【问题标题】:Solve cherry-pick conflicts between diverged branches without committing在不提交的情况下解决分歧分支之间的挑剔冲突
【发布时间】:2014-10-11 14:27:08
【问题描述】:

我有两个不同的分支(masterfeature)。

master  - C1 - C3
            \
feature      C2 - C4 - C5

C2 和 C4 只是带有临时代码的脏提交,我不想在两个分支的最终合并/变基中进行。

我通常执行一个:

git checkout master
git cherry-pick C5 (last commit from the feature branch)

但这次我的 C3 有冲突,我无法选择提交。

我尝试将 C3 重新定位到 feature 分支,因此在挑选樱桃时不会发生冲突。

git checkout feature
git rebase master

现在我得到了这个

master  - C1 - C3
                \
feature          C2 - C4 - C5

看起来不错,但是如果我再次尝试 cherry-pick 到 master 上,我仍然会遇到冲突(在我从某些文件中删除的一些空白空间上)。

Git 告诉我要解决冲突、添加文件并提交。 我可以手动解决冲突,但不想将它们仅仅作为冲突解决方案提交。

我想避免在我的历史记录中提交与实现不直接相关的内容。我什至不知道该写什么作为提交消息。

  • 为什么在 rebase 之后我仍然会遇到冲突?
  • 如何在不进行额外提交的情况下将 C5 合并/精选到 master

我通常更喜欢挑选,因为我可以避免“无用”的合并提交,并且只提交关于代码更改的提交。然后我删除了这个分支,过了一会儿我确定我不再需要它了

[[ 编辑]]

奇怪的行为是 C5 和 C3 在 C3 上未更改的文件上发生冲突。

事实上,所有检测到的冲突在主分支上都是空的

<<<<<<< HEAD
=======
[ added code ..................... ]
[ .......... from ................ ]
[ ............... 'feature' branch ]
>>>>>>> 581g52d... "Commit message from 'feature' C5 "

我需要'解决'只是从冲突文件中删除冲突标签。

  • 我不明白冲突的原因
  • 我想手动解决它,然后 merge/cherry-pick 而不必创建新的提交
    • 因为提交只会解决与将来会被删除的分支的一些冲突
    • 删除分支后,该提交将在存储库历史记录中没有意义/位置

[[ 编辑 2 ]]

此外,如果我尝试 `git cherry-pick master/C3 to feature 我会得到:

没有添加到提交的更改(使用“git add”和/或“git commit -a”) 之前的樱桃选择现在是空的,可能是由于冲突解决。

我不明白为什么我有相反方向的冲突(从 featuremaster

[[ 编辑 3 - 从头开始​​重试! ]]

这也是我尝试过的。

  • 制作了 master 分支的两个副本,最后一次提交为 C3,命名为:master_copyrepeat_feature

    • git checkout master / git branch master_copy / git branch repeat_feature
  • feature 分支(直到 C5)中将每个提交精心挑选到 repeat_feature
    • git checkout repeat_feature / git cherry-pick C2^..C5(来自功能
    • (我得到 没有冲突
  • 尝试从 repeat_feature 将 C5 挑选到 master_copy
    • 请记住,repeat_feature 是从 C3 开始的(因此,如果存在一些冲突,则应在从 C2 到 C5 挑选樱桃时提出这些冲突)
    • git checkout master_copy / git cherry-pick repeat_feature_C5

我仍然有同样的冲突!

即使我从同一个 C3 提交开始(当将分支克隆到 repeat_feature 分支时)并尝试 cherry-pick 到同一个 C3 提交(进入 master_copy)!

我完全不明白发生了什么以及为什么我会遇到这些空洞的冲突,这些冲突阻止我将我的功能移动到主分支。

这里需要专家的建议。

【问题讨论】:

  • 如果您尝试更改差异不明确的代码,您遇到合并冲突。我不确定在采摘樱桃时是否可以特别避免这种情况。这不是挑选樱桃,而是代码更改。
  • 是的,这是一个差异问题。我没有得到的是 C3 没有更改的文件上的 C5 和 C3 冲突(事实上,所有检测到的冲突在主分支上都是空的,我需要“解决”的只是删除冲突标签冲突的文件)。我将使用此信息更新问题。
  • 无论如何我需要的只是解决冲突但避免提交这些更改。不知道有没有办法。
  • 不,如果不提交它们就无法解决冲突,除非你想做的是强制推送,这不是一个好主意。
  • 如何将冲突解决到 feature 分支中(无论如何将来都会被删除),然后将解决方案提交到 master i> 分支,更改提交消息?我只想完成,因为我刚刚在 master 分支上提交了一次以添加新功能。

标签: git merge branch cherry-pick git-merge-conflict


【解决方案1】:

我想避免在我的历史记录中提交与实现不直接相关的内容。

当我在 SO 上阅读了大量关于此主题的答案时,我可以说大多数人建议不要使用不必要的 git cherry-pick

是的,cherry-pick 不是用于合并某些东西,这是通过大量提交开发的。它用于将两个分支在其他提交中未更改的代码行从一个分支应用到另一个分支。

主要的可能性是将featureC5状态合并到master,同时避免一些脏的C2C4to use squashing

1。使用merge:

git checkout master
git merge --squash feature

2。使用rebase:

这可以通过交互式变基来完成:

git checkout feature
git rebase -i master

然后,对于除一个之外的所有提交,您应该将pick 更改为squash

另外,所有的临时提交消息都以squash!fixup! 开头。然后你就可以使用autosquash(所有的临时提交都将在rebase期间与这个关键字一起出现在列表中)

git checkout feature
HASH=`git merge-base --fork-point master`
git rebase -i $HASH --autosquash

【讨论】:

    【解决方案2】:

    我完成了改变方法:

    • 我复制了_feature_branch_ (git checkout feature_branch/git checkout -b copy_feature_branch);
    • 我将所有分支提交“压缩”成一个
      • 首先:我回到分支的父提交:git reset &lt;branch_parent_commit&gt;
      • second:我用git add .重新添加所有更改,然后用git commit提交
      • 最后我选择了这个提交到主分支,只用一次提交应用了我从 feature_branch 中所做的所有更改(就像我想对 C5 做的那样,误解了 git cherry-pick )。 git checkout master/git cherry-pick &lt;last-commit-of-copy_feature_branch&gt;)

    这样我完全没有冲突(正如我所期望的那样)并且我只需要一个提交来引入所有更改(或者无论如何feature_branch 中的“更改包”)。 我制作了我的功能分支的副本,这样我就可以在一段时间内拥有 WIP 提交的完整序列,这可能有用一段时间(对于测试,应用修复,请参阅历史特定功能的更改)。我通常不会删除分支,而是将其重命名为 git branch -m &lt;current_name&gt; FINISHED_&lt;current_name&gt; 并保留它直到我不确定是否要删除它。

    这不是一个出色的工作流程,但实际上它对我有用,等待找到更好的方法来满足我的需求。

    不幸的是,我仍然无法解释在挑选最后一次提交时导致冲突的具体逻辑(功能的部分更改)。我知道我做错了,但不知道这些特定文件部分的冲突是如何产生的。

    【讨论】:

      猜你喜欢
      • 2014-10-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2022-11-03
      • 2023-01-18
      • 2017-11-25
      相关资源
      最近更新 更多