首先，請不要在更新中提交多餘的白字元（whitespace）。git 有種檢查此類問題的方法，在提交之前，先執行git diff --check，會把可能的多餘白字元修正列出來。下面的示例，我已經把終端中顯示為紅色的白字元用x替換掉：
接下來，請將每次提交限定於完成一次邏輯功能。並且可能的話，適當地分解為多次小更新，以便每次小型提交都更易於理解。請不要在週末窮追猛打一次性解決五個問題，而最後拖到周一再提交。就算是這樣也請盡可能利用暫存區域，將之前的改動分解為每次修復乙個問題，再分別提交和加註說明。如果針對兩個問題改動的是同乙個檔案，可以試試看git add --patch的方式將部分內容置入暫存區域。
如果想要整合新的**進來，最好侷限在特性分支上做。臨時的特性分支可以讓你隨意嘗試，進退自如。比如碰上無法正常工作的補丁，可以先擱在那邊，直到有時間仔細核查修復為止。建立的分支可以用相關的主題關鍵字命名，比如ruby_client或者其它類似的描述性詞語，以幫助將來回憶。git 專案本身還時常把分支名稱分置於不同命名空間下，比如sc/ruby_client就說明這是sc這個人貢獻的。現在從當前主幹分支為基礎，新建臨時分支：
$ git branch sc/ruby_client mastercheckout -b：
$ git checkout -b sc/ruby_client master如果收到的補丁檔案是用git diff或由其它 unix 的diff命令生成，就該用
命令來應用補丁。假設補丁檔案存在/tmp/patch-ruby-client.patch，可以這樣執行：
現在可以發布乙個新的版本了。首先要將**的壓縮包歸檔，方便那些可憐的還沒有使用git的人們。可以使用git archive：
$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz$ ls *.tar.gzv1.6.2-rc1-20-g8c5b85c.tar.gz這個壓縮包解壓出來的是乙個資料夾，裡面是你專案的最新**快照。你也可以用類似的方法建立乙個zip壓縮包，在git archive加上--format=zip選項：
$ git archive master --prefix='project/' --format=zip > `git describe master`.zipgit shortlog命令可以方便快捷的製作乙份修改日誌（changelog），告訴大家上次發布之後又增加了哪些特性和修復了哪些bug。實際上這個命令能夠統計給定範圍內的所有提交;假如你上一次發布的版本是v1.0.1，下面的命令將給出自從上次發布之後的所有提交的簡介：
Pro Git 學習筆記（Branching
分支是 git 的 killer feature git 鼓勵使用者多用分支。生成新的分支 git branch testing切換到另乙個分支 git checkout testing這兩條命令可以合併成 git checkout b testing顯示分支圖 git log oneline de...
《ProGit》閱讀筆記
modified staged 預設編輯器是vim，可以使用如git config global core.editor emacs更換 使用git config list檢查配置資訊，使用git config 檢查某一項配置 獲取幫助 忽略檔案 gitignore檔案 abc 匹配任何乙個列在方括...
git學習筆記2 ProGit2
先附上教程 progit 2 git 自帶乙個 git config 的工具來幫助設定控制 git 外觀和行為的配置變數。這些變數儲存在三個不同的位置 你可能會看到重複的變數名，因為 git 會從不同的檔案中讀取同乙個配置 例如 etc gitconfig與 gitconfig 這種情況下，git ...