重新调整依赖主题分支的基础
我在 git 中使用了很多本地主题分支，有时最终会因主题分支之间的依赖关系而导致变基问题。例如，具有如下结构：
master ---> featureA ---> featureB
\--> featureC
如果 master 发生更改，并且在重新调整 featureA 时遇到（并解决）冲突，然后将 featureB 重新调整为 < code>featureA 会触发相同的冲突（有时还会引发新的冲突），因为它尝试重新应用 featureA 分支中的补丁。假设如果选择的话，featureA和featureB之间的实际补丁将干净地应用，有没有一种方法可以在这种情况下进行变基，其效果与cherry-大致相同选择 featureA 和 featureB 之间的所有提交？
I use a lot of local topic branches in git, and sometimes end up with dependencies between topic branches causing rebase problems. For example, with a structure like:
master ---> featureA ---> featureB
\--> featureC
If master changes and I get (and resolve) conflicts when rebasing featureA, then afterwards rebasing featureB onto featureA triggers the same conflicts (and sometimes exciting new ones as well) because it tries to reapply the patches from the featureA branch. Assuming that the actual patches between featureA and featureB would apply cleanly if cherry-picked, is there a way of doing a rebase in this situation with roughly the same effect as cherry-picking all of the commits between featureA and featureB?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
变基
featureA后，您可以假设
oldFeatureA代表在变基之前featureA顶端的提交（您可以在那里保留另一个分支）或者只记住提交哈希）。这基本上应该与将 A 和 B 之间的每个提交挑选到 A 的重新基版本上相同。
关于 git-rebase 的文档（包括一些有用的图形解释，说明在一些更复杂的 rebase 操作期间会发生什么）
After rebasing
featureA, you can doassuming
oldFeatureArepresents the commit at the tip offeatureAbefore you rebased it (you can either keep another branch there or just remember the commit hash).This should basically be the same as cherry-picking each commit between A and B onto the rebased version of A.
Documentation on git-rebase (includes some helpful pictorial explanations of what happens during some more complex rebase operations)
对于未来，如果您使用大量相互依赖的主题分支，也许您应该考虑使用 TopGit (README)，管理补丁队列的工具使用 Git 主题分支，每个分支一个补丁；或者管理多个主题分支的工具。
请参阅 topgit 意味着永远不必等待评论博客文章。
For the future, if you work with lot of interdependent topic branches, perhaps you should consider using TopGit (README), a tool to manage patch queue using Git topic branches, one patch per branch; or alternatively a tool to manage multiple topic branches.
See e.g. topgit Means Never Having to Wait for Reviews blog posts.
（在 Git 2.38)
(after Git 2.38)