简介
本文git提交流程与规范是宝贵、靠谱的经验，它能解决如下问题：
- 分支差距过大，导致合代码无数的冲突
- 合完代码后发现代码丢失
- 分支不清晰，无法追溯问题
- 合代码耗时很长，占用大量时间。
git的基本使用规范
- git用户名要指定为名字拼音的第一个（或前两个）字母。比如：李四(ls)，张三(zhs)
- 不要搞稀奇古怪的英文，因为这样追溯代码时不好找对应的人。
- 要选择rebase，禁用merge
- merge会丢代码（我周围的人踩过很多这个坑）。
- git提交清晰
- rebase是人类的正常思维：远程的代码优先。
- rebase是本地git先跟上远程git的最新提交点，再去提交代码
- merge是让远程git以本地git为基点（这样会导致本来领先的远程git又退回了）
IDEA选择rebase的方法
拉代码
推代码
项目从0-1时
说明
将git分支分为主分支和临时分支。
- 主分支：develop（开发）、test（测试）
- 临时分支：需求点和bug修改
- 开发阶段：
- develop（只有这一个分支）
- 测试阶段：
- 开发完毕后从develop新拉分支，命名为test，用于测试（develop分支废弃）
- 若有新需求：
- 从test新拉临时分支写代码，分支命名为：test_需求名
- 代码写完后，压点，cherry pick到test。（合到test的只有一个提交点，若test已更新，要选择rebase，不要选择merge）
- 若有bug：
- 小bug：直接在test改
- 大bug：方法与上边“若有新需求”一致。
- 上线阶段：
- 测试完毕后从test新拉分支，命名为prod，用于测试
上线完毕后，项目0-1阶段结束，开启1-100阶段。删除develop分支，新代码全部从prod新拉分支写。
项目从1-100时
说明
将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到目的分支：可保证不会将其他人代码合到目的分支
- 定期删除test、pre并从prod拉分支：从临时分支合到主分支时基本不会有冲突；而且可以删除test里无用的代码
感言
一个正常的功能点，如果合代码超过10分钟，那么，项目的git管理大概率有问题。如果超过30分钟，项目的git管理问题有点儿大。如果超过一个小时，那么这个项目肯定是经常丢代码，经常出奇怪的线上问题，客户投诉率肯定很高（亲眼见过）。
请先 ！