Git工作流規範 Beta

摘要： Git工作流規範 Beta 前言 正確的 Git workflow 規範，可以適當的減少雜亂提交，形成清晰美觀的提交記錄樹。並方便對於每次新功能的Code Review。 分支說明 master: 正式版本分支，禁止直接Merge 和 push ,必須在...

Git工作流規範 Beta

前言

正確的 Git workflow 規範，可以適當的減少雜亂提交，形成清晰美觀的提交記錄樹。並方便對於每次新功能的Code Review。

分支說明

• master: 正式版本分支，禁止直接Merge 和 push ,必須在gitee上採用pull request的方式更新（直接操作master很恐怖）
• test: 測試分支
• dev: 開發分支

個人分支/feature分支：此為個人獨有分支，可以只存在本地，也可以上傳遠端。禁止在個人分支上協作開發。如若上傳遠端，記得有空清除廢棄分支(git branch -Dxxx 刪除本地分支，git push --delete origin/xxx 刪除遠端分支）

工作流說明

dev新功能開發：

1. 從最新的dev分支 checkout -b 一個feature分支 或 合併進 個人分支
2. 進行開發，可以隨時並且多次地commit。commit內容可以隨意，但一定要自己知道幹了啥
3. 開發完成，checkout切到dev分支，pull -rebase 一下遠端的程式碼，在最新程式碼下merge一下自己新開發的功能分支
4. 解決衝突，最後push到dev
5. 如果上線新版本，在gitee 上 pull request更新master分支（嚴禁直接操作master分支）

備註: 如果希望你的commit太雜亂，希望歸結到一條清爽無比 git rebase -i HEAD~x 來合併commit 提交記錄。(x表示之前的多少次提交，具體可以百度，暫時不對commit對要求)

幾個注意事項：

1. 多人協作分支（master、test、develop），禁止使用rebase(除非你已經是Git大師級別的人物），禁止git push --force。 （反正目前只允許在個人分支中使用rebase)
2. 每開發完一個功能，建議合併到develop，你個人分支與develop脫節越久，rebase時產生衝突的機率和影響範圍就越大。
3. 如果你對git rebase 不熟悉，建議先只在個人分支使用rebase來精簡提交記錄。 合併develop時產生的merge commit 暫時可以被接受。
4. 各種環節中，一旦出現merge commit，不用再像之前那樣填寫完整的commit message了，建議使用預設的message即可。（否則會有相同語義的message，影響美觀）。
5. 關於merge和rebase的區別，可以閱讀http://blog.csdn.net/hudashi/... 。 建議自己學會使用搜索引擎進行學習。
6. 建議自己弄個專案，把各種場景模擬一下，先玩一玩試試。
7. 具備一定程度以上的好奇心，比如rebase -i 中其他幾種command的作用。