_歡迎參加 DevSecOps in 5 的第 2 週：您獲得安全開發超級大國的門票！

嘿，安全冠軍和編碼戰士！

您是否渴望提升 DevSecOps 水平並成為堅如磐石的軟體架構師？好吧，您來對地方了！這個為期 5 週的部落格系列是您掌握安全開發和部署的快速通道。

準備好拋棄開發戲劇，對您的安全實踐建立不可動搖的信心。我們同舟共濟，所以係好安全帶，讓我們踏上這段史詩般的旅程！

歡迎來到 Git 的世界，這是一個為無數軟體開發專案提供支援的無處不在的版本控制系統。雖然您可能已經掌握了初始化儲存庫、提交變更和推送程式碼的基本命令，但本部落格將進行更深入的研究，探索進階策略和工作流程以增強您對 Git 的掌握。

分支策略：超越 GitFlow

分支是 Git 的核心概念，它允許開發人員在不影響主程式碼庫的情況下處理獨立的程式碼行。然而，有效的分支策略對於維護清潔和協作的開發環境至關重要。在這裡，我們將探討流行的分支策略及其細微差別：

GitFlow 與 GitHub Flow：

這兩種流行的分支策略提供了不同的方法：

gitflow：

受到較大團隊的青睞，GitFlow 採用了一組專用的分支：

master：

神聖不可侵犯的生產分支，只保存最穩定且經過徹底測試的程式碼。

develop：

整合了持續功能和錯誤修復的中央開發分支。

feature：

短期分支從針對特定功能的開發中分支出來，完成後合併回來。

hotfix：

短期分支直接從 master 分支出來，用於緊急錯誤修復，然後合併回開發分支和 master 分支。

發布分支：從開發分支出來的短期分支，為不同的環境準備發布。

GitHub 流程：

GitHub Flow 更輕量級且適合較小的團隊，它利用：

master：

與 GitFlow 類似，僅儲存可用於生產的程式碼。

feature：

這些分支直接從 master 分支出來，包含功能和錯誤修復，在審查和測試後直接合併到 master 中。

hotfix：

與GitFlow類似，用於關鍵bug修復，直接合併到master中，然後刪除。

優點和適用性：

GitFlow 為大型團隊提供結構化控制，確保程式碼在投入生產之前的穩定性。但是，它需要更嚴格地執行分支命名約定和工作流程。 GitHub Flow 對於較小的團隊來說更簡單、更快，專注於持續整合和快速迭代。選擇最適合您的專案規模、複雜性和團隊結構的策略。

額外提示：

考慮使用分支模型視覺化工具（例如“git分支”）來獲得分支及其關係的清晰圖形視圖。

功能分支工作流程：最佳實踐

功能分支是 Git 開發的主力。以下是如何利用它們來優化您的工作流程：

建立清晰且具描述性的分支名稱：

使用一致的命名約定（例如，功能/新登入系統）來提高專案的清晰度和可發現性。

定期程式碼審查：

在合併回主分支之前，請另一位開發人員檢查您的程式碼的品質、效率以及對編碼標準的遵守情況。利用 GitHub 或 GitLab 等平台的內建審核功能來簡化溝通。

合併策略：

採用「合併」或「變基」策略來整合您的功能分支：

合併：

建立合併提交，記錄分支和主分支之間的整合點。這更簡單，但可能會導致更複雜的 Git 歷史記錄。

狐狸：

在最新的主分支提交之上重寫功能分支的提交，從而產生更清晰的 Git 歷史記錄。然而，變基需要謹慎，因為它可以重寫其他合作者所看到的歷史。

衝突解決技巧：

當對不同分支所做的變更影響相同的程式碼行時，可能會出現合併衝突。學習使用 Git 的內建合併工具或手動編輯來辨識和解決衝突。

修補程式和版本的分支

專用分支服務於功能開發以外的特定目的：

修補程式分支：

對於需要立即部署的關鍵錯誤修復，請直接從主伺服器建立修補程式分支。修復問題，在臨時環境中進行徹底測試，並將修補程式合併回主版本（並在適用的情況下進行開發）以快速解決問題。合併後刪除修補程式分支。

發布分支：

使用從開發分支的專用分支準備版本。整合錯誤修復、最終功能完善和文件更新。嚴格測試完成後，將發布分支合併至 master 進行部署。考慮在 master 中標記提交以進行版本控制。

使用 Git 的協作工作流程

分叉和拉取請求：

GitHub 和 GitLab 等平台允許開發人員「分叉」儲存庫，建立個人副本。在他們的分支上，他們可以建立功能分支，實施更改，然後向原始儲存庫提交「拉取請求」。這會觸發程式碼審查流程，維護人員可以審查變更、建議修改並批准拉取請求以將程式碼合併到主分支中。

解決合併衝突：

