使用Cherry选择后从发布分支合并到主分支时合并冲突？

Question

我们使用Git Flow并拥有一个发布分支，我们不断从分支提交中选择Cherry来修复我们在开发分支中需要的错误。有时我们在做樱桃时会遇到冲突。当发布时，我们显然会将发布分支合并到我们的开发中。我们会再次得到同样的冲突吗？我们曾经在樱桃皮中解决过这个冲突吗？

也许还有其他更好的方法可以将我们的开发与发布分支的错误修正同步？

donnib

Answer 1

根据git flow model，您应该将发布分支中的错误修复应用于开发分支，而不是通过樱桃选择，而是通过合并。你提到你在“释放出来”时进行合并，但是没有理由等待它;只要您修复发布中的错误，就可以从发布版本合并到开发中。

（编辑：回复评论中的问题）

您提到在开发分支中有一些您不希望开发的更改（例如版本号和诸如此类）。如果您在第一次分支发布时知道所有这些更改是什么，请在分支开发后立即将这些更改发布，然后将发布版本合并到git merge release -s ours进行开发。这将导致合并提交发生，但开发中的文件实际上不会发生变化。然后，未来合并到开发中不会带来那些不必要的变化，因为就git而言，它们已经被合并。现在发布之后，如果你做希望将这些变化合并到开发中，你确实必须亲自挑选一个单一的提交，但这可能比你现在做的多个樱桃选择更好。

Answer 2

为什么功能分支中会出现错误提交？

错误修正应该在功能分支的单独分支上（或者直接推送到分支发布），每个错误修复和新功能都可以有一个单独的分支，这样你就不必挑选个别提交。

Answer 3

我不太了解你的过程，但听起来并不合适。 Git Flow大约是一个3层流程。三层是您的发布分支（rel＃。＃），您的中间开发分支（dev）以及您的缺陷修复或功能增强分支（任务＃）。

我的GitFlow开发周期：

1. 从最后批准的rel＃。＃branch拉到新的dev分支。由此 指向rel＃。＃branch是静态的。
2. 从dev开始执行任务＃
   工作，测试，重新同步dev（解决合并冲突），推送 完成任务工作到开发。确保我推动开发 快进，即没有合并气泡，重新同步使用 ＆＃34; git pull --rebase origin dev＆＃34;每天，当任务完成并准备推送时
3. 推送（开发）和收集（开发）所有为新版本和 停止任务推送到开发，即冻结远程开发新任务
4. 测试开发并将修复程序推送到开发新版本
5. 将最终开发人员推送到具有新版本分支名称的新版本分支
6. 删除dev，返回步骤＃1

git cherry-pick只能选择并合并提交，这些提交可能会对您不想要的文件进行更改。使用以文件为目标的git checkout来获取您想要的提交中的文件更改。

要从不同分支中的同一文件的单个文件中获得非常独立的更改，请使用旧的时尚剪切和粘贴。