Git使用心得分享

這寫都是我個人的約定，你可以取其精華或忽略它，但是你和你的團隊最好要有一些某種形式上的約定！:)

尊重現有項目的約定

這種情況並不多見，但是當你往一個你可以直接訪問的開源項目中提交代碼或補丁時，你最好花幾分鐘的時間了解一下該項目以前的提交記錄，並且了解一下該項目的作者是怎樣組織文件的。

為提交信息添加動詞前綴

當你往一個主分支(one that won't be squashed)提交代碼時，你最好為所有的提交信息加上前綴，或者至少為絕大部分的提交信息加上標准化的動詞前綴。何時添加以及添加的頻率有你決定，但是最好使用標准化的動詞，這可以更容易的快速浏覽。我喜歡用"add", "remove", "update", "refector", "fix" 等，如下所示：

* bafaeac TJ Holowaychuk — add mixin property array support
* e9df63a TJ Holowaychuk — remove opacity plugin. Closes #29
* c5b1e85 TJ Holowaychuk — remove media macros. Closes #36

更新依賴的時候做個記錄

當你更新你項目中的某個依賴時，你也許僅僅只用"update foo"類似這樣的信息來提交你的代碼，但是如果是出於某些原因你需要更新依賴，你最好為你的提交信息做一個簡單的記錄，這會對該項目的其他開發者（或者以後的你）很有幫助。

分支名稱

這裡沒有什麼特殊的，我通常會使用提交信息中同樣的約定來命名分支，像 “add/my-feature”, “remove/old-feature”, “fix/crazy-bug”。

合並提交

在你自己的代碼庫或當你向其他項目貢獻代碼時，你最好保持一個清晰的提交記錄，至少也要足夠清晰以免把你自己搞亂。其中一個重要的方面就是在適當的時候“合並(squashing)”提交記錄來形成一個單個的提交記錄。

這是一個有點爭議的話題，因為將多個提交合並成一個會使得二分查找(bisecting)更見困難，但是對於一些小的修改，這往往會有助於提交記錄的清晰。

舉例來說，如過某個人向你的項目中發送了一個pull-request來修復一個bug，但是這個pull-request包含3個提交記錄，如下所示。你很可能不會關心最上面和最下面的那兩個提交記錄，你可能只需要一個包括了test和fix在內的提交，這可以更容易的恢復(revert)，更容易的在你的主分支中進行浏覽，只要聚焦於這些修改，也同樣容易進行二分查找(bisect)

- fix typo
- fix something. Closes #123
- add test for fixing something

你真正想要的是：

- fix something. Closes #123

你可以使用 git-extras 中的 git-squash(1) 命令來實現它，盡管我相信某一個GIT大神會給出一個內建(build-in)的解決方案。

EDIT: @defunctzombie 建議只需簡單的使用 reset —soft，之後再重新提交修改即可。這種方法和git-squash(1)之間的唯一區別是後者會合並(squash)整個分支（要小心！！）。

EDIT 2: 最終發現git-merge 有一個--squash 選項可以有效的完成git-squash的工作，所以沒有必要再多做介紹如何使用了。下面是它的用戶手冊的一個片段：

 —squash, —no-squash
 Produce the working tree and index state as if a real merge happened (except for the merge information), but do not
 actually make a commit or move the HEAD, nor record $GIT_DIR/MERGE_HEAD to cause the next git commit command to
 create a merge commit. This allows you to create a single commit on top of the current branch whose effect is the
 same as merging another branch (or more in case of an octopus).

短暫的分支

對於一些我確定我會合並的短暫分支來說，在提交時，我會去掉功能相關的前綴。例如，在一個名為 fix/facebook-auth 的分支中有兩個常規的提交“fix facebook oauth integration” 和 “add test for facebook oauth integration bug”, 我通常只會像這樣提交，"add test"，“fix integration”，這樣它們依舊有意義，但是這可以為你節省很多時間。

留下一份記錄

大部分人都會這麼做但我還想強調一下,告訴使用者去“查看提交日志”是不友好的. 當你提交一個版本後，大家只想看到更改部分的日志, 或是排序後的日志，可以方便的看到那些是添加的，修改的，刪除的等等.

我用的是 git-change log(1) 來生成更改日志, 如果你還需要更嚴格的日志記錄，那也許不需要像git-change log(1) 那樣的處理.

關閉和引用

我想大部分 GitHub-ers都知道這個功能，但我還要再強調一下. 如果提交了 “Closes #123" 字樣的字符串，Github就會關閉這個條目，並創建該條目的注釋引用.

引用的時候也一樣, 在注釋中寫上 “#123" 以分類標識, 這是Github一個不起眼卻很強大的功能，最好能合理應用.

提交的標簽

我是不太使用這條功能，但我會積極嘗試. 比如生成了更新日之後還是需要分出哪些是“真正的” 更新, 誰也沒法確保提交日志的准確 — 但如果在相應的提交記錄裡添加#change或是[change]標簽, 區分起來就很容易了.

其他人也會使用#ui, #ux 或其他類似標簽來標識, 我想不管從統計的角度或是易讀性方面都很好.

我們在 Cloudup的提交都加上了相關模塊名字的前綴. 這樣確實是模塊化的開發，但卻影響了後續的代碼提交. 比如 “add gravatar support to signup”, 可以這麼寫“signup: add gravatar support”, 這樣能讓人們更容易識別.

還有其他好的建議?

以上都是我的一些使用心得，如果在你的工作中發現了其他更有效的使用方法，請不吝賜教。

在Ubuntu Server上安裝Git http://www.linuxidc.com/Linux/2009-06/20421.htm

服務器端Git倉庫的創建（Ubuntu） http://www.linuxidc.com/Linux/2011-02/32542.htm

Linux下Git簡單使用教程（以Android為例） http://www.linuxidc.com/Linux/2010-11/29883.htm

Git權威指南 PDF高清中文版 http://www.linuxidc.com/Linux/2013-10/91053.htm

Git 的詳細介紹：請點這裡
Git 的下載地址：請點這裡