此规范适用情况

1、项目基于 gitlab 工作流开发

• gitlab 有一套完整的多分支开发流程

2、项目存在多分支协同开发

• 有 dev、staging、prod 等分支
• 有具体每个 issue 的 merge-request 分支(参考 gitlab 工作流)

3、项目不关注每个提交的具体提交记录 只关注整体的代码

• 当 merge-request 有多条提交记录时，需要合并提交记录为一条 -> 尽量减少主分支的提交记录
• 项目希望提交树尽量干净，不需要 merge 信息

tip： 如果是小项目，开发者在 dev 分支开发就不会涉及到此规范，直接拉别人的代码再解决冲突提交就好了

创建 merge-request 分支

在 gitlab 上，当管理者 assign 给我们 issue 时，我们可以在 issue 详情页面 create merge request，我们可以选择 merge request 的源分支，当 merge request 通过代码审查后，会自动合并到主分支

squash 合并提交记录

可以使用 squash 操作合并提交记录
有很多工具有可视化操作，git使用命令也可以完成，不过使用工具会更方便 比如：GitHub Desktop

cherry-pick 代码

如果在开发过程中，有一个代码是其他分支的，没有提交到主分支，你刚好需要使用，这时候可以使用 cherry-pick 命令，把代码拉过来，这时候你的代码里就会有这条记录

具体命令:

copygit checkout target branch // 先切换到其他分支

git log // 查看 提交记录

git cherry-pick [git hash] // [git hash] 就是需要 pick 过来的 提交记录的 hash 值，是一串很长的字符串

rebase 代码变基

如果在开发过程中，有一个新合并到主分支的代码，或者是你在其他分支有新的提交，而当前你工作的分支需要那些代码，你可以基于 主分支/其他新分支进行 rebase(变基)，相当于代码变成了目标分支的代码

tips： rebase 代码后可能需要解决冲突，解决后一定要强推到远端，提交记录才会是正常的，不然可能会重复

具体命令:

copygit rebase target branch  // rebase

git push target branch --force // 强推

因为 rebase 是在你工作的分支上进行的，所以可以强推，只要处理好冲突就行

为什么需要使用 rebase 而不是 merge

我们可以通过以下两张图来看出区别

merge：

rebase:

可以看到 merge 后的代码在主分支上会比 rebase 多一个 merge 的提交信息，这个信息其实我们是不关注的，多分支协同开发的情况下，这种合并情况会很多，为了避免出现这么多的merge提交信息，我们通常采用 rebase 合并代码