🩺 醫生有聽診器。

🔧 機械師有扳手。

👨‍💻 我們開發人員，有 Git。

您是否注意到 Git 對於程式碼工作來說是如此不可或缺，以至於人們幾乎從未將其包含在他們的技術堆疊或簡歷中？假設你已經知道了，或至少足以應付，但你知道嗎？

Git 是一個版本控制系統（VCS）。無所不在的技術使我們能夠儲存、更改程式碼並與他人合作。

🚨 作為免責聲明，我想指出 Git 是一個很大的話題。 Git 書籍已經出版，部落格文章也可能被誤認為是學術論文。這不是我來這裡的目的。我不是 Git 專家。我的目標是寫一篇我希望在學習 Git 時擁有的 Git 基礎文章。

作為開發人員，我們的日常工作圍繞著閱讀、編寫和審查程式碼。 Git 可以說是我們使用的最重要的工具之一。身為開發人員，掌握 Git 提供的特性和功能是您可以對自己進行的最佳投資之一。

讓我們開始吧

如果您覺得我錯過了或應該更詳細地了解特定命令，請在下面的評論中告訴我。我將相應地更新這篇文章。 🙏

當我們談論這個話題時

如果您希望將 Git 技能運用到工作中並願意為 Glasskube 做出貢獻，我們於 2 月正式推出，我們的目標是成為 Kubernetes 套件管理的預設預設解決方案。有了您的支持，我們就能實現這一目標。表達您支持的最佳方式是在 GitHub 上為我們加註星標 ⭐

讓我們打好基礎

Git 有沒有讓你感覺像 Peter Griffin 一樣？

如果您沒有以正確的方式學習 Git，您可能會不斷地摸不著頭腦，陷入同樣的問題，或者後悔有一天在終端中出現另一個合併衝突。讓我們定義一些基本的 Git 概念來確保這種情況不會發生。

分公司

在 Git 儲存庫中，您會發現一條開發主線，通常名為「main」或「master」（ 已棄用），其中有幾個分支分支。這些分支代表同時的工作流程，使開發人員能夠在同一專案中同時處理多個功能或修復。

提交

Git 提交作為更新程式碼的捆綁包，捕獲專案程式碼在特定時間點的快照。每次提交都會記錄自上次記錄以來所做的更改，共同建立專案開發旅程的全面歷史。

當引用提交時，您通常會使用其唯一標識的加密雜湊。

例子：

git show abc123def456789

這顯示了有關該哈希提交的詳細資訊。

標籤

Git標籤充當 Git 歷史中的地標，通常標記專案開發中的重要里程碑，例如releases 、 versions或standout commits 。這些標籤對於標記特定時間點非常有價值，通常代表專案旅程中的起點或主要成就。

頭

目前簽出分支上的最新提交由HEAD指示，充當儲存庫中任何引用的指標。當您位於特定分支時， HEAD指向該分支上的最新提交。有時， HEAD可以直接指向特定的提交（ detached HEAD狀態），而不是指向分支的尖端。

階段

了解 Git 階段對於導航 Git 工作流程至關重要。它們代表文件更改在提交到儲存庫之前發生的邏輯轉換。

讓我們深入研究一下 Git 階段的概念：

工作目錄👷

working directory是您編輯、修改和建立專案文件的位置。表示本機上檔案的目前狀態。

暫存區🚉

staging區域就像一個保留區域或預提交區域，您可以在其中準備更改，然後再將更改提交到儲存庫。

這裡有用的指令： git add

git rm也可用於取消暫存更改

本地儲存庫🗄️

本機儲存庫是 Git 永久儲存已提交變更的位置。它允許您查看專案的歷史記錄，恢復到以前的狀態，並與同一程式碼庫上的其他人進行協作。

您可以使用以下指令提交暫存區域中準備好的變更： git commit

遠端儲存庫🛫

遠端儲存庫是一個集中位置，通常託管在伺服器（例如 GitHub、GitLab 或 Bitbucket）上，您可以在其中與其他人共用專案並進行協作。

