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 的作用。