为什么要规范
GIT作为最常见的分布式版本控制软件，能够记录用户每一次的新增、删除与修改等操作，特别是当多位开发共同维护一套系统时，分布式版本控制就能体现出很大的优势。
但是不恰当协作方式、工作流程，会导致GIT难以维护
在下图中我们可以看出，三位用户均从当前主干拉取了最新分支，并各自做出了修改
image.png
我们首先假设，他们的修改互不影响，且各自仅维护自己的代码，不理会其他人的修改，这样会造成什么现象呢？让我们来合并这三个用户的代码
image.png
合并完成后，来看下graph图。此时我们会发现每次merge都是相互交错的，但是这个图还能勉强看出他们之间的关系，因为整个流程还并不是很长。
image.png
现在，让我们试着再在各个分支上进行一次修改并合并，我们会惊奇的发现，这个图已经有一点复杂了，各个分支之间相互交叉。
image.png
但是毫无疑问，这种相互交错的流水线，随着项目的发展，后期只会愈发的不可收拾，最终成为一个"毛线团"，无法维护。
GIT规范提交
为了项目的健硕、可维护的发展，团队需要约定规范的代码提交方式。
- 每次提交代码，无特殊情况，避免直接在主干上修改，而是应该尽量从主干拉取分支，随后修改并提交代码合并。
- 每次合并代码，必须
rebase变基到最新的主干分支，才允许合并分支。特别是遇到冲突时，一定要尽早处理冲突代码。 - 每次提交尽量规范
git commit，可以使用常见的git template作为团队标准，包括但不限于feat、build、ci等，以便快速过滤出目标提交。
大致的流程如下：
git checkout -b fix-JIRA111 // 创建新分支
git add . // 修改添加到暂存区
git commit -m "fix: fix ...." // 修改添加到分支上
git chechout master // 切换到主干分支
git pull // 主干获取更新并自动合并
git checkout fix-JIRA111 // 重新切换到修改分支
git rebase master // rebase变基，类似当前分支是从最新主干拉取的一样
git push // 推送修改到远端，进行合并提交
关键GIT指令 git rebase
现在我们仍旧在user1分支上提交了一次修改，如下图，我们可以看到，最新的一次修改，是user1提的，并且是在user1自己分支上的
image.png
现在我们进行
git rebase master操作，然后使用git push -f强制推送代码，我们再来观察graph图，此时会发现user1的修改，已经移动到主干上了，就感觉user1分支是从最新的主干上拉取出来的一样！
image.png
现在我们同样对其他的分支作同样的操作，得到如下图，我们会发现当前的图形，就和我们最初提交的一样，三次修改均从最新的主干出发
image.png
现在我们遵循这个规范，进行后续的代码合并，最终得到：
image.png