您可以使用git push和git pull等命令將提交的變更從本機儲存庫推送/拉取到遠端儲存庫。

Git 入門

好吧，你必須從某個地方開始，在 Git 中那就是你的workspace 。您可以fork或clone現有儲存庫並擁有該工作區的副本，或者如果您在電腦上的新本機資料夾中全新開始，則必須使用git init將其轉換為 git 儲存庫。不容忽視的下一步是設定您的憑證。

憑證設定

當執行推送和拉取到遠端儲存庫時，您不想每次都輸入使用者名稱和密碼，只需執行以下命令即可避免這種情況：

git config --global credential.helper store

第一次與遠端儲存庫互動時，Git 會提示您輸入使用者名稱和密碼。之後，您將不再收到提示

請務必注意，憑證以純文字格式儲存在.git-credentials檔案中。

若要檢查已配置的憑證，您可以使用下列命令：

git config --global credential.helper

與分公司合作

在本地工作時，了解您目前所在的分支至關重要。這些命令很有幫助：

# Will show the changes in the local repository
git branch 

# Or create a branch directly with
git branch feature-branch-name

若要在分支之間轉換，請使用：

git switch

除了在它們之間進行轉換之外，您還可以使用：

git checkout 
# A shortcut to switch to a branch that is yet to be created with the -b flag 
git checkout -b feature-branch-name

若要檢查儲存庫的狀態，請使用：

git status

始終清楚了解當前分支的一個好方法是在終端機中查看它。許多終端插件可以幫助解決這個問題。這是一個。

使用提交

在處理提交時，使用 git commit -m 記錄更改，使用 git amend 修改最近的提交，並盡力遵守提交訊息約定。

# Make sure to add a message to each commit
git commit -m "meaningful message"

如果您對上次提交進行了更改，則不必完全建立另一個提交，您可以使用 --amend 標誌來使用分階段變更來修改最近的提交

# make your changes
git add .
git commit --amend
# This will open your default text editor to modify the commit message if needed.
git push origin your_branch --force

⚠️ 使用--force時要小心，因為它有可能涵蓋目標分支的歷史記錄。通常應避免在 main/master 分支上應用它。

根據經驗，最好經常提交，以避免遺失進度或意外重置未暫存的變更。之後可以透過壓縮多個提交或進行互動式變基來重寫歷史記錄。

使用git log顯示按時間順序排列的提交列表，從最近的提交開始並按時間倒推

操縱歷史

操縱歷史涉及一些強大的命令。 Rebase重寫提交歷史記錄， Squashing將多個提交合併為一個，而Cherry-picking選擇特定提交。

變基和合併

將變基與合併進行比較是有意義的，因為它們的目標相同，但實現方式不同。關鍵的差異在於變基重寫了專案的歷史。對於重視清晰且易於理解的專案歷史的專案來說，這是理想的選擇。另一方面，合併透過產生新的合併提交來維護兩個分支歷史記錄。

在變基期間，功能分支的提交歷史記錄在移動到主分支的HEAD時會被重組

這裡的工作流程非常簡單。

確保您位於要變基的分支上並從遠端儲存庫取得最新變更：

git checkout your_branch
git fetch

現在選擇您想要變基的分支並執行以下命令：

git rebase upstream_branch

變基後，如果分支已推送到遠端儲存庫，您可能需要強制推送變更：

git push origin your_branch --force

⚠️ 使用--force時要小心，因為它有可能涵蓋目標分支的歷史記錄。通常應避免在 main/master 分支上應用它。

擠壓

Git 壓縮用於將多個提交壓縮為單一、有凝聚力的提交。

這個概念很容易理解，如果使用的統一程式碼的方法是變基，則特別有用，因為歷史記錄會被改變，所以注意對專案歷史記錄的影響很重要。有時我很難執行擠壓，特別是使用互動式變基，幸運的是我們有一些工具可以幫助我們。這是我首選的壓縮方法，其中涉及將 HEAD 指標向後移動 X 次提交，同時保留分階段的變更。

