這是比利。

帶著微笑和紅色領帶的簡筆畫

他是一位為重要公司工作的實習開發人員。

對公司來說不幸的是,今天比利醒來並選擇了暴力。

這是因為他覺得學習Git非常麻煩、枯燥、很費解。

分支、提交、簽出、HEAD、功能、暫存,天啊!

這對他來說實在太多了。

但隨後比利想到了一個絕對是最好、最壞的主意。

「如果我學習 git 時先學會什麼不該做,然後又去做,那會怎麼樣!”

這將完成三件事:

  1. 他會透過給自己一些通常被禁止的有趣的小挑戰來學習 git 最常用的工具。

  2. 如果他知道什麼不該做,那麼他以後就可以專注於他應該做的事情。

  3. 這樣的學習滿足了他混亂的邪惡傾向。

對比利來說,這聽起來越來越像是個好主意。這肯定會讓他成為一個更好的開發人員。

但只有一個問題......

Git 是開發人員用來管理軟體原始碼的版本控制系統。

每當某人更改、新增甚至刪除某些內容時,Git 都會記錄誰做了什麼。

如果你想在你工作的公司擁有的儲存庫中做一些非常糟糕的事情,那麼總是有人可以追溯到你。

那肯定會讓你被解僱。

這就是比利偷了特倫特電腦的原因。

簡筆人物比利舉著一台逼真的筆記型電腦,上面寫著“特倫特的電腦(被盜)”

特倫特是個大笨蛋,他去洗手間時打開了電腦,而且沒有採取任何保護措施。

在上個月的聚會後,他還沒有事先詢問就吃了最後一片披薩。

透過 Trent 的計算機,Billy 現在可以存取相同的儲存庫,但需要使用 Trent 的登入憑證。

所以現在 Billy 可以透過先學習他不應該做的所有事情來學習 Git,例如:

1.使用--force將程式碼推送到別人的分支

假設目前的 git 生態系如下所示:

主分支和同事功能分支的 Git 圖。

Billy 目前正在查看另一位同事分支的早期版本。

如果兩個人在同一個分支上簽出,但其中一個人開始將變更推送到遠端,則可能會發生這種情況。

這意味著比利在分支上落後了。如果他想取得目前所在分支的最新更改,他會在終端機中寫入git pull

有趣的事實:

Git pull 其實是另外 2 個 git 指令的組合。

  • git fetch origin (取得遠端的最新變更而不檢查或合併它)

  • git merge origin/<branch name> (這會將本機變更合併至遠端。由於通常您不會合併本機文件,因此 git 會執行所謂的「快轉」操作,最終您會得到最新的變更)

比利想知道如果他嘗試推動這個人的分支會發生什麼,即使他落後於最新的變化。

通常,如果他嘗試git push某些程式碼,該嘗試將會失敗並出現錯誤 - 要求他首先提取最新的更改。

(這是 git 內建的安全網,以避免工作遺失。除非先拉,否則無法推!)

但如果比利執行git push --force指令,就可以避免這種情況。

git push --force對於開發人員來說通常是一個大問題。這是一個強制覆蓋 git 歷史記錄並讓您推送本地更改的命令,儘管它可能會刪除同一分支上其他人的工作。

比利以前從未使用過它,是一個好奇的男孩,所以他做了任何好奇的人都會做的事情。

  1. 他建立了一個新文件,其中包含特殊文字:

echo "Trent was here" > Trent.txt

  1. 他對分行做出了非常重要的改變

git add Trent.txt

git commit -m "Trent committed this"

這使得 git 看起來像這樣:

Git 流程圖顯示了他的同事的更改如何消失以及 Billy 的新程式碼如何覆蓋它

  1. 他透過強制將新變更推送到分支來結束

git push --force

幾秒鐘後...

噗!

Billy 非常重要的更改現在已在 Git 中!

同時,他同事的所有工作完全消失了!

天啊,那真是太有趣了。比利想知道他還要等多久才能讓那位同事注意到。

他想知道是否有什麼事情是他能做的最糟糕的事情。也許……他可以在生產中做類似的事情?

比利腦中的一個燈泡突然熄滅了!如果他做了:

2.生產分支上的硬重置

Git reset是一個命令,類似於 Billy 對他的同事所做的那樣,撤消在分支中建立的對先前提交的更改。

與他之前學到的git push --force指令不同,沒有什麼可以推送的。它只是透過(通常)取消提交在某個提交之前完成的所有事情來重寫 git 歷史記錄。

git reset 指令有 3 種模式。

  1. git reset --soft將 HEAD(Head 是您目前簽出的提交)移回指定的提交,同時也撤銷所做的所有變更。所有這些變更都會返回暫存狀態,並允許您再次提交。

  2. git reset --mixedgit reset --soft作用相同,但會保留您所做的所有變更。這也是 git reset 指令的預設模式。因此,如果您編寫git reset ,則與執行git reset --mixed相同。

  3. git reset --hard是惡魔般的。它不會撤消更改並將其保留在暫存/未暫存狀態...它只是丟棄它們。

