当我使用冲突进行git重基时，创建社区修补程序的最佳方法

Question

我对创建补丁并将它们重新定位到主分支有疑问。例如：

我在一个与主人分离的分支中工作，我生成了5次变更提交。所以，我想把这个提交作为补丁发送到社区。例如Linux内核。

其他开发人员在主分支中添加了新的提交，当我将我的5个补丁重新定位到master时，会出现一些冲突。

那么，我需要生成一个新的补丁来解决冲突吗？那么，我是否需要发送5+1补丁(我的5提交+1冲突解决提交)？

我想知道发送补丁和修复合并冲突的策略是什么。

Answer 1

解决这些冲突的最好方法--在补丁中不产生不必要的“噪音”，是在新主服务器之上重新设置分支，然后创建修补程序系列。这给了你解决任何冲突的机会，而不会分散“端到端-解决所有冲突”补丁的接受者的注意力。(我相信这个工作流在Linux内核的“入门”文档中已经讨论过(或者至少提到过)。

更新主分支

git checkout master
git pull

将您的更改重新定位到最新的上游头(原始/主、主)

git checkout mybranch
git rebase master

# Resolve rebase conflicts here

创建你的补丁。此时，修补程序应该干净地应用于上游水头，因为重新定位。

git format-patch master

注意:这些命令未经测试，来自内存。

Answer 2

这不是“怀疑”，而是一个问题。

我将我的5个补丁重新定位到主版中，出现了一些冲突。

你是如何解决冲突的？

您应该解决它们才能完成重基，所以在您的分支中仍然应该只有5次提交，而不是5+1。

如果在分支上执行git log master..，应该会看到需要发送的提交。如果您正确地进行了重基(并且没有提交冲突或中断的代码)，那么仍然应该只有5次提交才能发送。

因为冲突只存在于您的分支中，并且您应该在本地解决它们，因此没有人知道它们的存在，所以您不需要向它们发送任何补丁来解决任何问题。

Answer 3

使用git format-patch |

每次提交都要准备一个文件中的修补程序，格式类似于UNIX邮箱格式。此命令的输出对于电子邮件提交或与git am一起使用都很方便。 有两种方法可以指定要操作的提交。 1.单个提交，指定导致当前分支尖端的提交在历史记录中不导致要输出。2.泛型表达式是指在指定范围内提交。