3

不知道谷歌如何处理这个问题。以上应该是我的X问题。我的Y问题是

您如何处理经常变基的父分支？

假设我有以下分支：

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保留旧的提交？

有什么工作流程只是将分支链接到一组提交并且在变基后不会遇到这个问题？

缺少手动修复每个分支。

（另外，很清楚重新定位已经发布的提交的危险，所以请放弃重复。这些分支都没有发布/主线。）

4

3 回答 3

1

在将它们推向世界之前，您应该只对本地分支进行 rebase。拥有一个经常被 rebase 的共享 repo 是使用 Git 的错误方式。

（另外，很清楚重新定位已经发布的提交的危险，所以请不要重复。）

但这是正确的答案。

变基重写历史。rebase 分支上的提交集实际上与本地分支上没有看到 rebase 的提交集无关。变基基本上是做一堆相关的樱桃选择的捷径。

合并和分支是您应该与 git 共享代码的方式。变基旨在清理您的本地工作，然后再将其暴露给世界。

于 2013-07-19T22:44:07.127 回答
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 ...
于 2013-07-19T22:53:16.967 回答
0

使用 topgit

这个答案的细节很少，因为我刚刚发现这个并且我在让它工作时遇到了一些麻烦......但这似乎几乎是这种工作流程的确切答案。它将原始分支编码到存储在 git 中的元数据文件中。它有自己的更新命令，在更新后代分支方面做正确的事。

https://github.com/greenrd/topgit

于 2013-07-20T00:49:54.140 回答