每天，美團(tuán)的上百名工程師都在不斷改進(jìn)美團(tuán)的用戶體驗(yàn)，或是加入各種新鮮的功能。作為負(fù)責(zé)展現(xiàn)、交互的前端工程師，我們上線的次數(shù)可達(dá)一天數(shù)十次。

我們使用?Stash?托管項(xiàng)目代碼。每個(gè)功能都新增一個(gè)新任務(wù)分支 (feature branch)，當(dāng)開發(fā)測試完成后，推送任務(wù)分支到 Stash 上，并創(chuàng)建 pull request 進(jìn)入代碼審查，直到被通過，等待上線。

為了保證開發(fā)速度，我們不斷改進(jìn)完善這個(gè)發(fā)布流程，讓這個(gè)過程更簡單、高效。

前端工作現(xiàn)狀

前端工作是連接后臺(tái)實(shí)現(xiàn)和視覺表現(xiàn)交互的橋梁，前端工作有以下特點(diǎn)：

• 往往需要和后端工程師合作開發(fā)
• 在測試時(shí)也需要 checkout 后端代碼，并在此基礎(chǔ)上進(jìn)行開發(fā)
• 雙方頻繁 merge/rebase 分支
• 每個(gè)人使用 Git 的方式不太一樣，我們的工作流需要較強(qiáng)的適應(yīng)性
• 在開發(fā)測試完成之后，我們要求每一次上線的代碼都必須經(jīng)過 pull request 加代碼審核

多人合作開發(fā)的一般工作流可以參見?A successful Git branching model?和?Git Workflows，在一般開發(fā)階段使用 merge 或 rebase 都能夠勝任。

但在 pull request 之前我們需要把雙方的提交分開，這個(gè)工作往往還不夠自動(dòng)化。一種常見的做法是?git reset --soft HEAD~?將所有改動(dòng)移出暫存區(qū) (staging area)，然后手工添加那些我們改了的文件。

事實(shí)上，我們可以用 rebase 來幫我們提高效率，實(shí)現(xiàn)自動(dòng)提取、合并提交。

rebase 是什么？

首先簡單介紹一下 rebase（衍合），git-scm 上有很好的介紹（中文翻譯），簡單的說，git rebase A B?會(huì)把在 A 分支里提交的改變移到 B 分支里重放一遍。

它的原理是回到兩個(gè)分支最近的共同祖先，根據(jù) B 的歷次提交對(duì)象，生成一系列文件補(bǔ)丁，然后以 A 為基底分支最后一個(gè)提交對(duì)象為新的出發(fā)點(diǎn)，逐個(gè)應(yīng)用之前準(zhǔn)備好的補(bǔ)丁文件，最后會(huì)生成一個(gè)新的合并提交對(duì)象，從而改寫 B 的提交歷史，使它成為 A 分支的直接下游。

通過修改提交歷史，我們可以更方便的準(zhǔn)備 pull request。

用 git rebase 來提取、合并提交

比如說后端的 Alice 和前端的 Bob 合作開發(fā)一個(gè)功能，他們分別從 master 分支上 checkout，并開始工作。

他們互相 merge 對(duì)方的分支的進(jìn)行開發(fā)、測試。最終，這個(gè)功能開發(fā)測試完成，Bob 合并了 Alice 的分支（圖中星號(hào)的位置），可以進(jìn)入代碼審核和上線的流程了。

這時(shí)候 Alice 和 Bob 需要提取、合并各自的提交，并分別發(fā)送 pull request 進(jìn)入代碼審核。我們站在 Bob 的角度來解釋一下如何使用 rebase 來方便的做到這一點(diǎn)。

Bob 現(xiàn)在處在 bob/fb 上（圖中星號(hào)的位置），這時(shí)候 bob/fb 實(shí)際上包含了 alice/fb 的所有提交。首先我們從 bob/fb 上新建一個(gè)分支

// 準(zhǔn)備一個(gè)新的分支 $ git checkout -b bob/review

然后我們通過 rebase 把自己的提交排到一起

// 把 Alice 的提交和自己的提交分別排在一起 $ git rebase alice/fb

接下來我們把 bob/review 上的提交合并

// 用 interactive rebase 合并提交 $ git rebase -i HEAD~`git rev-list --first-parent master...bob/fb --no-merges --count`

執(zhí)行上面這行命令會(huì)打開終端默認(rèn)的編輯器（可通過 EDITOR 環(huán)境變量設(shè)置）。

這些信息表示從在 bob/review 上找到了兩個(gè)在 bob/fb 上的提交。每個(gè)提交都另起一行來表示，行格式如下：

(action) (partial SHA-1) (short commit message)

按照下面的提示，我們可以把除了第一行外的 pick 替換成 fixup (f) 或是 squash (s) 來實(shí)現(xiàn)合并提交。另外，上下移動(dòng)一行可以對(duì)提交進(jìn)行重排序。一旦你完成對(duì)提交信息的編輯，并退出編輯器，git 會(huì)按照你指定的順序去應(yīng)用提交，并且做出相應(yīng)的操作（action），形成的新提交和提交信息會(huì)被保存起來。(備注：在 Git 1.7 之后，我們還可以使用?rebase --autosquash?自動(dòng)合并提交，進(jìn)一步提高生產(chǎn)效率。)

合并完之后我們的分支是這樣的

然后，我們可以使用?rebase --onto?取出 bob/review 上有而 alice/fb 上沒有的提交，并指定新的基底分支（也就是主干分支 master）

// 取出 Bob 的提交，并排除 alice/fb 上的提交 git rebase --onto master alice/fb bob/review

這樣在 bob/review 分支上就只有 Bob 自己的提交了。

這時(shí)候就可以用?git merge master?或者?git rebase master?來更新分支，然后發(fā)送 pull request 進(jìn)入代碼審核環(huán)節(jié)了。

小結(jié)

以上是我們處理代碼審查之前提取、合并提交的一點(diǎn)思考和實(shí)踐。例子中命令雖然長，但可以很方便的寫成一個(gè)腳本自動(dòng)進(jìn)行，除非遇到?jīng)_突，否則需要人工干預(yù)的情況并不多在。在美團(tuán)，我們一直努力用好現(xiàn)有工具，降低重復(fù)操作，讓工具自動(dòng)化融入工作流程之中，成為我們不斷提升工作效率的重要幫手。希望我們的實(shí)踐能對(duì)你有幫助。

from:?http://tech.meituan.com/improving-git-flow_squashing-commits.html

總結(jié)

以上是生活随笔為你收集整理的改进合作 Git 工作流：自动提取、合并提交的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。