如何处理git中的嵌套分支？

不知道谷歌在这个问题上做了什么。以上应该是我的X问题。我的问题是

如何处理经常重设基础的父分支

假设我有以下分支：

STACK-123 [origin/master: ahead 3]
STACK-456 [STACK-123: ahead 7]
STACK-789 [STACK-456: ahead 4]

注意，它们也有这个依赖链

origin/master <- STACK-123 <- STACK-456 <- STACK-789

如果STACK-123被重定基址，我们得到：

STACK-123 (a', b', c', d') atop origin/master
STACK-456 (a, b, c, d, e, f, g) atop origin/master

注意

STACK-456

如何保存旧的提交

有什么工作流只将分支链接到一组提交，在重定基址后不会遇到此问题？

缺少手动修复每个分支

---

（同时，非常清楚对已发布的提交进行重定基址的危险，因此请不要重复。这些分支都没有发布/主线。）

在将它们推向世界之前，您应该只对本地分支进行重定基址。使用Git的错误方法是，拥有一个定期被重定基础的共享回购

（同时，我们也非常清楚对已发布的提交进行重定基址的危险，因此请不要重复。）

但这是正确的答案

重定基期改写历史。重基分支上的提交集实际上与未看到重基的本地分支上的提交集无关。重定基调基本上是做一堆相关樱桃采摘的捷径

---

合并和分支是与git共享代码的方式。重定基址意味着在将本地作品公之于众之前，先将其清理干净。

我一直在考虑的一个解决方案。。。我现在讨厌的是。。。就是通过将主题分支编码到提交消息中来对真正属于主题分支的提交进行编码（JIRA风格的开发人员无论如何都会这样做）

如果提交

efg

在其提交中有某种标记（一个要grep的字符串），则可以使用实用程序脚本（在

git

之外）将其过滤掉

a [self] STACK-123 ... relics before rebase, will be filtered
b [self] STACK-123 ...
c [self] STACK-123 ...
d [self] STACK-123 ...
f [self] STACK-456 ... contains the string 'STACK-456', will be kept
g [self] STACK-456 ...
h [self] STACK-456 ...

使用topgit 这个答案将是缺乏细节，因为我刚刚发现这个，我有一些困难，使它的工作。。。但这似乎是这种工作流程的确切答案。它在git中存储的元数据文件中对原始分支进行编码。它有自己的update命令，在更新子分支方面做正确的事情

---

除非您的合作伙伴同意频繁重新调整基址，否则不要对git分支执行此操作，只需保留一组补丁即可。如果他们已经同意，您可能需要对您的fetch REF规范大惊小怪。如果您想在repo内部保留补丁（在它们自己的分支上），您可以为它们提供独立的根提交。这可能有点奇怪，但可行。我从来没有试过那样做。还有，考虑一下。这个问题有点像“我知道我的车需要柴油，但是我怎样才能让它在汽油上运行得更好呢？”将功能视为可能依赖于其他未发布功能的补丁集并非不合理。避免让git新手头疼的是，合并似乎会让他们少说“他们应该学会如何正确地合并”。通过重定基来保持提交历史记录的直观性是值得的。这里的“头痛”是指需要手动解决的冲突吗？与标准的“不可变历史”相比，频繁的重定会导致相同或更多的冲突工作流的另一个缺点是没有记录重定基址提交的原始父级，因此无法区分错误合并导致的错误与原始代码中的错误。@CharlesBailey我不明白你在说什么。代码中的错误将出现在父级或要素分支中。有什么模棱两可的地方？

STACK-123 (a', b', c', d') atop origin/master
STACK-456 (a, b, c, d, e*, f*, g*) atop origin/master

a [self] STACK-123 ... relics before rebase, will be filtered
b [self] STACK-123 ...
c [self] STACK-123 ...
d [self] STACK-123 ...
f [self] STACK-456 ... contains the string 'STACK-456', will be kept
g [self] STACK-456 ...
h [self] STACK-456 ...