英文原文：Understanding the Git Workflow
如果你不理解Git的設(shè)計(jì)動(dòng)機(jī)，那你就會(huì)處處碰壁。知道足夠多的命令和參數(shù)后，你就會(huì)強(qiáng)行讓Git按你想的來(lái)工作，而不是按Git自己的方式來(lái)。這就像把螺絲刀當(dāng)錘子用，也能把活干完，但肯定干的差極了，花費(fèi)很長(zhǎng)時(shí)間，還會(huì)弄壞螺絲刀。
想想常見的Git工作流程是怎么失效的吧。
多數(shù)時(shí)候這樣做的效果會(huì)如你所愿，因?yàn)閺哪銊?chuàng)建分支到合并回去之間，Master一般都會(huì)有些變動(dòng)。然后，有一天當(dāng)你想把一個(gè)功能（feature）分支合并進(jìn)Master的時(shí)候，而Master并沒有像以往那樣有變動(dòng)，問題來(lái)了：這時(shí)Git不會(huì)進(jìn)行合并commit，而是將Master指向功能分支上的最新commit。（看圖）
不幸的是，你的功能分支有用來(lái)備份代碼的commit（作者稱之為checkpoint commit），這些經(jīng)常進(jìn)行的commit對(duì)應(yīng)的代碼可能處于不穩(wěn)定狀態(tài)！而這些commit現(xiàn)在沒法和Master上那些穩(wěn)定的commit區(qū)分開來(lái)了。當(dāng)你想回滾的時(shí)候，很容易發(fā)生災(zāi)難性后果。
于是你就記住了：“當(dāng)合并功能分支的時(shí)候，加上 -no-ff 選項(xiàng)強(qiáng)制進(jìn)行一次全新的commit?！编?，這么做好像解決問題了，那么繼續(xù)。
然后一天你在線上環(huán)境中發(fā)現(xiàn)了一個(gè)嚴(yán)重bug，這時(shí)你需要追溯下這個(gè)bug是什么時(shí)候引入的。你運(yùn)行了bisect命令，但卻總是追溯到一些不穩(wěn)定的commit。因此你不得不放棄，改用人肉檢查。
最后你將bug范圍縮小到一個(gè)文件。你運(yùn)行blame命令查看這個(gè)文件在過(guò)去48小時(shí)里的變動(dòng)。然后blame告訴你這個(gè)文件已經(jīng)好幾周沒有被修改過(guò)了 —— 你知道根本不可能沒有變動(dòng)。哦，原來(lái)是因?yàn)閎lame計(jì)算變動(dòng)是從第一次commit算起，而不是merge的時(shí)候。你在幾周前的一次commit中改動(dòng)了這個(gè)文件，但這個(gè)變動(dòng)今天才被merge回來(lái)。
用no-ff來(lái)救急，bisect又臨時(shí)失效，blame的運(yùn)作機(jī)制又那么模糊，所有這些現(xiàn)象都說(shuō)明一件事兒，那就是你正在把螺絲刀當(dāng)錘子用。
反思版本控制
版本控制的存在是因?yàn)閮蓚€(gè)原因。
首先，版本控制是用來(lái)輔助寫代碼的。因?yàn)槟阋屯峦酱a，并經(jīng)常備份自己的代碼。當(dāng)然了，把文件壓縮后發(fā)郵件也行，不過(guò)工程大了大概就不好辦了。
其次，就是輔助配置管理工作。其中就包括并行開發(fā)的管理，比如一邊給線上版本修復(fù)bug，一邊開發(fā)下一個(gè)版本。配置管理也可以幫助弄清楚變動(dòng)發(fā)生的具體時(shí)間，在追溯bug中是一個(gè)很好的工具。
一般說(shuō)來(lái)，這兩個(gè)原因是沖突的。
在開發(fā)一個(gè)功能的時(shí)候，你應(yīng)該經(jīng)常做備份性的commit。然而，這些commit經(jīng)常會(huì)讓軟件沒法編譯。
理想情況是，你的版本更新歷史中的每一次變化都是明確且穩(wěn)定的，不會(huì)有備份性commit帶來(lái)的噪聲，也不會(huì)有超過(guò)一萬(wàn)行代碼變動(dòng)的超大commit。一個(gè)清晰的版本歷史讓回滾和選擇性merge都變得相當(dāng)容易，而且也方便以后的檢查和分析。然而，要維護(hù)這樣一個(gè)干凈的歷史版本庫(kù)，也許意味著總是要等到代碼完善之后才能提交變動(dòng)。
那么，經(jīng)常性的commit和干凈的歷史，你選擇哪一個(gè)？
如果你是在剛起步的創(chuàng)業(yè)公司中，干凈的歷史沒有太大幫助。你可以放心地把所有東西都往Master中提交，感覺不錯(cuò)的時(shí)候隨時(shí)發(fā)布。
如果團(tuán)隊(duì)規(guī)模變大或是用戶規(guī)模擴(kuò)大了，你就需要些工具和技巧來(lái)做約束，包括自動(dòng)化測(cè)試，代碼檢查，以及干凈的版本歷史。
功能分支貌似是一個(gè)不錯(cuò)的折中選擇，能夠解決基本的并行開發(fā)問題。當(dāng)你寫代碼的時(shí)候，可以不用怎么在意集成的問題，但它總有煩到你的時(shí)候。
當(dāng)你的項(xiàng)目規(guī)模足夠大的時(shí)候，簡(jiǎn)單的 branch/commit/merge 工作流程就出問題了?？p縫補(bǔ)補(bǔ)已經(jīng)不行了。這時(shí)你需要一個(gè)干凈的版本歷史庫(kù)。
Git之所以是革命性的，就是因?yàn)樗芡瑫r(shí)給你這兩方面的好處。你可以在原型開發(fā)過(guò)程中經(jīng)常備份變動(dòng)，而搞定后只需要交付一個(gè)干凈的版本歷史。
工作流程
考慮兩種分支：公共的和私有的。
公共分支是項(xiàng)目的權(quán)威性歷史庫(kù)。在公共分支中，每一個(gè)commit都應(yīng)該確保簡(jiǎn)潔、原子性，并且有完善的提交信息。此分支應(yīng)該盡可能線性，且不能更改。公共分支包括Master和發(fā)行版的分支。
私有分支是供你自己使用的，就像解決問題時(shí)的草稿紙。
安全起見，把私有分支只保存在本地。如果你確實(shí)需要push到服務(wù)器的話（比如要同步你在家和辦公室的電腦），最好告訴同事這是私有的，不要基于這個(gè)分支展開工作。
絕不要直接用merge命令把私有分支合并到公共分支中。要先用reset、rebase、squash merges、commit amending等工具把你的分支清理一下。
把你自己看做一個(gè)作者，每一次的commit視為書中的一章。作者不會(huì)出版最初的草稿，就像Michael Crichton說(shuō)的，“偉大的書都不是寫出來(lái)——而是改出來(lái)的”（“Great books aren’t written – they’re rewritten.”）。
如果你沒接觸過(guò)Git，那么修改歷史對(duì)你來(lái)說(shuō)好像是種禁忌。你習(xí)慣于認(rèn)為提交過(guò)的所有東西都應(yīng)該像刻在石頭上一樣不能抹去。但如果按這種邏輯，我們?cè)谖谋咎幚碥浖髦幸膊粦?yīng)該使用“撤銷”功能了。
實(shí)用主義者們直到變化變?yōu)樵胍舻臅r(shí)候才關(guān)注變化。對(duì)于配置管理來(lái)說(shuō)，我們關(guān)注宏觀的變化。日常commit（checkpoint commits）只是備份于云端的用于“撤銷”的緩沖。
如果你保持公共歷史版本庫(kù)的簡(jiǎn)潔，那么所謂的fast-forward merge就不僅安全而且可取了，它能保證版本變更歷史的線性和易于追溯。
關(guān)于 -no-ff 僅剩的爭(zhēng)論就只?！拔臋n證明”了。人們可能會(huì)先merge再commit，以此代表最新的線上部署版本。不過(guò)，這是反模式的。用tag吧。
規(guī)則和例子
根據(jù)改變的多少、持續(xù)工作時(shí)間的長(zhǎng)短，以及分支分叉了多遠(yuǎn)，我使用三種基本的方法。
1）短期工作
絕大多數(shù)時(shí)間，我做清理時(shí)只用squash merge命令。
假設(shè)我創(chuàng)建了一個(gè)功能分支，并且在接下來(lái)一個(gè)小時(shí)里進(jìn)行了一系列的checkpoint commit。
git checkout -b private_feature_branchtouch file1.txtgit add file1.txtgit commit -am "WIP" 完成開發(fā)后，我不是直接執(zhí)行g(shù)it merge命令，而是這樣：
git checkout mastergit merge --squash private_feature_branchgit commit -v 然后我會(huì)花一分鐘時(shí)間寫個(gè)詳細(xì)的commit日志。
2）較大的工作
有時(shí)候一個(gè)功能可以延續(xù)好幾天，伴有大量的小的commit。
我認(rèn)為這些改變應(yīng)該被分解為一些更小粒度的變更，所以squash作為工具來(lái)說(shuō)就有點(diǎn)兒太糙了。（根據(jù)經(jīng)驗(yàn)我一般會(huì)問，“這樣能讓閱讀代碼更容易嗎？”）
如果我的checkpoint commits之后有合理的更新，我可以使用rebase的交互模式。
交互模式很強(qiáng)大。你可以用它來(lái)編輯、分解、重新排序、合并以前的commit。
在我的功能分支上：
git rebase --interactive master
然后會(huì)打開一個(gè)編輯器，里邊是commit列表。每一行上依次是：要執(zhí)行的操作、commit的SHA1值、當(dāng)前commit的注釋。并且提供了包含所有可用命令列表的圖例。
默認(rèn)情況下，每個(gè)commit的操作都是“pick”，即不會(huì)修改commit。
pick ccd6e62 Work on back buttonpick 1c83feb Bug fixespick f9d0c33 Start work on toolbar 我把第二行修改為“squash”，這樣第二個(gè)commit就會(huì)合并到第一個(gè)上去。
pick ccd6e62 Work on back buttonsquash 1c83feb Bug fixespick f9d0c33 Start work on toolbar 保存并退出，會(huì)彈出一個(gè)新的編輯器窗口，讓我為本次合并commit做注釋。就這樣。
舍棄分支
也許我的功能分支已經(jīng)存在了很久很久，我不得不將好幾個(gè)分支合并進(jìn)這個(gè)功能分支中，以便當(dāng)我寫代碼時(shí)這個(gè)分支是足夠新的的。版本歷史讓人費(fèi)解。最簡(jiǎn)單的辦法是創(chuàng)建一個(gè)新的分支。
git checkout mastergit checkout -b cleaned_up_branchgit merge --squash private_feature_branchgit reset 現(xiàn)在，我就有了一個(gè)包含我所有修改且不含之前分支歷史的工作目錄。這樣我就可以手動(dòng)添加和commit我的變更了。
總結(jié)
如果你在與Git的默認(rèn)設(shè)置背道而馳，先問問為什么。
將公共分支歷史看做不可變的、原子性的、容易追溯的。將私有分支歷史看做一次性的、可編輯的。
推薦的工作流程是：
基于公共分支創(chuàng)建一個(gè)私有分支。
經(jīng)常向這個(gè)私有分支commit代碼。
一旦你的代碼完善了，就清理掉私有分支的歷史。
將干凈的私有分支merge到公共分支中。
聯(lián)系客服
