Question

使用git，是否有一种从上游获取最新信息并重新应用下游更改的好方法？不是将上游分支合并到已经包含我们的下游变更的下游分支，而是将我们的下游变更重新应用到新的上游将更有效。

我有一种我认为并不独特的情况：我们下游分支机构的变化是上游赢了还是还没有接受，但我们需要定期保持（非常大））一个团队的上游变化比我们的要大得多（按数量级）。

我们将下游代码更改调整为上游更改要好得多 - 反之亦然 - 因为从长远来看，每次合并都会有更多的工作。重新应用我们的下游变更（并使其适应新的上游）比将上游变更合并到我们的下游变更更加清洁和安全，并使我们能够更好地审查下游变更如何修改新的上游。

传统合并上游到下游方法将是：

git merge upstream/master
git log，解决新上游更改与下游更改之间的冲突

重新应用新上游的下游变更的劳动密集型方法可能是：

创建下游更改列表以通过git rebase保留 - 让我们将其称为保留列表
将 origin / master 的内容替换为上游/母版：git command for making one branch like another
git cherry-从保留列表中选择每个旧的更改回 origin / master ，解决冲突

考虑它的一种方式 - 我们需要类似于git rebase的东西，但它适用于＆＃34; public＆＃34;非本地分支机构，使用最新的上游/主站重新定位下游/主站。 {{1}}本身通常是不可接受的，因为它会打破变革的黄金法则 - 永远不会贬低公共＆＃34;分支。

任何人都有更好的方法吗？提前谢谢！

Answer 1

假设分支如下：

A - B - C - D - E - F - G <- upstream/master
        |
         \
          - X - Y - Z <- origin/master <- HEAD

1，用git merge upstream/master -Xtheirs替换origin / master的内容与上游/主站。调用此合并提交＆＃34; R＆＃34;。（如果您在分支中创建了新文件，则需要删除它们。）

A - B - C - D - E - F - G <- upstream/master
        |               |
         \              |
          - X - Y - Z - R <- origin/master <- HEAD

2，运行git rebase -i --onto origin/master upstream/master origin/master^。此命令将打开一个包含以下内容的编辑器：

pick 5db64e4 X
pick d0744fe Y
pick 550d34b Z

# Rebase  0cbeed6..550d34b onto 86590a3 (3 command(s))
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

只需关闭编辑器，然后X，Y和Z所做的更改将合并到origin / master上。（如果有的话，你需要在这里解决冲突。）

A - B - C - D - E - F - G <- upstream/master
        |               |
         \              |
          - X - Y - Z - R <- origin/master
                        |
                         \
                          - X' - Y' - Z' <- HEAD

3，运行git branch -f origin/master HEAD将原点/主人移动到小费。

A - B - C - D - E - F - G <- upstream/master
        |               |
         \              |
          - X - Y - Z - R
                        |
                         \
                          - X' - Y' - Z' <- origin/master
                                         <- HEAD

最后，运行git checkout origin/master以附加HEAD。

A - B - C - D - E - F - G <- upstream/master
        |               |
         \              |
          - X - Y - Z - R
                        |
                         \
                          - X' - Y' - Z' <- origin/master <- HEAD

Answer 2

我不确定我是否理解你问题背后的动机。我假设你知道由于你指出的溢出答案而导致的rebase策略和选项的所有可能性。

也许补丁会帮助你。如果你想模拟樱桃采摘，请保留清单＆＃39;制作包含您需要应用于其他分支的每个提交的补丁：

git format-patch --stdout first_commit_hash^..last_commit_hash > commits.patch

签出所需状态的所需分支并应用补丁

git am -3 --signoff < commits.patch

如果存在冲突，

-3选项将执行三向合并。

签收选项将添加有关制作补丁的人员的其他数据

已应用的提交将包含元数据

通过替换上游并使用git重新应用下游更改来更新下游？

2 个答案: