Git使⽤规范
⽂章⽬录
⼀、简介
Git是分布式版本控制系统，与之对应另⼀种常⽤的SVN是集中式版本控制系统。它们的差异很⼤，主要是源于它们的设计思想，这⾥就不展开细说，⼤家可以⾃⾏查找资料。总体来说，Git更灵活、对⼯作环境依赖更⼩、更适合多⼈团队的协同⼯作，但是学习成本更⾼，如果仅仅是⽤Svn的⽅式去使⽤它，那就⼏乎和Svn⼀样没有什么学习成本，但是之所以选择了Git，就是要充分利⽤它的优点，从⽽使我们的项⽬代码管理更加有效、合理，提⾼协同⼯作效率。互联⽹上Git托管平台有：GitHub，国内的有Gitee。
⼆、分⽀
1、概念
在Git使⽤过程中，我们从始⾄终都在和分⽀打交道，分⽀可以说是最重要的，也是使⽤Git所必须要掌握的⼀个点。
分⽀的概念很好理解，顾名思义，就像⼀颗树，从主⼲出来可以衍⽣⽆数个树枝，但是在Git梦见包
中没有实际上的主⼲，每个分⽀都是可以作为主⼲，因为每个分⽀就是⼀个副本，每个分⽀都可以不依赖于其他分⽀。通常在项⽬建⽴后，我们会⼈为的确认⼀条分⽀作为主⼲，这条主⼲将放在我们的中央存储仓库中，提供给各开发⼈员作为基线。
在Git中，当新创建了仓库后，就会默认创建⼀个分⽀，名称为master，我们可以在该分⽀上创建多次提交，并以任意提交为基础，新创建任意个分⽀。（注意：如果master还未创建提交，此时新创建了分⽀，那么此操作相当于对master分⽀进⾏重命名）。 如上图，共存在5个分⽀，不同的开发⼈员可以并⾏的在不同分⽀上进⾏编码⼯作并提交，它们之间互不影响。
⼀个项⽬在持续开发和迭代中主要有⼏个阶段：功能开发、问题修复、版本发布、紧急问题修复、版本迭代。这个过程中，每个阶段并不是完全是时间顺序的，可能是并⾏的，也可能涉及到多⼈的协同⼯作。但最终⽬的是输出稳定的发布版本，Git分⽀对这个过程的⼯作提供了强⼤⽽灵活的⽀持。
2、原则
虽然可以在任意分⽀上创建任意个⼦分⽀，但是在实际项⽬开发过程中，团队内部需要制定⼀个规则⽤于指导分⽀的创建，⽐如：创建时机 通常是在开发⼈员接收到新功能需求或者被指派了问题修复任务时，需要以主分⽀或者开发主分⽀为基础新创建出⼦分⽀。
⽤途 需要明确分⽀的⽤途，即它是⽤于开发新功能，还是⽤于修复问题，必须确保它的⽤途单⼀，不能混合在⼀起。⽐如不允许⼀个分⽀即⽤于新功能开发，同时⽤于问题修复（同个功能需求内的除外），这样不利于问题的追溯。
命名规范 分⽀的命名相对⽐较⾃由，但有⽐要定义⼀下团队内部的规范，通常是根据⽤途进⾏命名，⽐如新功能分⽀以feature/为前缀，加上功能名，如：feature/sms_login，问题修复分⽀以fix/为前缀，加上问题描述，如：fix/ur_table_query_fail。
3、协同
⽅才所说，分⽀本质上是独⽴互不依赖的，这为团队协同⼯作提供了极⼤便利性，但是⼀个版本或者⼤功能的完整性则需要集合各分⽀上的代码，因此需要指定⼀个分⽀作为主分⽀，当其他分⽀上的代码已编码结束并完成测试时，需要把该分⽀的提交整合到主分⽀，这个操作叫做合并，协同⼯作因此变为可能。
三、合并
对Git分⽀进⾏合并操作有两种⽅式，merge和reba，它们的设计思想有较⼤不同，在实际的项⽬开发中，应⽤的场景也有所不同。
1、merge
合并，把指定分⽀（假设为分⽀B）的代码修改合⼊到当前分⽀（假设为master），它提供了两种模式：Fast Forward 快进模式，合并后会直接将当前分⽀master的HEAD指向指定分⽀B的HEAD。
No Fast Forward 在合并时会⽣成⼀个新的提交到当前分⽀master，该提交包含了指定分⽀B的所有私有提交。
两种模式的模型图：
如果当前分⽀master和要合并的分⽀B都有⾃⼰独有的提交时（即合并的分⽀B与当前分⽀master的最近公共提交不是当前分⽀master的最新提交），则⽆法使⽤Fast Forward进⾏合并。 两种模式⽐较：
Fast Forward 优点： （1）当有⼤量分⽀，且进⾏⼤量合并时，该模式不会产⽣⼤量的分⽀合并记录，使提交记录图谱看起来更简洁清晰。 （2）避免在当前分⽀产⽣冲突，规定了指定的分⽀必须是基于当前分⽀的最新提交，可以从机制上降低当前分⽀风险。 缺点： （1）由于丢失了分⽀合并信息，⽆法追溯分⽀合并历程。
No Fast Forward 优点： （1）保留每次的分⽀合并信息，⽅便追溯分⽀历程。 缺点： （1）当分⽀合并次数太多时，提交记录的图谱不够简洁，不便利阅读和分析。 （2）容易在当前分⽀产⽣冲突，需要⼿动去解决冲突，从机制上增加了当前分⽀代码稳定性的风险。
Git进⾏merge时默认使⽤Fast Forward，不成功时则⾃动切换为No Fast Forward，可以在merge时⼿动指定使⽤哪种模式。2、reba
变基，本质是丢弃当前分⽀现有的提交，然后把HEAD移动到另⼀个分⽀的HEAD，最后把当前分⽀已丢弃提交的内容重复提交⼀遍，这样就实现了把指定分⽀的提交同步到当前分⽀的效果。注意： 被丢弃的提交并不会被删除，实际上还会占⽤磁盘空间。 由上⾯的模型可以看到，变基后的分⽀B，master分⽀可以使⽤Fast Forward对它进⾏合并。注意： 使⽤reba，提交记录的时间并不⼀定是按照顺序的。
3、原则
合并提供了多种⽅式，它们各有优缺点，采⽤哪种⽅式主要是看项⽬团队⾃⼰的喜好和风格。基于经验之谈，很多公司都是采⽤这样的原则：
公共分⽀
⼀般规定要使⽤merge操作的Fast Forward模式进⾏合并，这是为了保证提交记录的线性显⽰，同时降低了代码冲突风险。说明： 保留分⽀合并信息实际上对⼤多数项⽬来说并⽆多⼤意义且增加了风险控制成本。
私有分⽀
私有分⽀⼀般只由⼀个开发⼈员维护，通常都是⼦分⽀，因此它的基点可能会落后与主分⽀，此时规定使⽤reba操作，把私有分⽀变基到主分⽀的最新提交。这样的好处是，⽅便当前分⽀的回退到某次提交，⽽且当主分⽀需要合并私有分⽀时可以使⽤Fast Forward。说明： 私有分⽀在被合⼊主分⽀后，⼀般需要把它删除。
四、代码管理规范
1、⽬的
规定了公司软件代码管理规范。
提⾼协同开发效率。
提⾼代生命的句子
码稳定性和可追溯性。
2、适⽤对象
Git管理员
开发主管
开发⼈员
测试⼈员
3、原则
⾓⾊职责权限
Git管理员
1、创建仓库
2、检查分⽀规范创建、修改
3、维护后台系统
开发主管1、管理项⽬公共分⽀（master、develop）
2、成员管理
3、标签（tag）管理
4、代码审核
创建、修改
开发⼈员1、创建私有分⽀（功能分⽀、Bug修复分⽀）
2、代码开发和提交
3、提交MR（合并请求）
修改
测试⼈员对master和develop版本进⾏测试查看
⾓⾊职责权限
4
、分⽀管理
主分⽀（ma骨裂怎么治疗
ster） &nbs春节古诗四句
p; 提供了最稳定的版本，只合并develop和hotfix，合并后需要打tag（⽤于标识版本），可⽀持随时从指定的tag处发布版本到线上。必须有以下特性：
不允许直接commit和push，只能通过MR合并。
限制merge权限，只允许指定⼈员（通常是开发主管）执⾏。
只允许满⾜Fast Forward条件的合并。
开发分⽀（develop） 始终保持最新的代码和bug的修复，进⼊新版本迭代时，必须新创建⼀个开发分⽀，命名规范：develop/版本号，⽰例：develop/3.0.1。必须有以下特性：
不允许直接commit和push，只能通过MR合并。
限制merge权限，只允许指定⼈员（通常是开发主管）执⾏。
只允许满⾜Fast Forward条件的合并。
每次合并前都需要进⾏CR。
只有功能完整并测试稳定后，才允许向master提交MR。
功能分⽀（feature） 开发新功能时，必须以develop书籍尺寸
为基础新创建⼀个功能分⽀，命名规范：feature/功能名，⽰例：feature/finger_login。 &稻城亚丁几月去好
nbsp; 该分⽀为开发⼈员的私有分⽀，通常只有⼀个开发⼈员在此分⽀进⾏代码修改和提交，当⾃测没问题时，才可以提交MR到develop，并告知develop的负责⼈（通常是开发主管）进⾏合并，合并后本分⽀需要删除。**注意：**在功能开发过程中，develop分⽀可能有了新的提交，那么develop的合并将会失败，必须先在本分⽀reba到develop后再提交MR，不能使⽤merge操作，根据经验，开发过程中最好经常pull下远端的develop，然后对本分⽀进⾏reba下。
修复分⽀（fix） 版本开发期间，若有发现bug，必须以develop为基础新创建⼀个修复分⽀，命名规范：fix/问题简述，⽰例：fix/com_data_loss。 该分⽀为开发⼈员的私有分⽀，其开发和合并过程同功能分⽀。
紧急修复分⽀（hotfix） 在某个版本上线后，若发现了需要紧急修复的bug，则必须从master的最新提交新创建⼀个紧急修复分⽀，命名规范：hotfix/版本号_问题简灵芝如何食用
述，⽰例：hotfix/3.0.0_login_crash。 该分⽀为开发⼈员的私有分⽀，需要测试验证没问题后，才可以提交MR到master，注意： 若master已经有新的提交，需要先reba。 爱国作文400字
通常合⼊到master后，develop也要跟着合⼊此修复，develop合⼊过程：
如果此hotfix分⽀产⽣了⼏⼗上百个⼤量的提交，则：使⽤merge⽅式把master合⼊到develop/3.0.1，此种⽅式会产⽣额外的分⽀合并信息。
如果此hotfix分⽀只产⽣少量⼏个提交，则：使⽤reba⽅式把develop/3.0.1变基到master，然后强制推送到远端仓库（使⽤--force-with-lea选项）。
以上两种⽅式，基于develop开发分⽀创建的其他分⽀都需要重新变基到develop。尽量使⽤reba⽅式以保持统⼀风格。
5
、⼯作流
6、⽇志规范
每次在分⽀上进⾏提交时，都需要添加提交⽇志，且遵循⼀定的⽇志说明规范，这样有利于问题追溯，同时可以利⽤⼯具根据每个提交⾃动⽣成CHANGELOG。
