探索功能分支工作流程
功能分支工作流程背後的核心概念是,所有功能開發都應該在專用分支中進行,而不是主要分支。
封裝可讓多個開發人員輕鬆地處理特定功能,而不會干擾主要程式代碼基底。 這也表示主要分支永遠不會包含中斷的程序代碼,這是持續整合環境的巨大優勢。
封裝功能開發也讓您能使用拉取請求,這是用來啟動對分支討論的一種方式。 這些工具可以讓其他開發人員在將功能整合至官方專案前,對功能進行審核。 或者,如果您卡在功能中間,您可以開啟提取要求,詢問同事的建議。
提取要求可讓您的小組輕鬆評論彼此的工作。 此外,功能分支也可以(且應該)推送至中央存放庫。 它允許與其他開發人員共用功能,而不需要觸及任何官方程序代碼。
因為main是唯一的「特殊」分支,因此將數個功能分支儲存在中央存放庫上並沒有任何問題。 這也是備份大家本地提交的便利方式。
發行分支工作流程
除了功能分支工作流程之外,Git 分支工作流程中另一個常用的策略是發行分支策略。 此策略涉及創建專用分支,專門用於準備發佈。 發行分支通常是從穩定的功能分支建立,確保它只包含經過徹底測試和驗證的程序代碼。 建立之後,發行分支會進行額外的測試、Bug 修正和穩定工作,以準備程式代碼基底以進行部署。 發行分支允許將發行相關活動與進行中的功能開發隔離,以提供受控環境來完成和完善即將發行的版本。 在發行分支上進行所有必要的調整和驗證之後,它會合併到主要分支,或直接部署到生產環境,視小組的發行程式而定。 發行分支策略可協助小組管理協調發行活動的複雜性,同時維護穩定的主要分支以進行持續開發。
主幹型開發工作流程
主幹型開發工作流程會假設中央存放庫,而主要代表官方專案歷程記錄。 開發人員不會直接提交到他們的主要分支,而是在開始開發新功能時,建立新的分支。 功能分支應該具有描述性名稱,例如 new-banner-images 或 bug-91。 其概念是讓每個分支擁有清楚且高度專注的目的。
Git 在技術上不區分主要分支和功能分支,因此開發人員可以編輯、暫存和提交功能分支的變更。
建立分支
當您在處理專案時,在任何指定時間都會有許多不同的功能或想法,其中有些已準備好進行,而另一些功能尚未進行。 分支的存在可協助您管理此工作流程。 當您在專案中建立分支時,您會建立一個環境,讓您試用新想法。
除了為新功能或修正建立分支之外,遵循發行分支工作流程的小組也會特別建立專用分支來準備發行版本。 這些發行分支通常衍生自穩定的功能分支,以確保它們包含經過徹底測試和驗證的程序代碼。 建立之後,發行分支會進行額外的測試、Bug 修正和穩定工作,以準備程式代碼基底以進行部署。
新增提交
建立分支之後,是時候進行變更了。 每當您新增、編輯或刪除檔案時,您會提交更改,並將它們新增至您的分支。
當您在功能分支上工作時,新增提交會紀錄您的進度。
提交也會建立您工作的透明歷史記錄,其他人可以遵循這些記錄來了解您所做的事情和原因。
每次提交都會有一個相關的提交訊息,說明為何進行特定變更。
此外,每個提交都會被視為獨立的變更單位。 如果找到 Bug,或您決定以不同的方向前進,它可讓您回復變更。
認可訊息很重要,特別是因為 Git 會追蹤您的變更,並在推送至伺服器後將其顯示為認可。
藉由撰寫明確的認可訊息,您可以更輕鬆地讓其他人追蹤並提供意見反應。
開啟提取要求
拉取請求會開始討論您的提交。 由於它們與基礎 Git 存放庫緊密整合,因此任何人都可以在接受您的要求時確切地看到哪些變更會合併。
您可以在開發程式期間隨時開啟提取要求:
- 您很少或沒有程序代碼,但想要共享螢幕快照或一般概念。
- 你被困住了,需要幫助或建議。
- 您已準備好讓某人檢閱您的工作。
您可以在提取要求訊息中使用 @mention 系統,詢問特定人員或小組的意見反應,無論他們位於大廳或 10 個時區之外。
提取要求有助於參與專案,以及管理共用存放庫的變更。
如果您使用分支 & 提取模型,提取要求會提供一種方式來通知專案維護人員您想要考慮的變更。
如果您使用共用存放庫模型,拉取請求可以在合併到主要分支之前,先啟動程式碼審查和對建議變更的討論。
討論並檢閱您的程序代碼
開啟拉取請求之後,檢閱變更的人員或小組可能會有問題或評論。
也許程式代碼撰寫樣式不符合項目指導方針,變更遺漏單元測試,一切看起來都很棒,而且道具是有序的。
Pull Requests 的目的是為了鼓勵與記錄這種類型的交談。
您也可以繼續推送至您的分支,同時考慮有關提交的討論和意見反饋。
假設有人留言說您忘記做了什麼,或者程式碼中出現 bug,您可以在自己的分支中修正然後推送變更。
Git 會在統一的拉取請求檢視中顯示您的新增提交以及您可能收到的任何意見反應。
提取要求批註是以 Markdown 撰寫,因此您可以內嵌影像和表情符號、使用預先格式化的文本塊和其他輕量格式。
部署
透過 Git,您可以從分支進行部署,在合併到 main 之前進行最終測試。
您的拉取請求被審查並且分支通過您的測試之後,您就可以部署變更以驗證這些變更。 如果您的分支造成問題,您可以復原它藉由部署現有的主要分支。
合併
一旦您的變更經過驗證,即可將程式代碼合併到主要分支。
合併之後,拉取請求會保留程式碼歷史變更紀錄。 因為這些是可搜尋的,所以它們讓任何人可以回溯以瞭解決策的原因和過程。
您可以將特定關鍵詞併入提取要求文字,以將問題與程式代碼產生關聯。 當你的提取請求被合併時,相關的問題也會關閉。
此工作流程可協助組織和追蹤著重於商務網域功能集的分支。
其他 Git 工作流程,例如 Git 分支工作流程和 Gitflow 工作流程,都是以存放庫為主,而且可以使用 Git 功能分支工作流程來管理其分支模型。