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

你可能感兴趣的