将分支重新建立到重写的历史记录上时,如何避免虚假的合并冲突?

时间:2019-12-16 00:08:33

标签: git

在我的工作场所中,我们使用了变基工作流程。我最近为三个同事解决了以下问题,因此我认为值得进行问答以帮助更多人,并为同事提供参考。

假设我运行以下一系列命令来创建git存储库,并使用一些数据和一次提交对其进行初始化。

git init .
cat > MyFile.txt <<'EOF'
> Line 1
> Line 2
> Line 3
> Line 4
> EOF
git commit -m 'Initial commit'

然后,我创建一个分支并添加一个提交以修改特定行。

$ git checkout -b MyFeature
Switched to a new branch 'MyFeature'
$ ed MyFile.txt
28
2s/$/ This is the initial implementation of my glorious feature
Line 2 This is the initial implementation of my glorious feature
wq
86
git add -u
git commit -m 'WIP Add glorious feature'

将其发送以供审核后,然后我研究一个依赖于此功能的其他功能,并进行新的提交。

git checkout -b MySecondFeature
cat >> ThisFileDependsOnMyFile.txt <<'EOF'
> This commit touches a completely different file.
> EOF
git add ThisFileDependsOnMyFile.txt
git commit -m 'Add Feature2'

现在我对第一个功能的评论回来了,所以我对其进行了一些更改,然后将其合并到主版本中。

git checkout MyFeature
sed -i '2s/initial/final/' MyFile.txt
git add -u
git commit --amend -m 'Add glorious feature'
git checkout master
git merge MyFeature

最后,我尝试将MySecondFeature改组为master。不幸的是,即使MySecondFeature上的新提交甚至没有触及冲突的文件,它也会炸毁。

git checkout MySecondFeature
git rebase master
First, rewinding head to replay your work on top of it...
Applying: WIP Add glorious feature
Using index info to reconstruct a base tree...
M       MyFile.txt
Falling back to patching base and 3-way merge...
Auto-merging MyFile.txt
CONFLICT (content): Merge conflict in MyFile.txt
error: Failed to merge in the changes.
Patch failed at 0001 WIP Add glorious feature
hint: Use 'git am --show-current-patch' to see the failed patch
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

在分支分支中随后如何重写其历史记录时,如何避免这些虚假的合并冲突?请注意,我们总是可以手动解决冲突,但是这会浪费大量时间这样做。

为便于讨论,这里有一些哈希值:

git log MySecondFeature
hq6:GitPlay hqin$ git log
commit 061fc8448e93f0e31239b2f4806d5caac6bfe578 (HEAD -> MySecondFeature)
Author: ***
Date:   Sun Dec 15 15:36:21 2019 -0800

    Add Feature2

commit f878084412c04542e297cb5c52b0fb6f6a2b2870
Author: ***
Date:   Sun Dec 15 15:30:45 2019 -0800

    WIP Add glorious feature

commit fe88218ac2432e086a40f052bfa4e7c759f677b4
Author: ***
Date:   Sun Dec 15 15:26:18 2019 -0800

    Initial commit


git log master
commit 522cc625b709b37c4ccfd1878465f8da30f9e082 (master, MyFeature)
Author: ***
Date:   Sun Dec 15 15:30:45 2019 -0800

    Add glorious feature

commit fe88218ac2432e086a40f052bfa4e7c759f677b4
Author: ***
Date:   Sun Dec 15 15:26:18 2019 -0800

    Initial commit

2 个答案:

答案 0 :(得分:1)

我喜欢使用交互式资源库并删除所有不应该存在的提交来做到这一点:

git rebase -i master

您的git编辑器将打开,其中包含一个文件,可让您重新排序,编辑和删除提交。在这种情况下,我们只想删除现在不存在的MyFeature提交,这是通过在提交哈希之前放置“ drop”来完成的:

drop f878084 WIP Add glorious feature
pick 061fc84 Add Feature2

# Rebase 522cc62..061fc84 onto 522cc62 (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# 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

现在您可以看到重新建立成功:

Successfully rebased and updated refs/heads/MySecondFeature.

答案 1 :(得分:0)

有三种方法可以避免手动解决虚假合并冲突。

跳过冲突的提交

由于我们实际上并不在乎f878084412c04542e297cb5c52b0fb6f6a2b2870,因此我们可以在调整基准期间简单地跳过它。

git rebase master
# Bunch of merge 
git rebase --skip

明确告知要重新设置历史记录的部分

这是我最喜欢的解决方案。可以使用git rebase运行--onto并传递目标分支,然后传递我们关心的MySecondFeature上最早提交的父对象。

# Get out of the merge conflict situation
git rebase --abort

git rebase --onto master 061fc8448e93f0e31239b2f4806d5caac6bfe578~1

樱桃精选

我们可以从所需的历史记录开始创建一个临时分支,然后从MySecondFeature中挑选所需的提交。

# Get out of the merge conflict situation
git rebase --abort

git checkout -b TempBranch master
# Note that if there are multiple commits we care about on MySecond Feature, these should be cherry-picked either individually or together in the right order.
git cherry-pick MySecondFeature
git checkout MySecondFeature

# Note that this command will blow away changes in your working directory.
git reset --hard TempBranch

# git branch -d TempBranch