Question

我的难题是这个。我的团队成员修改了供应商组件。然后，该组件升级到当前版本，覆盖了我的团队的更改。

有问题的部分由我的队友进行了重大更改，但升级后添加的变化很小。我有这个：

---component version 1.0----team change A---team change B---component version 2.0
        (stock)                                              (result of upgrade)

我想要的是像这样进行合并：

          ----team change A---team change B
         /                                 \
---component version 1.0                    successful 'merge'
        (stock)                            /
         \------------component version 2.0
                       (result of upgrade)

理由是，如果我们看到供应商从component version 1.0更改为component version 2.0，我们从component version 1.0更改为team change B并将这些更改合并，那么应用团队更改会更容易两组变化。

据我了解，执行此操作的唯一方法是将分支重置为team change B，从component version 1.0签出新分支，并在component version 1.0和{{之间应用差异1}}作为补丁，合并创建的分支，并提交解决方案。

我希望有一种方法可以基本模拟像component version 2.0这样的合并，这样我就可以使用合并解析工具来确定生成的文件的样子。

Answer 1

如果您不想重置分支（可能已经发布到共享存储库，并且您不希望人们必须处理强制更新），您只需将升级恢复为2.0版即可 - 在版本1.0导入的分支上升级到2.0版，然后合并该分支。

例如（假设您的分支被称为master并且master当前已签出）：

# create a commit that is the opposite of HEAD, effectively undoing it
git revert HEAD^
# create a new branch based on the original vendor import
git checkout -b vendor <sha1-of-vendor-1.0-commit>
# import the vendor 2.0 code
git read-tree -u --reset master^
git commit -m "vendor 2.0 code"
# merge in the new vendor code
git checkout master
git merge vendor

Answer 2

你应该能够这样做（假设master是你的分支的名称，它可能不是）：

git checkout master
git reset --hard <SHA of team change B>
git checkout -b vendor-upgrade <SHA of component version 1.0>
# replace contents of working directory with component version 2.0
git add <everything that needs to be added>
git commit -m "component version 2.0"
git checkout master
git merge vendor-upgrade

根据团队变更的性质，您可能会遇到一些合并冲突，由您决定是否在完成后删除vendor-upgrade分支，或者只是将其留在那里当不可避免的版本3.0出来时......

Git'合并'，但在同一分支中指定远程/本地/基地

2 个答案: