关于在公司提pr的时候设置了默认rebase

踩坑记录

为了使代码仓库的commit graph的可读性更高点，我们设置了在pr进目标分支的时候，自动做一个rebase，再加上merge的时候禁用快进模式也就是--no-ff,这样子就可以使得graph图永远只有两条线，一个主干，一个需求分支，如下图：

问题所在

我们都知道rebase是会变基的，特别是真实的开发我们有develop，release，pre-release，master等分支，一般情况下我们都是基于master创建的需求分支，在自测阶段，如果我们pr提交到了一个分支，比如develop，然后我们发现需要进行修改，然后我们修改好之后重新提交pr，发现就冲突了（经过发现，应该是只会在第一次提交pr的时候进行目标分支的rebase，后续不会rebase）

下面我们来复现一下这个场景 因为已经在develop上的第一次commit的基变了，已经和自己需求分支上的基不一致，git在合并代码的时候就会将修改的代码视为冲突。而且会标记修改的一整个文件。此时pr提示冲突，解决起来是比较麻烦的，因为我们不能把自己的需求分支来rebase或者merge测试分支，这样会把别人开发中的需求功能给带进来。这一次采用的解决方法是直接切换到develop，将需求分支merge进来解决冲突后push，但是这样就会出现内容相同但是commitId不同的无用重复的提交记录

复现

下面我们来通过操作复现一下

1. 先创建分支

• master上有一次提交，然后在master上切除feature分支，然后在回到master上提交第二次

  master：

  feature：

• 在feature上提交一次commit，rebase master，分别记录各自的commitId feature上的commitId：

  rebase后的commitId:

• 将feature merge进master，模仿pr自动rebase目标分支后merge且关闭快进，我们就得到这样的graph

• 回到需求分支，将其重置回rebase前的记录，来模拟本地分支未发生rebase

• 在feature上进行一次提交，修改前一次提交的内容并且提交

• 这个时候我们不进行rebase，模拟只有第一次pr才会进行rebase目标分支，提示我们有冲突，且标记的是文件的一整个文件

• 将冲突解决查看提交记录，会发现有两条内容相同但commitId不同的提交记录

• 原因是基变了，绿色和粉色的提交已经是不同的基底

后续问题

而且如果develop和你的需求分支不一致的话，develop上的commitId也是和本地需求分支不一致，如果是只需要develop提交pr，后续直接merge，恰好又设置了下一分支想要push commit的记录必须存在于上一分支的hook，如果commitId不一致就会push失败

改进思路

如果一定要保留这种graph图的话，也确实是比较直观。 但是我觉得应该在master和pre-release分支上设置自动rebase

原因：

• master和pre-release一般都是不会进行修改的，只存在一次pr，并且pre-release一般情况下会定期重置成master
• 方便我们解决冲突，如果发生了冲突只需要rebase master，这样就不会将开发中的需求带进自己的需求分支

对于develop等测试分支的话，如果每一次都必须提交pr，可以自己本地先rebase最新的develop，然后强推到自己的需求分支提pr，完成后reset回rebase前，再强推需求分支。但是这样也有许多问题，如果有人测试分支需要回撤，那你的提交就已经包含了别人的提交，所以我觉得测试分支还是不要rebase方便点

本人初学者，遇到的就是这么些问题

欢迎各位大佬提供一下解决方案