标准的Git使用流程

今天发现好多同学Git用的不规范，写篇博客吧

一、先把角色分好，别越位

项目组长

• 负责merge组员的分支。
• 全权管理项目的dev，bugfix，release，master 分支

项目组员

• 只需提交自己的相关的feature分支

 

二、再把分支分好，别弄乱

• master
  稳定的已发布版本，这个分支只能从其他分支合并，不能在这个分支直接修改。
• bugfix
  当线上出现bug，从master分支上创建一个bugfix分支，修复完毕再和dev和master分支合并。
• release
  用于版本发布，当要发布时，我们从dev分支中创建一个release分支来，当发布结束时，再将release分支和dev和master分支合并。
• dev
  主开发分支，包含下个发布版本的代码，主要是从各种feature分支合并，尽量不要在该分支上直接提交。项目组长负责merge该分支的冲突。
• features
  用于开发一个新功能，开发完成后合并到dev分支。每个feature分支只能包含一个功能，不要把多个功能包含在一个分支中。

分支命名规范

• master
  每个项目Only One 
• dev
  每个项目Only One 
• release
  可能会同时有多个版本同时发布。尽量保持只有一个release分支，避免运维发布混淆。
  命名规则尽量带有版本号
• feature
  同时会有多个功能开发，就会有多个feature分支。
  命名规则尽量带有时间和开发人员以及功能
• bugfix
  同时会有多个bug修复，就会有多个bugfix分支。
  命名规则尽量带着时间和修复内容

开发场景

• 功能开发

·        1.组员从线上master或dev分支中创建自己本地feature分支开始功能开发

·        2.开发完成，将feature分支push到线上，提交merge request。

·        3.组长review代码后，将feature分支和dev分支合并。

·        4.定期dev分支上发布版本，进行项目组内的构建和测试。

 

• 版本发布

·        1.组长从dev分支上创建release分支。

·        2.从release分支上进行预发布，提交测试。

·        3.如有bug，从release分支进行修复，流程同功能开发。

·        4.发布成功后，将release分支和dev合并。

·        5.和master分支合并，并打上版本tag。

·        6.删除release分支。

 

• bug修复

·        1.线上发生错误，从master上的相应版本创建bugfix分支。

·        2.在bugfix上修复bug，流程同功能开发

·        3.从bugfix上发布

·        4.发布成功后，将bugfix分支和dev合并

·        5.和master分支合并，并打上版本tag

·        6.删除bugfix分支

 

注意

• 只能从release-和bugfix-分支进行版本发布。
• 请不要merge不能运行的，未测试的代码到dev分支。
• 每个feature只包含一个功能，如有多个功能就多次提交，或多个feature分支。

养成定期清理个人feature分支的习惯，便于运维备份维护。

还有一篇博客写着在这个流程中的一些命令操作，感兴趣的可以参考下啊