# Change to the number after HEAD~ depending on the commits you want to squash
git reset --soft HEAD~X
git commit -m "Your squashed commit message"
git push origin your_branch --force

⚠️ 使用--force時要小心，因為它有可能涵蓋目標分支的歷史記錄。通常應避免在 main/master 分支上應用它。

採櫻桃

櫻桃採摘對於選擇性地合併從一個分支到另一個分支的更改非常有用，特別是當合併整個分支不合需要或不可行時。然而，明智地使用櫻桃選擇很重要，因為如果應用不當，可能會導致重複提交和不同的歷史記錄

要先執行此操作，您必須確定要選擇的提交的提交哈希，您可以使用git log來執行此操作。一旦確定了提交哈希，您就可以執行：

git checkout target_branch
git cherry-pick <commit-hash> # Do this multiple times if multiple commits are wanted
git push origin target_branch

高級 Git 指令

簽署提交

對提交進行簽名是一種驗證 Git 中提交的真實性和完整性的方法。它允許您使用 GPG (GNU Privacy Guard) 金鑰對您的提交進行加密簽名，從而向 Git 保證您確實是該提交的作者。您可以透過建立 GPG 金鑰並將 Git 配置為在提交時使用該金鑰來實現此目的。

步驟如下：

# Generate a GPG key
gpg --gen-key

# Configure Git to Use Your GPG Key
git config --global user.signingkey <your-gpg-key-id>

# Add the public key to your GitHub account

# Signing your commits with the -S flag
git commit -S -m "Your commit message"

# View signed commits
git log --show-signature

轉發日誌

我們還沒有探討的一個主題是 Git 引用，它們是指向儲存庫中各種物件的指針，主要是提交，還有標籤和分支。它們可作為 Git 歷史記錄中的命名點，允許使用者瀏覽儲存庫的時間軸並存取專案的特定快照。了解如何導航 git 引用非常有用，他們可以使用 git reflog 來做到這一點。

以下是一些好處：

• 恢復遺失的提交或分支

• 除錯和故障排除

• 糾正錯誤

互動式變基

互動式變基是一個強大的 Git 功能，可讓您以互動方式重寫提交歷史記錄。它使您能夠在將提交應用到分支之前對其進行修改、重新排序、組合或刪除。

為了使用它，您必須熟悉可能的操作，例如：

• 選擇（“p”）

• 改寫（“r”）

• 編輯（“e”）

• 壁球（“s”）

• 刪除（“d”）

這是一個有用的影片，用於學習如何在終端中執行互動式變基，我還在部落格文章的底部連結了一個有用的工具。

與 Git 協作

起源與上游

來源是複製本機 Git 儲存庫時與本機 Git 儲存庫關聯的預設遠端儲存庫。如果您分叉了一個儲存庫，那麼預設情況下該分叉將成為您的「原始」儲存庫。

另一方面，上游指的是您的儲存庫分叉的原始儲存庫。

為了讓您的分叉儲存庫與原始專案的最新更改保持同步，您可以從「上游」儲存庫中 git 取得更改，並將它們合併或變基到本機儲存庫中。

若要查看與本機 Git 儲存庫關聯的遠端儲存庫，請執行：

git remote -v

衝突

不要驚慌，當嘗試合併或變基分支並檢測到衝突時，這只意味著存儲庫中同一文件或文件的不同版本之間存在衝突的更改，並且可以輕鬆解決（大多數情況下）。

它們通常在受影響的文件中指示，Git 在其中插入衝突標記<<<<<<< 、 =======和>>>>>>>以突出顯示衝突部分。

決定保留、修改或刪除哪些更改，確保產生的程式碼有意義並保留預期的功能。

手動解決衝突檔案中的衝突後，刪除衝突標記<<<<<<< 、 =======和>>>>>>>並根據需要調整程式碼。

對解決方案感到滿意後，請儲存衝突文件中的變更。

如果您在解決衝突時遇到問題，該影片可以很好地解釋它。

流行的 Git 工作流程

