英文:
Git conflicts when rebasing on squashed code
问题
I will provide the translation of the text you've provided:
"我会尽量以我理解的方式，尽可能简单地解释问题。
所以，作为基础分支，我正在使用另一个分支（非主分支），其中包含我需要的更改。
但是当基础分支合并到主分支并且当我想要与主分支进行变基时，我遇到了40多个步骤的 git rebase --continue，并且在 --continue 命令之后大多数文件都是相同的。例如，完全相同的冲突文件会在1或2个 --continue 命令后再次出现。而且那些是我没有修改的行。
我认为显示这些冲突文件的原因是因为在主分支上它们被压缩在一起，但在我的代码中，它们在不同的提交中。但是仍然不能解释为什么我一遍又一遍地得到相同的冲突文件。
对于所有的40多个冲突，是否可以运行 git rebase --skip，或者我应该手动更新它们中的所有内容，选择 当前更改？因为主分支上的代码在冲突中显示为 当前。
如何处理这种类型的冲突的最佳方法是什么？
我看到很多关于 --skip 的帖子，但它们没有回答我的问题。我有点担心，如果跳过会跳过来自主分支的实际提交，而且在差异中看不到它，并且当我将分支合并到主分支时，它将删除主分支上的提交和代码。
在标题上可能不是特别有帮助来理解，所以如果您建议，我可以根据您的建议进行更改。"
英文:
I will try to explain the issue as I understand and as easily as possible.
So as a base branch, I am using another branch (non-master) which includes changes that I need.
But when the base branch is merged to master and when I want to rebase with master I face 40+ steps git rebase --continue and most of the files are the same which appears after the --continue command. for example, the exact file with the exact conflict appears after 1 or 2 --continue commands again. And those are the lines that I don't touch.
What I think is the reason why it shows up is because on master it is squashed but in my code, those are in separate commits. But still, it doesn't explain to me why I am getting the same conflict file over and over again.
Does git rebase --skip for all 40+ okay to run or I should manually update all of them to choose current changes? because the code on the master show as current in conflict.
What is the best way to deal with that kind of conflict?
I see a log of posts about --skip but they don't answer my questions. I am a bit afraid of what if skip will skip the actual commit coming from the master and will not be visible in the diff, and when I merge the branch to the master it will delete the commit and code from the master branch.
On the title it might not be super helpful to understand so I you suggest I can change it according.
答案1
得分: 1
这是压缩合并的不幸副作用：关于哪些提交被合并的信息不仅保留在 git 中。
您可以通过识别需要重新基础的历史的哪个部分来重新基础您的工作：
- 在您的分支历史中，找到哪个提交已合并到主分支
- 记下该提交的
<sha> - 运行
git rebase --onto master <sha> my-branch
英文:
This is an unfortunate side effect of squash merge: information about what commits got merged is not kept in git alone.
You can rebase your work by spotting what part of your history needs rebasing :
- in the history of your branch, spot what commit got merged into master
- write down the
<sha>of that commit - run
git rebase --onto master <sha> my-branch
答案2
得分: -2
我创建了一个新分支，并使用cherry-pick将旧的提交复制到之前在rebase上出现问题的分支上。看起来它按预期工作了。
英文:
What I did is creating a new branch and do cherry-pick to copy old commits from then branch which had issues on rebase. seams it worked as expected
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论