Git版本控制的最佳实践

分支描述

• Master分支（主分支。上线前，必须确保 master 分支时刻是一个可以发布给客户演示版本。上线后，必须确保 master 分支时刻是一个可以发布给客户使用版本。）
• Develop分支（开发分支，开发新功能，开发过程中的“主”分支）
• HotFix分支（用于上线后，出现bug，需要从Master分支checkout出一个hotfix分支，命名规则为“hotfix”+解决问题名+时间。例如：“hotfixHiddendangerSubmitError20160820”。Bug解决并测试通过后merge到Master并删除该分支）
• 各个开发人员自己的独有分支

开发过程中要遵循共同的工作流程

每开始一个项目都要先创建一个Master分支和一个Develop分支，Master分支起初为一个空的项目，在develop分支上作为开发的主分支，直到develop分支可以生成一个可以发布给客户的版本，再merge到Master分支，之后，开发过程中每次大的节点（给客户演示或者完成一轮测试）都要从develop分支merge到Master分支一次，平时不做Merger。任何开发人员都不允许直接修改Master分支，也就是说Master分支代码的来源只能是开发过程中从Develop分支merge和上线后从hotfix分支merge。

开发过程中，开发人员从develop分支获取最新代码进行各自开发，完成一个功能后并测试通过后及时向develop分支merge。确保develop分支必须能编译通过，单元测试通过。至少每天一次。

具体操作注意事项：

1. 开发过程中至少每天Merge一次Develop分支的代码到各自的分支

由于多人同时进行开发工作，所以为了防止当前develop分支与当前自己的分支中，存在冲突代码，就要求开发过程中，每个人需要每天merge主干代码。以保证及早发现冲突问题，及早解决冲突问题。

过程：

1、保证当前分支代码干净后（无修改，全更新），切换至develop分支。

2、获取develop最新代码至本地。

3、切换回自己的分支，执行merge develop，合并。

4、观察合并后列出的结果，查看是否未能自动merge文件。如果存在both modified 也表明存在冲突。根据显示的路径进入存在未解决冲突的文件，Git会将冲突用会这组 >>>> == <<<< 符号进行分割。==分割了相互冲突的代码，解决冲突后，即可删除这组符号。解决所有冲突后重新编译。

1. 一次只提交一个功能模块/bug改动（或相关联的一组改动）到develop

比如，修复两个不同的bug，应该是两次提交。小型提交，使其他人更易理解那些更新。当出错时，也更容易回滚。

1. 经常性提交到develop

经常性地提交改动可以确保不会出现特别庞大的提交，同时也可以比较精准地对应到所需要的改动上。此外，通过频繁地提交也可以比较快速地和其他开发人员来共享你的改动。同样也会避免在整合代码时出现过多的合并冲突。相反的，非常庞大的提交会加大整合代码时出现冲突的风险，解决这些冲突也会非常复杂。

1. 不要提交不完整的改动

只有当功能完成或者不敢修复后才提交。如果是一个比较大的新功能，必须把那些改动正确地分割成一些有意义的逻辑模块来进行频繁地提交。如果你分支没有完成,不要合并回Develop分支。

1. 提交前测试那些改动

所有提交的代码必须经过自己的单元测试才能提交。如果到了下班时间还没有完成，至少要保证编译通过再提交到本地仓库。但决不能merge到develop。

1. 高质量的提交注释

这个常我们所忽视。提交注释的标题需要一个少于50个字符的简短说明。注释通常包含两个方面：出于什么原因需要进行这次修改？具体改动了些什么？

1. 仔细检查config的设置，不要用自己本地的覆盖了服务器上的。
2. 解决冲突后，一定要测试！！！