高級 Git 工作流程和用法

已發表: 2022-06-30

最近，我們了解了在項目中使用 Git 進行源代碼控制的基礎知識。雖然這是一個很好的起點，但還有許多其他命令和 Git 工作流程可以幫助您在日常編碼工作中使用 Git。

Git 工作流

當我開始使用 Git 時，我想我知道如何正確使用它。我理想的方法是在一個沒有分支的地方進行所有更改，然後將它們提交到存儲庫並繼續工作。

雖然它比不使用版本控制要好，但我花了一段時間才意識到我沒有使用 Git 提供的大部分功能。為了讓 Git 為我工作，我需要一個策略來分支和合併我的更改。

然後 git-flow 出來了，我採用了它作為我的策略。我仍然記得感覺就像我在幕後偷看了不起的開發人員所在的地方。我現在對它們的工作方式有了深入的了解，並且可以開始成為其中的一員。

但是 git-flow 並不適合所有場景，因此在我們研究它的同時，我們還將研究其他一些保持 Git 項目井井有條的方法，包括我作為一個單獨的開發人員如何管理我的項目。

混帳流

現在看看 git-flow，我承認軟件環境在 10 年內發生了很大變化，git-flow 可能不是您團隊的最佳選擇。在編寫 git-flow 的時候，一天內很少部署一個應用程序很多次。相反，如果您在一個特別敏捷的團隊中，您可能會每隔幾個月或幾週發布一次主要版本號和發布。

我們來看看git-flow是什麼。

如果你想看到關於 Git Flow 的圖表和 Git 命令的完整深入解釋，你應該閱讀這篇文章。

在 git-flow 中，兩個分支的生命週期是無限的。首先，main 應該反映準備好部署到您的實時/生產環境的代碼。

其次，我們有我們的開發分支。這個分支應該有最新的變化，為我們軟件的下一個版本做好準備。當開發中的更改準備好部署到我們的實時應用程序時，我們將它們合併到主分支並用與發布號對應的版本號標記它們。

在兩大分支之外，還有三種支撐分支。

一、特點

特性分支只能從開發分支創建。它必須合併回開發分支。命名可以是描述您正在處理的功能的任何內容。

當工作準備好下一個版本時，它會合併回開發分支，等待發佈時間。

2.發布

發布分支是從開發分支創建的，並且必須合併回開發和主分支。您使用 release-x 約定命名一個發布分支。在實踐中，這通常意味著您將使用您計劃使用的版本號命名一個分支，如下所示：release-2.2

您使用發布分支作為最後準備發佈軟件的一種方式。這可能包括增加文件的版本號、確保您的翻譯已完成或最終的代碼檢查。

3. 修補程序

hotfix 分支是從主分支創建的，用於包含需要在實時應用程序中立即處理的更改。這可能是必須修復的錯誤或需要處理的安全問題。

一旦問題得到解決並將其部署到您的主分支，您將使用正確的版本號標記您的代碼。

團隊現在不使用 git-flow 的最大原因是我們發佈軟件的方式發生了變化。您可以在一天內多次發布對應用程序的更改，而不是不那麼頻繁地發布較大的版本。我知道一旦準備好，我每週都會多次將工作推送到客戶的站點。我們不做網站的版本號，我們只是不斷改進它。

標準 git-flow 並不意味著適應這一點。

Github 流

許多人使用的第二個選項是 Github Flow。

Github Flow 的一個重要規則是，主分支上的任何代碼都可以隨時部署，因為它已準備好生產。

所有分支都是從主分支創建的，並為您正在做的任何事情提供一個描述性名稱。

準備好更改後，您可以創建拉取請求。

拉取請求告訴其他使用相同代碼的人，在將這些更改合併到主代碼之前，您正在做的工作已經準備好進行審查。

提交拉取請求後，與您合作的團隊可以查看更改並提供反饋。如果認為拉取請求已準備好合併，則將其合併到項目的主分支中。

對於單個開發人員或非常小的團隊來說，Github 流的一個缺點是管理拉取請求可能會在管理項目時產生額外的開銷。這就是為什麼我不在工作中使用它們的原因。

我如何在客戶端項目中使用 Git 工作流

在我的客戶工作中，我通常是唯一一個每天為項目編寫代碼的人。我的客戶可能會更新 WordPress 插件或更改一些 CSS，但他們不做任何主要的編碼工作。這意味著如果我使用 Github 流程，我將審查我的拉取請求，這只會帶來額外的管理難題。讓我們看看我使用的系統，它與 git-flow 和 Github flow 都有一些相似之處。

我有兩個主要分支，分別稱為 main 和 staging。主分支跟踪生產站點上當前運行的任何代碼。在我們將更改推送到實時站點之前，暫存分支跟踪我們用來測試更改的暫存站點上正在測試的任何內容。

每個分支都是從主分支創建的。新功能的名稱如下：feature/32-new-feature。在這種情況下，數字 32 對應於我們項目管理系統中的工單編號，其後面的單詞是對正在處理的內容的簡短描述。錯誤修復的名稱類似，bug/20-bug-name。

創建的每個分支都會先合併到我們的暫存分支中，然後一旦得到客戶的批准或我自己的測試，就會合併到主分支中。該工作流程可能如下所示。

# 將特徵合併到暫存分支

git 合併功能/32-新功能

# 部署和測試功能

git結帳主要

git 合併功能/32-新功能

# 將功能部署到實時站點

在我的項目中，我設置了持續部署，這意味著每當我將代碼推送到 main 時，它都會自動推送到實時站點。為暫存分支設置相同的過程。

如果我與一個可以在拉取請求工作流中檢查我的代碼的團隊合作，那麼我會使用這個系統，因為它在團隊中運行良好。對於一個主要靠自己工作的開發人員來說，只是管理開銷會減慢您的工作流程。

我使用的高級 Git 命令

現在我們對如何在實際工作流程中使用 Git 有了一些想法，讓我們看一下實現這一點所需的更高級的命令。在處理客戶代碼時，我每周至少使用這些命令幾次。

即使您打算使用 GUI 應用程序（我在上一篇關於 Git 的文章中提到了一些好的應用程序），了解後台發生的事情仍然很重要。很多時候，我不得不通過終端解決由 Git GUI 應用程序創建的問題。

按行添加更改

對我來說，通過終端點擊使用 Git 的一個命令是 git add -p。在我學會這個命令之前，我使用 GUI 應用程序，因為我會在我的代碼中進行更改，但想將特定的行分解為不同的提交，以便我可以解釋為什麼我進行了更改。為此，我使用 GUI 來選擇行，但 git add -p 會引導您通過交互式界面添加塊中的更改。

我每天都使用這個很多次。

跟踪遠程 Git 分支

如果您要拉下現有存儲庫並具有需要跟踪但已經存在的 main 和 staging 等分支，則需要告訴分支的本地版本以跟踪分支的遠程版本。

有幾種方法可以做到這一點。

# 推送到遠程時設置上游

git push -u 原點暫存

# 設置上游

# 假設你在你想要遠程跟踪的分支上

git 分支 -u 起源/暫存

git 分支 --set-upstream-to=origin/staging

# 如果您不在要跟踪的分支上，則在最後指定分支

git branch --set-upstream-to=origin/staging staging

保存更改而不提交

有時您會處於一些尚未準備好提交的工作的中間，但您需要保存其狀態。這就是 git stash 有用的地方。此命令通過刪除更改為您隱藏更改。您可以使用 git stash pop 將它們取回。還有一些命令可以使 stash 有用，但這是我經常使用的兩個。

拉取特定的 Git 提交

有時您需要將特定提交拉入當前工作。使用乾淨的 HEAD（您尚未進行任何更改），您可以使用 git cherry-pick 拉入特定的提交。你可以在這裡找到關於 git cherry-pick 的完整文檔。

對於每個提交，Git 都會構建一長串字母和數字，稱為 Git 對象，通常稱為 SHA。 由於每個提交都有一個，因此您可以使用其 SHA 值引用一個提交。 閱讀更多關於 Git 對象的信息。

扔掉你不需要的改變

在任何項目的某個時刻，我們都會進行更改，然後意識到它不起作用，我們需要簡單地廢棄它們並重新開始。我們可以使用以下 Git 命令刪除尚未跟踪的任何更改，而不是僅僅嘗試撤消直到我們回到我們想要的位置。

git reset --hard

上面的命令會將您的代碼重置為您當前正在處理的分支上的最新提交。如果我們想恢復到最近一次提交之前的狀態，我們還可以使用帶有此命令的 <#commitSHA> 來重置到特定的提交。也許您會使用它來重置初始分支結帳，因為您不想保留整個分支的工作價值，但您已經跟踪了一些工作。

更進一步，我們可以使用 git clean 命令丟棄任何尚未在 git 中跟踪的文件或目錄。

git clean -fd：標誌 f 和 d 告訴 git 丟棄未跟踪的文件和目錄。

刪除分支

每隔一兩週，我都會查看 git status 命令的結果，發現我的分支太多，無法合理地理解我的存儲庫中發生了什麼。這意味著我可以刪除與已使用以下命令解決的票證相對應的任何分支。

# 刪除本地版本

git 分支 -d $ 分支名稱

#刪除我遙控器上的分支

git push $remotename --delete $branchname

使用版本控制

雖然您可能不是您將使用的所有 Git 命令的專家，但要記住的一件重要事情是您應該使用版本控制。即使您是項目的唯一工作人員，使用 Git 和 Git 工作流程也將幫助您保持項目井井有條。在編寫不起作用的代碼後重置工作之前，您無需按 CTRL + Z。

您將能夠信任您的系統並繼續為您的項目工作。

嘗試完全託管的 WordPress 託管

需要為 WordPress 優化的主機？ 立即查看 Nexcess 的完全託管的 WordPress 託管計劃。