【譯】如何高效的使用 Git

原文連接

https://medium.freecodecamp.o...

代碼昨天仍是運行好好的今天就不行了。

代碼被刪了。

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

若是你出現過上面的任何一種狀況，那本篇文章就是爲你準備的。

除了知道 git add, git commit , git push 以外，Git 中還須要其餘重要的技術須要掌握。長遠來看對咱們是有幫助的。這裏我將向你展現 Git 的最佳實踐。

Git 工做流

當有多個開發者同時涉及到一個項目時那麼就很是有必要正確使用 Git 工做流。

這裏我將介紹一種工做流，它在一個多人大型項目中將很是有用。

前言

忽然有一天，你成爲了一個項目的技術 Leader 並計劃作出下一個 Facebook。在這個項目中你有三個開發人員。

1. Alice：一個開發小白。
2. Bob：擁有一年工做經驗，瞭解基本開發。
3. John：三年開發經驗，熟練開發技能。
4. 你：該項目的技術負責人。

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 代碼是最新的。

咱們如今團隊就是按照這樣的方式進行開發，確實能夠儘量的減小代碼管理上的問題。

題外話

像以前那篇《如何成爲一位「不那麼差」的程序員》說的那樣，建議你們都多看看國外的優質博客。

甚至嘗試和做者交流，通過溝通原做者也會在原文中貼上個人翻譯連接。你們互惠互利使好的文章轉播的更廣。