代码管理规范

git提交规范

说明：将git分支分为主分支和临时分支。

主分支：test（测试）、pre（预发布）、prod（生产）
临时分支：需求点和bug修改
开发与提交流程

• 每个修改点（需求或bug）都要从prod新拉分支
• 合代码（合代码时都是从临时分支cherry pick到目的分支（主分支））
• 往test分支合代码时，需要先把自己的临时分支压缩为一个点，再cherry pick到test。
• 往pre分支合代码时，从临时分支cherry pick到pre分支，不要从test分支cherry pick。（因为test肯定有没测试的，不能上pre）
• 往prod分支合代码时，组员告诉组长自己的提交点，由组长从临时分支cherry pick到prod分支（因为pre肯定有没测试的，不能上正式）
• 远程有更新时，要rebase（以远程为基准），不要用merge（以本地为基准）
• 修改点上线（临时分支cherry pick到master）后，删除临时分支（防止分支过多）
• 定期（两三周）对test进行清理，删除test并重新从prod拉分支，作为test分支。（防止test与prod差距较远，导致临时分支往test分支合代码时冲突很多）
• 定期（两三周）对pre进行清理，删除pre并重新从prod拉分支，作为pre分支。（防止pre与prod差距较远，导致临时分支往pre分支合代码时冲突很多）

优点

按这个流程来做，可以做到：合代码基本不出问题、合代码速度快（一般不会超过3分钟）。

原因

以上步骤每一步都是有原因的：

• 从prod拉新分支：可保证新分支代码是基于生产的，可以保证新分支是纯粹的自己的修改点
• 合代码时都是从临时分支cherry pick到目的分支：可保证不会将其他人代码合到目的分支
• 使用rebase而不是merge：git提交清晰，而且这是人类的正常思维：以服务器的代码为准，而不是以自己本地的代码为准。
• 定期删除test、pre并从prod拉分支：从临时分支合到主分支时基本不会有冲突；而且可以删除test里无用的代码

感言

一个正常的功能点，如果合代码超过10分钟，那么，项目的git管理大概率有问题。如果超过30分钟，项目的git管理问题有点儿大。如果超过一个小时，那么…😦