发送Pull Request时如何避免自动合并消息

Question

为了保持我的修复分支更新上游主分支，我写了一个contab来自动合并上游提交在我自己的Branh修复过程中。但现在，当我想将PR发送到上游仓库时，我发现差异页面显示如下：

[commit1] myfix1
[commit2] myfix2
[commit3] auto-merge
[commit4] auto-merge
[commit5] auto-merge

....

现在PR里面有很多“自动合并”的消息！这太丑了......

在发送PR之前，我该怎么做才能避免这些事情？

Answer 1

我不确定你的自动合并提交真的那么难看，或者它们真的很重要。

当我在GitHub上合并PR时，我不会查看单个提交。我看看最后的差异。我经常要求开发人员回滚他的一些更改，并添加一些新的。在完成修复并再次推送之后，我再次查看最后的差异，并且就我从未发生的事情而言，回滚的变化将会消失，就我而言。

在合并PR时，通过提交读取提交是不切实际的。最好看看总体变化。如果我想查看特定提交的详细信息，我可以猜测注释中“自动合并”的提交没有做任何有趣的事情，我不会看那些。

但如果你真的想在将来避免这些提交，那么就不要自动合并，而是使用变基。最后，这只是一个美容问题，而不是一个真正的问题。

Answer 2

如果您尝试rebase而不是merge，那么您有2个选项

假设分支master和远程origin

• 获取然后使用rebase

  git fetch origin master
  git rebase origin/master
  

• 带标记rebase

  git pull origin master --rebase
  

  这样git会更喜欢变基，而不是合并

即使我是喜欢使用merge而不是rebase的人之一，如果您发现任何冲突，我也不会建议使用rebase，特别是如果您的本地树对于你所拥有的每个本地提交，你会发现你的自我解决了一次相同的冲突。

注意：如果事情向南，您可以随时中止

git rebase --abort

这会将您的本地分支返回到原始格式。

我仍然不明白为什么你真的需要那个cron工作，你只需要在推动之前重复一次，至少这就是我的工作。

Answer 3

git rebase是适合您情况的命令：

你的情况有点像

你正在研究我的例子中的分支功能，有些人已经在master上执行了两次提交，所以目前你没有与master同步，所以你必须在你的Git pull或Git fetch之后执行Git rebase

所以看起来有点像

然后您可以将更改推送到原点。