存在各種 Git 工作流程，但需要注意的是，不存在通用的「最佳」Git 工作流程。相反，每種方法都有其自身的優點和缺點。讓我們來探索這些不同的工作流程，以了解它們的優點和缺點。

功能分支工作流程🌱

每個新功能或錯誤修復都是在自己的分支中開發的，然後在完成後將其合併回主分支。

• 優點：隔離變更並減少衝突。

• 弱點：可能變得複雜並且需要勤奮的分行管理。

Gitflow 工作流程 🌊

Gitflow 定義了嚴格的分支模型，為不同類型的開發任務提供了預先定義的分支。

它包括長期分支，例如 main、develop、feature 分支、release 分支和 hotfix 分支。

• 優點：適合定期發布、長期維護的專案。

• 缺點：對於較小的團隊來說可能過於複雜

分岔工作流程🍴

在此工作流程中，每個開發人員都會複製主儲存庫，但他們不會將變更直接推送到主儲存庫，而是將變更推送到自己的儲存庫分支。然後，開發人員建立拉取請求以提出對主儲存庫的更改，從而允許在合併之前進行程式碼審查和協作。

這是我們在開源 Glasskube 儲存庫上進行協作的工作流程。

• 優點：鼓勵外部貢獻者進行協作，而無需授予對主儲存庫的直接寫入存取權。

• 弱點：維持分支和主儲存庫之間的同步可能具有挑戰性。

拉取請求工作流程 ⏩

與分叉工作流程類似，但開發人員不是分叉，而是直接在主儲存庫中建立功能分支。

• 優點：促進團隊成員之間的程式碼審查、協作和知識共享。

• 弱點：對人類程式碼審查員的依賴可能會導致開發過程延遲。

基於主幹的開發🪵

如果您所在的團隊專注於快速迭代和持續交付，您可能會使用基於主幹的開發，開發人員直接在主分支上工作，提交小而頻繁的變更。

• 優勢：促進快速迭代、持續集成，並專注於為生產提供小而頻繁的變更。

• 缺點：需要強大的自動化測試和部署管道來確保主分支的穩定性，可能不適合發佈時間表嚴格或功能開發複雜的專案。

什麼叉子？

強烈建議在開源專案上進行分叉，因為您可以完全控制自己的儲存庫副本。您可以進行變更、嘗試新功能或修復錯誤，而不會影響原始專案。

💡 我花了很長時間才弄清楚，雖然分叉存儲庫作為單獨的實體開始，但它們保留了與原始存儲庫的連接。此連接可讓您追蹤原始專案中的變更並將您的分支與其他人所做的更新同步。

這就是為什麼即使您推送到原始存儲庫也是如此。您的變更也會顯示在遙控器上。

Git 備忘錄

# Clone a Repository
git clone <repository_url>

# Stage Changes for Commit
git add <file(s)>

# Commit Changes
git commit -m "Commit message"

# Push Changes to the Remote Repository
git push

# Force Push Changes (use with caution)
git push --force

# Reset Working Directory to Last Commit
git reset --hard

# Create a New Branch
git branch <branch_name>

# Switch to a Different Branch
git checkout <branch_name>

# Merge Changes from Another Branch
git merge <branch_name>

# Rebase Changes onto Another Branch (use with caution)
git rebase <base_branch>

# View Status of Working Directory
git status

# View Commit History
git log

# Undo Last Commit (use with caution)
git reset --soft HEAD^

# Discard Changes in Working Directory
git restore <file(s)>

# Retrieve Lost Commit References
git reflog

# Interactive Rebase to Rearrange Commits
git rebase --interactive HEAD~3

獎金！一些 Git 工具和資源可以讓您的生活更輕鬆。

• 互動式變基工具。

• Cdiff查看豐富多彩的增量差異。

• 互動式 Git 分支遊樂場

如果您喜歡這類內容並希望看到更多內容，請考慮在 GitHub 上給我們一個 Star 來支持我們🙏

原文出處：https://dev.to/glasskube/the-guide-to-git-i-never-had-1450