不确定Google对此问题的看法。以上应该是我的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 (a, b, c, d) atop origin/master
STACK-456 (e, f, g) and implicitly (a, b, c, d) atop origin/master
如果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如何保留旧提交？
哪些工作流只是将分支链接到一组提交，并且在重新定位后没有遇到此问题？
没有手动修复每个分支。
（另外，请注意重新定义已发布的提交的危险，所以请放弃重复。这些分支都没有发布/主要。）
答案 0 :(得分：0)
在将它们推向世界之前，你应该只改变当地的分支机构。拥有一个经常被重新定位的共享仓库只是使用Git的错误方式。
（另外，请注意重新定义已发布的提交的危险，所以请放弃重复。）
但这是正确答案。
重新定位会重写历史记录。在一个重新分支的分支上的提交集实际上与您没有看到rebase的本地分支上的提交集无关。重新定位基本上是做一堆相关樱桃选择的捷径。
合并＆amp;分支是你应该用git共享代码的方式。重新定位旨在清理您的本地作品，然后将其暴露给世界。
答案 1 :(得分：0)
我一直在考虑的一个解决方案...我当前讨厌的...是通过将其编码到提交消息中来编码哪些提交真正属于主题分支（JIRA-风格开发者无论如何都会这样做。）
STACK-123 (a', b', c', d') atop origin/master
STACK-456 (a, b, c, d, e*, f*, g*) atop origin/master
如果提交e f g在提交中有某种标记（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 ...
答案 2 :(得分：0)
这个答案在细节上很少，因为我刚发现这个问题而且我在使用它时遇到了一些麻烦......但它似乎几乎是这种工作流程的确切答案。它对存储在git中的元数据文件中的原始分支进行编码。它有自己的更新命令，在更新后代分支方面做了正确的事。