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