當多個開發人員在不同的分支中處理相同的檔案時，就會發生合併衝突。 Git 通常會突出顯示這些衝突，您有責任手動編輯文件來解決它們。 Git 的合併工具或 Git 用戶端中的視覺化合併編輯器等工具可以簡化此流程。

使用遠端儲存庫：

使用 GitHub 或 GitLab 等遠端儲存庫服務集中化版本控制。這提供了許多好處：

合作：

團隊成員可以輕鬆分叉、克隆程式碼並將其推送到遠端儲存庫，從而促進協作開發。

版本控制歷史記錄：遠端儲存庫維護完整的 Git 歷史記錄，讓您可以恢復到先前的版本或追蹤程式碼演進。

備份和災難復原：

如果本機電腦發生故障，遠端儲存庫可確保程式碼庫的安全備份。

用於自動化任務的 Git Hooks

Git 掛鉤是在 Git 工作流程中的特定點自動執行的腳本，增加了自動化並實施最佳實踐。

Git Hook 的類型：

有幾種預定義的鉤子類型：

預提交：

在提交之前執行，允許您強制執行編碼標準或執行 linting 檢查。

提交後：

在提交後執行，對於更新建置版本或發送通知很有用。

預推：

在程式碼被推送到遠端儲存庫之前執行，通常用於最終檢查或測試。

推後：

在推送程式碼後執行，可能會觸發部署或整合。

常見的 Git Hook 使用案例：Git hook 可以自動執行各種任務：

程式碼格式：

使用在提交之前執行程式碼格式化程式（例如 autopep8 或 clang-format）的鉤子來強制執行一致的程式碼風格。

單元測試：

在推送程式碼之前使用 pytest 或 Jest 等掛鉤執行自動化單元測試，確保整合先前的基本功能。

靜態程式碼分析：

透過預先提交掛鉤將 Pylint 或 ESLint 等靜態程式碼分析工具整合到您的工作流程中，以辨識潛在的錯誤或漏洞。

建立自訂 Git Hook：

雖然預先定義的掛鉤可以滿足常見需求，但您可以使用 Bash 或 Python 等腳本語言建立自訂掛鉤。有關建立和配置自訂掛鉤的詳細說明，請參閱 Git 文件。

適用於非程式設計師的 Git：

Git 不僅僅適合程式設計師！對於使用基於文字的文件進行協作專案的任何人來說，它都很有價值。使用它來管理文件、設定文件，甚至具有版本控制的創意寫作專案。

高級 Git 主題：

藏匿：

暫時儲存未提交的變更以供以後使用。

子模組：

管理較大專案中不同 Git 儲存庫之間的依賴關係。

變基

：重新組織您的 Git 歷史記錄，以獲得更清晰的線性進展（謹慎使用！）。

將 Git 與不同的工具和 IDE 結合使用：

Visual Studio Code、IntelliJ IDEA 和 Eclipse 等流行的開發工具和 IDE 與 Git 無縫集成，為直接在開發環境中提交、分支和合併程式碼提供了流暢的工作流程。

深入研究 Git：高級技術和高級用戶提示

現在您已經掌握了基礎知識，讓我們為經驗豐富的使用者深入研究進階 Git 概念：

進階分支策略：

功能標誌和分支切換：使用功能標誌管理向特定環境或使用者群組推出新功能。將此與 Git 分支結合起來，建立啟用功能標誌的功能分支，從而允許分階段部署和受控部署。

Git 鏡像：

使用 Git 映像建立遠端儲存庫的同步副本，以實現災難復原或冗餘目的。這會在另一台伺服器上建立儲存庫的完整副本，確保在發生中斷或意外刪除時的資料安全。

高級版本控制的精挑細選和變基：

這些技術提供了對 Git 歷史記錄的精細控制：

採櫻桃：

選擇特定提交並將其從一個分支應用到另一個分支，這對於合併來自修補程式分支的錯誤修復而不合併整個分支非常有用。

變基（互動式）：

透過重新排列、編輯或壓縮提交來重寫 Git 歷史記錄。互動式變基允許對重寫過程進行更細粒度的控制。謹慎使用這些技術，因為它們可以改變合作者所看到的歷史並且需要仔細協調。

Git Porcelain 命令和重構

可拆卸 HEAD 和變基工作流程：

Git 中的 HEAD 指的是目前簽出的提交。可拆卸的 HEAD 可讓您將其與工作目錄分離，從而實現複雜的變基等高級工作流程。這是一個強大但在概念上具有挑戰性的功能。

互動式變基：

如前所述，互動式變基允許以互動方式編輯現有提交並重構 Git 歷史記錄。你可以：

將大型提交拆分為更小、更集中的提交。

將多個提交合併為一個提交。

編輯現有提交的提交訊息。

重新排序致力於反映開發的邏輯流程。

用於日常任務的 Git Porcelain 命令：Git 為各種用例提供了一套強大的「Porcelain」命令：

