Question

我有两个分支（主和功能）分歧。

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

C2和C4只是临时代码的脏提交，我不想进入两个分支的最终合并/ rebase。

我通常会执行：

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

但是这次我有C3冲突，我不能选择提交。

我尝试将C3重新引入功能分支，以便在挑选时不会产生冲突。

git checkout feature
git rebase master

现在我得到了这个

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

看起来很好，但是如果我再次尝试 cherry-pick 到主服务器上，我仍会遇到冲突（在一些空白区域我从某些文件中删除）。

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

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

为什么我在 rebase 之后仍然会遇到冲突？
如何在没有额外提交的情况下将C5合并/挑选到 master ？

我通常喜欢挑选，因为我可以避免'无用的'合并提交，并且只提交有关代码更改的提交。然后我删除了分支，过了一段时间我确定我不再需要了它

[[编辑]]

奇怪的行为是C5和C3在C3上没有改变的文件上发生冲突。

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

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

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

我没有得到冲突的原因
我想手动解决，然后 merge / cherry-pick ，而无需创建新的提交
- 因为提交将解决与将来将被删除的分支的一些冲突
- 删除分支时，该提交在存储库历史记录中没有意义/位置

[[EDIT 2]]

此外，如果我尝试`git cherry-pick master / C3 到功能，我得到：

没有更改添加到提交（使用“git add”和/或“git commit -a”）之前的挑选现在是空的，可能是由于解决冲突。

我不明白为什么我会在相反方向发生冲突（从功能到主）

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

这也是我尝试过的。

制作了主分支的两个副本，其中C3为最后一次提交，名为： master_copy 和 repeat_feature
- git checkout master / git branch master_copy / git branch repeat_feature
从功能分支中挑选每个提交，直到C5，进入 repeat_feature
- git checkout repeat_feature / git cherry-pick C2^..C5（来自功能）
- （我没有冲突）
尝试从 repeat_feature

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 ）！

我完全不明白发生了什么，为什么我得到这些空洞的冲突，阻止我将我的功能移到主分支。

这里需要专家的建议。

Answer 1

我完成了改变方法：

我制作了_feature_branch_（git checkout feature_branch / git checkout -b copy_feature_branch）的副本;
我'将所有分支提交压缩成一个
- 首先：我回到分支的父提交：git reset <branch_parent_commit>
- 第二：我使用git add .重新添加所有更改，然后使用git commit提交
- 最后我把这个提交添加到主分支中，只用一个提交来应用 feature_branch 中的更改（因为我想用C5做错误，错误解释 git cherry-pick ）。 git checkout master / git cherry-pick <last-commit-of-copy_feature_branch>）

通过这种方式，我完全没有冲突（正如我预期的那样）和我只获得了一次引入所有更改的提交（或者无论如何来自 feature_branch 的“更改数据包”。我制作了我的功能分支的副本，因此我可以暂时完成 WIP 提交的完整序列，这可能对于暂停有用（用于测试，应用修复，查看历史记录）特定功能的更改）。我没有删除分支，而是通常使用git branch -m <current_name> FINISHED_<current_name>重命名它，并保留它直到我不确定是否要删除它。

这不是一个很棒的工作流程，但实际上它正在为我工作，等待找到更好的方法来满足我的需求。

不幸的是，我仍然无法解释导致冲突的具体逻辑，只是最后一次提交（从功能部分更改）。我知道我做错了，但不知道那些特定文件部分的冲突是怎么出来的。

Answer 2

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

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

是的，cherry-pick 不用于合并某些已通过一系列提交开发的内容。它是为了将两个分支在其他提交中没有改变的代码行从一个分支应用小的更改到另一个分支。

主要的可能性是将feature C5州合并到master，同时避免一些脏C2和C4 to use squashing。

1。使用`merge`：

git checkout master
git merge --squash feature

2。使用`rebase`：

这可以通过交互式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 个答案:

1。使用`merge`：

2。使用`rebase`：

解决分歧的分支之间的樱桃挑选冲突而不提交

2 个答案:

1。使用merge：

2。使用rebase：

1。使用`merge`：

2。使用`rebase`：