Question

我正在管理一个git存储库，并且只对master分支具有写访问权限。我已经要求我的同事创建他自己的分支并将任何更改推送到该分支，我将把它们变成主人。现在这是我的场景：

我的同事检查了分支A并做了几次提交。我继续在master分支上工作。同事将更改推送到存储库，然后将它们重新命名为master。当我的同事一直在研究A时，我一直在主分公司工作。

现在，我的问题是同事是否需要在rebase之后删除A并创建一个新分支，或者他是否可以继续使用A？他是否需要在重组后继续工作之前将新主人与A合并？

A
| \
|  \
B   D
|   |
C   E
|  /|
H / F
|   |
I   G

编辑以回应Tim对格式化的回答：

这不是我的情景。 branchA从不整合来自master的更改。所以基本上：

master:      ... A -- B
branchA:    ... A -- C

然后：

master:      ... A -- B -- C'
branchA     ... A -- C

注意branchA保持不变。现在可以继续使用branchA吗？

Answer 1

使用master的更改快进branchA后，您的同事应该可以继续使用相同的分支。这样做的原因是，在您的同事完成对branchA的{{1}}和快进master的自身提交后，这两个分支应该相同在那个时间点。请注意，这与通过合并进行同步后发生的情况相反，在这种情况下，您很可能希望删除功能分支并使用新分支再次分支。

考虑以下使用变基的简单工作流程：

master

master: ... A branchA: ... A和master都会得到提交：

branchA

现在master: ... A -- B branchA: ... A -- C branchA上的master折扣：

master:  ... A -- B
branchA: ... A -- B -- C'

请注意，我已使用撇号标记了上面branchA的唯一提交，因为它是 new 提交，但它可能与原始提交C非常相似

现在，我们使用master的更改快进branchA。我们可以这样做，因为在branchA之后<{1}} 提前之后。这给我们留下了：

master

在这个确切的时刻，master: ... A -- B -- C' branchA: ... A -- B -- C'和featureA都是彼此锁定的。我们可以冲洗并重复，因为我们现在基本上回到了我们开始的地方。

Answer 2

从技术上讲，由于他的分支机构保持不变，他可以继续在分支机构工作。也就是说，由于您正在使用master，因此您的相应代码库会出现分歧，可能会在变基期间引发越来越多的冲突。如果你决定要开始将master的更改带到他的分支中，我建议废弃他的分支并创建一个新分支，而不是将master合并或重新定位到他的分支上。

我个人认为你应该将他的分支合并到你的分支而不是变基础。这样你就可以来回合并，始终保持最新状态。但我意识到合并与rebase部分是品味问题。

Git rebasing分支机构

2 个答案: