当相同的更改手动应用于两个分支时如何强制变基？

发布于 2024-08-30 06:41:36 字数 758 浏览 7 评论 0原文

我的存储库看起来像：

X - Y- A - B - C - D - E             branch:master
     \                  \
      \                  \ merge master -> release
       \                  \
        M  ---  BCDE  ---  N         branch:release

这里“M - BCDE - N”是手动（不幸的是！）应用的更改与单独提交“A - B - C - D - E”大致相同（但似乎GIT不知道这些更改是相同的））。我想变基并获得以下结构：

X - Y- A - B - C - D - E     branch:master
                        \
                         *   branch:release

即我想让branch:release与branch:master完全相同，并从master的HEAD中分叉它。

但是，当我在分支版本上运行“git rebase master”时，GIT 报告了很多冲突并拒绝 rebase。我该如何解决这个问题？

对此的其他解释：我想“重新创建”分支：从 master 的 HEAD 从头开始释放。而且还有很多其他人已经为分支制作了“git pull”：release，所以我不能使用 git reset + git push -f。

原文

My repository looks like:

X - Y- A - B - C - D - E             branch:master
     \                  \
      \                  \ merge master -> release
       \                  \
        M  ---  BCDE  ---  N         branch:release

Here "M - BCDE - N" are manually (unfortunately!) applied changes approximately same as separate commits "A - B - C - D - E" (but seems GIT does not know that these changes are the same). I'd like to rebase and get the following structure:

X - Y- A - B - C - D - E     branch:master
                        \
                         *   branch:release

I.e. I want to make branch:release to be exactly the same as branch:master and fork it from the master's HEAD.

But when I run "git rebase master" sitting at the branch release, GIT reports about lots of conflicts and refuces rebasing. How could I solve this?

Other explaination of this: I'd like to "re-create" branch:release from scratch from master's HEAD. And there are a lot of other people who had already made "git pull" for the branch:release, so I cannot use git reset + git push -f.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

春庭雪 2024-09-06 06:41:36

你说人们已经拉取了发布分支，所以你无法重置。这也意味着你不能变基——无论哪种方式，你都会以非合并的方式移动裁判，并让其他人感到不安。

假设你想扔掉发布分支上的一切（我对M有点困惑）并使其与master相同（为什么你要显示< code>*？），这是你可以做的：

git checkout master
git merge --strategy=ours release   # merge in release, but keep master's contents
git checkout release
git merge master                    # fast-forward

你最终会得到这样的结果：

X - Y- A - B - C - D - E ----- Z (master, release)
     \                  \     /
      \                  \   /
       \                  \ /
        M  ---  BCDE  ---  N

合并提交 Z 将放弃发布中的所有更改；它只是为了确保发布快进。从文档中：

我们的
这可以解析任意数量的头，但合并的结果树始终是当前分支头的树，有效地忽略来自所有其他分支的所有更改。它旨在用于取代侧分支的旧开发历史。

这正是你的情况！

在合并中使用 --no-commit 选项，然后手动提交，这样您就有机会编辑消息并记下您所做的事情，这也是一个不错的主意。

You say that people have pulled the release branch already, so you can't reset. That also means you can't rebase - either way, you move the ref in a non-merge way, and upset everyone else.

Assuming that you want to throw away everything on the release branch (I'm a little confused by the M) and make it identical to master (why do you show the *?), here's what you can do:

git checkout master
git merge --strategy=ours release   # merge in release, but keep master's contents
git checkout release
git merge master                    # fast-forward

You'll end up with this:

X - Y- A - B - C - D - E ----- Z (master, release)
     \                  \     /
      \                  \   /
       \                  \ /
        M  ---  BCDE  ---  N

The merge commit Z will have discarded all changes from release; it's just there to ensure that release moves in a fast-forward. From the documentation:

ours
This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches.

This is exactly your situation!

It's also not a bad idea to use the --no-commit option on the merge, then commit manually so that you get a chance to edit the message and note what you did.

回复收藏 0 原文