Git工作流规范 Beta

Git工作流规范 Beta

前言

正确的 Git workflow 规范，可以适当的减少杂乱提交，形成清晰美观的提交记录树。并方便对于每次新功能的Code Review。

分支说明

• master: 正式版本分支，禁止直接Merge 和 push ,必须在gitee上采用pull request的方式更新（直接操作master很恐怖）
• test: 测试分支
• dev: 开发分支

个人分支/feature分支： 此为个人独有分支，可以只存在本地，也可以上传远端。禁止在个人分支上协作开发。如若上传远端，记得有空清除废弃分支(git branch -D xxx 删除本地分支，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的作用。