原文网址：git代码提交流程与规范-CSDN博客

简介

本文git提交流程与规范是宝贵靠谱的经验，它能解决如下问题：

1. 分支差距过大，导致合代码无数的冲突
2. 合完代码后发现代码丢失
3. 分支不清晰，无法追溯问题
4. 合代码耗时很长，占用大量时间。

git的基本使用规范

1. git用户名要指定为名字拼音的第一个（或前两个）字母。比如：李四(ls)，张三(zhs)
   1. 不要搞稀奇古怪的英文，因为这样追溯代码时不好找对应的人。
2. 要选择rebase，禁用merge
   1. merge会丢代码（我周围的人踩过很多这个坑）。
   2. git提交清晰
   3. rebase是人类的正常思维：远程的代码优先。
      1. rebase是本地git先跟上远程git的最新提交点，再去提交代码
      2. merge是让远程git以本地git为基点（这样会导致本来领先的远程git又退回了）

IDEA选择rebase的方法

拉代码

推代码

项目从0-1时

说明

将git分支分为主分支和临时分支。

• 开发阶段：
  • 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修改

开发与提交流程

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

优点

以上步骤是我之前所在某个公司的提交流程，按这个流程来做，可以做到：合代码基本不出问题、合代码速度快（一般不会超过3分钟）。

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

• 从prod拉新分支：可保证新分支代码是基于生产的，可以保证新分支是纯粹的自己的修改点
• 合代码时都是从临时分支cherry pick到目的分支：可保证不会将其他人代码合到目的分支
• 定期删除test、pre并从prod拉分支：从临时分支合到主分支时基本不会有冲突；而且可以删除test里无用的代码

感言

一个正常的功能点，如果合代码超过10分钟，那么，项目的git管理大概率有问题。如果超过30分钟，项目的git管理问题有点儿大。如果超过一个小时，那么这个项目肯定是经常丢代码，经常出奇怪的线上问题，客户投诉率肯定很高（亲眼见过）。