當您硬重置到舊提交時,所有這些更改都會消失。

因此,如果 Billy 說…硬重置到6 個月前的提交,哦,我不知道,這對公司來說將是非常糟糕的。

比利微笑著打開終端機。

記住 git 生態系統是什麼樣子的:

Git 分支顯示 6 個月前的提交和最新的提交

比利高興地開始說:

  1. 在終端git checkout main中輸入,將他定位到該分支的最新提交。

  2. 使用 git 視覺化工具從主分支尋找 6 個月前的提交。

  3. 最後輸入git reset --hard <commit hash>刪除主分支中過去 6 個月的所有變更。

幾秒鐘後...

噗!

比利成功地讓一些公司高層非常非常生氣!

但等一下...

比利能夠做到這一點很奇怪,不是嗎?畢竟...

權限通常在儲存庫中設置,以便任何人都無法直接推送到生產分支。

這可以防止意外推送或重寫直接影響網站的 git 歷史記錄。

這就是為什麼存在所謂的「拉取請求」(或 PR)的原因。

拉取請求是將一組變更從一個分支合併到另一個分支的提議。

通常,其他精通技術的開發人員首先必須接受您的更改,然後您才能合併。

但如果從未設定這些權限會發生什麼事?

好吧,似乎像比利這樣的人可以在一秒鐘內抹掉每個人過去兩個季度的努力。

他計算出,在他對生產產生主要影響之前,他可能還有 10 分鐘……不,15 分鐘。

所以比利必須快速行動。在一個名叫特倫特的人陷入麻煩之前,他可能還有時間去做另一件混亂的邪惡事情。

該怎麼辦...

哦,比利知道!他應該:

  1. 揭露專案秘密並將其推向生產!

Billy 可以透過修改 .gitignore 檔案輕鬆完成此操作。

.gitignore 是位於專案目錄中的一種特殊類型的檔案。顧名思義,它指定 Git 應忽略哪些檔案並避免讓您暫存。

當您有一些不想先上傳到儲存庫的特定檔案時,這非常有用。

通常希望避免上傳的檔案之一是 .env 檔案。

.env 檔案往往在專案中用於保存您將在整個解決方案中使用的環境變數。

它們具有鍵/值對以及您確實不想上傳的資訊。 API 金鑰、資料庫 URI、AUTH 金鑰等。

但比利不喜歡保守秘密。

他是他故事中的英雄,必須讓人知道!

因此,如果我們假設 .gitignore 檔案如下所示:

# Javascript node_modules
node_modules/

# API keys
.env

那麼比利要做的就是:

  1. 找到 .gitignore 文件

  2. 使用他最喜歡的 IDE 或終端文字編輯器從檔案中刪除 .env 行並儲存。 (這使得文件現在看起來像這樣)

    # Javascript node_modules
    node_modules/

    # API keys are gone from ignore oops
  1. 將現在更改的 .gitignore 檔案新增到暫存中。 Billy 透過在終端機中輸入git add .gitignore來完成此操作

  2. 等一下!不要忘記 - 由於 Git 現在不會忽略 .env 文件,Billy 也必須加入它! git add .env也被輸入到終端機中。

  3. 是時候做出承諾了!比利用這一行做到了這一點:

`git commit -m "FREEEEEEDOOOOOMMM!!!! #TrentWasHere"`
  1. 最後一步!是時候推送到主分支了。再次,由於某種原因,沒有任何權限設定可以阻止比利,他可以在終端機中寫入git push --force

幾秒鐘後...

噗!

「自由、平等、博愛」比利高興地低聲說!就在他把特倫特的電腦留在了它所屬的地方。

這也是一件好事,因為他剛剛聽到遠處房間裡傳來廁所沖水的聲音。

比利跑回他的辦公桌,在任何人注意到之前及時趕到。

看來特倫特終於從衛浴休息回來,坐在辦公桌前。

但就在他打開筆記型電腦之前,特倫特的電話響了。

戒指戒指,戒指戒指

比利滿懷期待地等待著,看到特倫特慢慢地拿起電話。

“你好?”

“特倫特。辦公室。現在。”

比利可以在 5 個辦公桌外聽到特倫特電話裡的喊叫聲。

“哇,老闆發生什麼事了?”

“我沒有做任何事——”

「你們生產出了什麼事嗎?

“我正在路上”

崔恩特迅速跑向辦公室,可能是為了他一生中的尖叫聲。

比利坐下來,放鬆下來,終於可以說:

「今天我是一個更好的開發人員」。

簡筆畫比利微笑著


這是我寫過的最愚蠢的文章。

如果您喜歡我的幽默感,那麼我想您一定會喜歡我的電子報「Exceptional Frontend」——網路上最有趣的前端電子報。

它適合任何想要一份以前端為中心、試圖與其他人不同的時事通訊的開發人員。我們專注於使其獨一無二,最重要的是—有趣!

同時也幫助開發人員在他們所做的事情上變得出色。

您可以在這裡註冊。


原文出處:https://dev.to/mauroaccorinti/how-to-get-somebody-fired-using-git-31if


共有 0 則留言