git add -p (patch):

暫存文件中的特定更改而不是整個文件。

git stash:

暫時儲存未提交的變更以供以後檢索，這對於切換上下文或測試分支很有用。

git lfs (Large File Storage):

使用 Git LFS 在儲存庫中有效管理大型文件（影片、映像），它可以單獨儲存這些文件，而不會增加儲存庫的大小

具有大型程式碼庫的 Git

Git 大檔案儲存 (LFS)：

如前所述，Git LFS 對於管理 Git 儲存庫中的大檔案至關重要。它追蹤存儲庫中的這些文件，但將它們存儲在單獨的位置，從而保持主存儲庫的精簡和高效。

模組化開發的子模組：

將大型專案分解為較小的模組化元件，由單獨的 Git 儲存庫管理。您可以將這些子模組整合到更大的專案（monorepo）中，同時維護每個模組的獨立版本控制。

適用於分散式團隊和持續整合 (CI) 的 Git：

在分散式團隊中利用 Git：Git 在地理分散的團隊中表現出色。就是這樣：

遠端儲存庫：

在 GitHub 或 GitLab 等平台上集中進行版本控制，使每個人都可以無縫地複製、推送和拉取程式碼。

分支策略：

採用 GitFlow 或 GitHub Flow 等清晰的分支策略來管理並發開發並避免衝突。

溝通與協調：

保持清晰的溝通管道並利用拉取請求審查和問題追蹤器等工具進行有效協作。

Git 與 CI/CD 管道整合：

持續整合和持續交付 (CI/CD) 管道可自動執行建置、測試和部署。將 Git 與 CI/CD 管道集成，以便在程式碼變更時自動觸發這些流程：

CI 觸發器：

配置 CI 系統以在程式碼推送到特定分支時觸發建置和測試。

部署自動化：根據成功的建置和測試，自動部署到不同的環境（暫存、生產）。

CI 管道的 Git Hooks：

自訂 Git 掛鉤可以觸發 CI 管道中的特定操作：

預推掛鉤：

在推送程式碼之前執行程式碼品質檢查或單元測試，以防止在到達遠端儲存庫之前出現回歸。

後推掛鉤：

成功推播後觸發部署或自動通知。

Git 用於非程式碼資產的版本控制：

Git 不僅限於程式碼。使用它來管理非程式碼資產的版本控制，例如：

文件:

追蹤文件檔案隨時間的變化。

設定檔：維護開發、登台和生產環境的不同配置。

設計樣機：

版本控制設計資產（例如模型和原型）可輕鬆協作和迭代。

視覺化 Git 歷史記錄：

「git log --graph」等工具或 GitKraken 等圖形用戶端可以以使用者友好的格式視覺化您的 Git 歷史記錄，幫助您一目了然地了解分支和合併活動。

結論

這本綜合指南為您提供了在基礎知識之外駕馭 Git 的知識和技術。請記住，掌握 Git 是一個持續的旅程。繼續練習、試驗這些概念，並利用龐大的線上 Git 社群進行進一步探索。以下是一些可協助您掌握 Git 的額外資源：

官方 Git 文件：https://git-scm.com/ - Git 所有內容的權威來源，包含深入的解釋、命令和教學。

互動式 Git 訓練：https://learngitbranching.js.org/ - 一個學習 Git 基礎並在模擬環境中進行分支和合併實驗的動手平台。

Git SCM 部落格：https://git-scm.com/ - 隨時了解 Git 團隊的最新 Git 開發、新聞和最佳實踐。

線上 Git 社群：Stack Overflow、GitHub Discussions 和 Git 論壇等平台提供了經驗豐富的 Git 用戶的豐富知識和幫助。

透過積極利用這些資源並將新學到的知識付諸實踐，您將成為 Git 高級用戶，準備好應對專案遇到的任何版本控制挑戰。快樂分支！

我很高興有機會今天與您一起深入研究《掌握 Git 版本控制：超越基礎知識》。這是一個令人著迷的領域，具有改善安全狀況的巨大潛力。

感謝您與我一起探索《使用 Git 掌握版本控制：超越基礎》。您持續的興趣和參與推動了這趟旅程！

如果您發現有關使用 Git 進行版本控制：超越基礎知識的討論有幫助，請考慮與您的網路分享！知識就是力量，尤其是在安全方面。

讓我們繼續談話吧！在下面的評論中分享您的想法、問題或經驗《掌握 Git 版本控制：超越基礎知識》。

渴望了解有關 DevSecOps 最佳實踐的更多資訊？請繼續關注下一篇文章！

透過共同努力並採用安全的開發實踐，我們可以建立一個更具彈性和值得信賴的軟體生態系統。

請記住，安全開發之旅是一個持續學習的過程。這是為了持續改進！

原文出處：https://dev.to/gauri1504/mastering-version-control-with-git-beyond-the-basics-44ib