英文:
squash hundreds of commits and rebase kicks off a large conflict resolution
问题
我有一个名为"长期特性"的分支，我在过去的两个月里一直在这上面工作。它有211次提交，我想在这个"长期特性"分支能够与"origin master"合并之前将它们压缩成一个单独的提交。当我运行"git rebase -i HEAD~210"时，它启动了一个超过500次冲突解决过程。
最佳的压缩提交和完成重置的方法是什么？
当我执行以下操作时：
git rerere
git rebase -i HEAD~210
# 将所有的 "pick" 改为 "squash" 并保存退出，然后编写单一的提交消息
然后它会呈现给我大约500个或者更多的冲突需要解决，这是我的问题。也就是说，有没有办法可以摆脱这些冲突？
只有4个文件不断重复，并且git rerere没有提供太多帮助。
我另一个困扰是，为什么当提交只有211次时，我却得解决500多个冲突？
我一直在研究合并与重置的区别，看起来唯一的区别就是是否保留历史记录，但实际上这两种方法的过程相当不同。合并工作得很好，但重置却引起了很多麻烦。我一直在考虑创建另一个特性分支并运行git merge --squash来消除提交，但是我的同事已经在基于我的"长期特性"分支的PR上进行了提交，我希望能找到一种方法解决这个问题，而不必创建另一个分支。
英文:
I have a "long lived feature" branch that i have been working for last 2 months. It has 211 commits that i want to squash into single commit before this "long lived feature branch" can be merged with "origin master". When i run "git rebase -i HEAD~210" it kicks off a conflict resolution process of more than 500 conflicts.
What's the best way to squash commits and complete rebase ?
When i do:
git rerere
git rebase -i HEAD~210
# change all "pick" with "squash" and save and exit followed by single
# commit message
It will then present me with 500 or so conflicts to be resolved which is my problem. i.e. is there any way i can get away with it?
There are only 4 files that keep repeating and git rerere hasnt been of much help.
My other confusion is why i get more than 500 conflicts to be resolved when the commits are 211?
I have been reading on merge vs rebase and the difference seems to be only retaining history or not but in effect processes are quite different. merge works fine but rebase creates a lot of trouble. I have been thinking of creating another feature branch and run git merge --squash to get rid of commits but my colleagues have already committed on a PR based on my "long lived feature branch" and i would prefer a way to sort out this issue without creating another branch
答案1
得分: 1
以下是翻译的部分：
这是一个制作分支并将特性分支引入的所有更改压缩到一个单一提交中的配方：
# 从你的特性分支：
git switch my-long-lived-branch
# 创建一个工作分支：
git switch -c my-squashed-branch
# 将所有更改合并到一起，放在最后一次与主分支同步的同步点之上：
git reset --soft $(git merge-base HEAD master)
# 并提交：
git commit # 所有更改都在一个提交中
现在你有了 my-squashed-branch，它引入了与你最初的分支完全相同的更改，只有一个提交。该提交基于你同步 master 与你的分支的最后一个点。
你可以直接从这个压缩分支打开一个拉取请求，或者运行 git fetch; git rebase origin/master 在打开拉取请求之前将其重新基于 master 的最新版本。
如果在最后一次 rebase 中出现冲突，至少它们将被包含在一个单一的提交中。
注意: 如果该分支修改了500个文件，并且不幸的是，这些同样的500个文件也已经在主分支上被修改，你可能会有500个冲突，尽管只有一个提交。
冲突的数量受到单个文件更改的数量（如果你有200个提交，你需要计算每个提交中文件更改的数量之和）的限制，而不是仅仅由提交的数量决定。
英文:
Here is a recipe to create a branch which groups all the changes brought by your feature branch squashed in one single commit:
# from your feature branch:
git switch my-long-lived-branch
# create a working branch:
git switch -c my-squashed-branch
# bring all changes together, on top of the last sync point with master:
git reset --soft $(git merge-base HEAD master)
# and commit:
git commit # all changes in one commit
You now have my-squashed-branch, which introduces the exact same changes as your initial branch, with only one commit. That commit is based on the last point in master where you synced master with your branch.
You may open a pull request directly from that squashed branch, or run git fetch; git rebase origin/master to rebase it on the latest version of master before opening that pull request.
Should there be conflicts in that last rebase, at least they will be contained to one single commit.
note: if the branch modifies 500 files, and that out of bad luck these same 500 files have also been modified on master, you may have 500 conflicts even though there is one single commit.
The number of conflicts is bound by the number of individual file changes (if you have 200 commits, you would have to sum the number of file changes in each commit), not by the number of commits alone.
答案2
得分: 1
If in the end you want to have a single commit to then merge into the main branch, then you can just as well merge with the main branch and then do a soft reset.... "tomato/tomato", "potato/potato".
git checkout my-long-branch
git merge main-branch
# get that merge finished if there are conflicts....
# when the merge commit is finished:
git reset--soft main-branch
git commit -m "a single commit for my long branch"
# now if you try to merge that into the main branch, it should be fine
英文:
If in the end you want to have a single commit to then merge into the main branch, then you can just as well merge with main branch and then do a soft reset.... "tomato/tomato", "potato/potato".
git checkout my-long-branch
git merge main-branch
# get that merge finished if there are conflicts....
# when the merge commit is finished:
git reset--soft main-branch
git commit -m "a single commit for my long branch"
# now if you try to merge that ibto main branch, it should be fine
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论