如何高效的使用 Git

良許Linux發表於2019-05-07
Git

程式碼昨天還是執行好好的今天就不行了。

程式碼被刪了。

突然出現了一個奇怪的 bug，但是沒人知道怎麼回事。

如果你出現過上面的任何一種情況，那本篇文章就是為你準備的。

除了知道 git add、git commit、git push 之外，Git 中還需要其他重要的技術需要掌握。長遠來看對我們是有幫助的。這裡我將向你展示 Git 的最佳實踐。

Git 工作流

當有多個開發者同時涉及到一個專案時那麼就非常有必要正確使用 Git 工作流。這裡我將介紹一種工作流，它在一個多人大型專案中將非常有用。

前言

突然有一天，你成為了一個專案的技術 Leader 並計劃做出下一個 Facebook。在這個專案中你有三個開發人員：

  • Alice：一個開發小白
  • Bob：擁有一年工作經驗，瞭解基本開發
  • John：三年開發經驗，熟練開發技能
  • 你：該專案的技術負責人

Git 開發流程

Master 分支

  1. Master 分支應該始終和生產環境保持一致。
  2. 由於 master 和生產程式碼是一致的，所以沒有人包括技術負責人能在 master 上直接開發。
  3. 真正的開發程式碼應當寫在其他分支上。

Release（釋出）分支

  1. 當專案開始時，第一件事情就是建立釋出分支。釋出分支是基於 master 分支建立而來。
  2. 所有與本專案相關的程式碼都在釋出分支中，這個分支也是一個以 release/ 開頭的普通分支。
  3. 比如這次的釋出分支名為 release/fb。
  4. 可能有多個專案都基於同一份程式碼執行，因此對於每一個專案來說都需要建立一個獨立的釋出分支。假設現在還有一個專案正在並行執行，那就得為這個專案建立一個單獨的釋出分支比如 release/messenger。
  5. 需要單獨的釋出分支的原因是：多個並行專案是基於同一份程式碼執行的，但是專案之間不能有衝突。

Feature（功能分支）branch

  1. 對於應用中的每一個功能都應該建立一個獨立的功能分支，這會確保這些功能能被單獨構建。
  2. 功能分支也和其他分支一樣，只是以 feature/ 開頭。
  3. 現在作為技術 Leader，你要求 Alice 去做 Facebook 的登入頁面。因此他建立了一個新的功能分支。把他命名為 feature/login。Alice 將會在這個分支上編寫所有的登入程式碼。
  4. 這個功能分支通常是基於 Release（釋出）分支 建立而來。
  5. Bob 的任務為建立新增好友頁面，因此他建立了一個名為 feature/friendrequest的功能分支。
  6. John 則被安排構建訊息流，因此建立了一個 feature/newsfeed 的功能分支。
  7. 所有的開發人員都在自己的分支上進行開發，目前為止都很正常。 8.現在當 Alice 完成了他的登入開發，他需要將他的功能分支 feature/login 傳送給 Release（釋出）分支。這個過程是通過發起一個 pull request 完成的。

Pull request

首先 pull request 不能和 git pull 搞混了。

開發人員不能直接向 Release發（布）分支推送程式碼，技術 Leader 需要在功能分支合併到 Release（釋出）分支之前做好程式碼審查。這也是通過 pull request 完成的。

Alice 能夠按照如下 GitHub 方式提交 pull request。

在分支名字的旁邊有一個 “New pull request” 按鈕，點選之後將會顯示如下介面：

  • 比較分支是 Alice 的功能分支 feature/login。
  • base 分支則應該是釋出分支 release/fb。

點選之後 Alice 需要為這個 pull request 輸入名稱和描述，最後再點選 “Create Pull Request” 按鈕。

同時 Alice 需要為這個 pull request 指定一個 reviewer。作為技術 Leader 的你被選為本次 pull request 的 reviewer。

你完成程式碼審查之後就需要把這個功能分支合併到 Release（釋出）分支。

現在你已經把 feature/login 分支合併到 release/fb，並且 Alice 非常高興他的程式碼被合併了。

程式碼衝突

  1. Bob 完成了他的編碼工作，同時向 release/fb 分支發起了一個 pull request。
  2. 因為釋出分支已經合併了登入的程式碼，這時程式碼衝突發生了。解決衝突和合並程式碼是 reviewer 的責任。在這樣的情況下，作為技術 Leader 就需要解決衝突和合並程式碼了。
  3. 現在 John 也已經完成了他的開發，同時也想把程式碼合併到釋出分支。但 John 非常擅長於解決程式碼衝突。他將 release/fb 上最新的程式碼合併到他自己的功能分支 feature/newsfeed （通過 git pull 或 git merge 命令）。同時他解決了所有存在的衝突，現在 feature/newsfeed 已經有了所有釋出分支 release/fb 的程式碼。
  4. 最後 John 建立了一個 pull request，由於 John 已經解決了所有問題，所以本次 pull request 不會再有衝突了。

因此通常有兩種方式來解決程式碼衝突：

  • pull request 的 reviewer 需要解決所有的程式碼衝突。
  • 開發人員需要確保將釋出分支的最新程式碼合併到功能分支，並且解決所有的衝突。

還是 Master 分支

一旦專案完成，釋出分支的程式碼需要合併回 master 分支，同時需要釋出到生產環境。因此生產環境中的程式碼總是和 master 分支保持一致。同時對於今後的任何專案來說都是要確保 master 程式碼是最新的。

本文轉載自【Docker】

原文連結：https://medium.freecodecamp.org/how-to-use-git-efficiently-54320a236369

更多精彩內容，請關注公眾號良許Linux，公眾內回覆1024可免費獲得5T技術資料，包括：Linux，C/C++，Python，樹莓派，嵌入式，Java，人工智慧，等等。公眾號內回覆進群，邀請您進高手如雲技術交流群。

img


相關文章