如何在不解决其他提交冲突的情况下在 git 中变基，或者压缩我的所有提交，同时不影响其他人的提交？答案

【问题标题】：How can I rebase in git without resolving other commit conflicts, or squash all of my commits while leaving others' commits untouched?如何在不解决其他提交冲突的情况下在 git 中变基，或者压缩我的所有提交，同时不影响其他人的提交？
【发布时间】：2020-12-07 16:51:05
【问题描述】：

 ---A---
/       \
---main--------
  \---B---+A------/
       \-----\--\C-?

以上是我团队repo的大致情况。功能 A 是一个巨大的分支，我绝对不得不独自离开。我从 B 分支出来，但一直定期从中拉出，这意味着我拥有 A 的所有更改，并且与分支 C 上的 main 保持同步。这也意味着在我对 C 的第一次和最后一次提交之间，有几十个提交加上来自 A 的巨大合并。我的 repo 要求每次推送到 main 都被压扁，我想避免重新提交其他所有人的工作作为我自己的工作，如果我在第一次 C 提交之前执行git reset --soft 就会出现这种情况，而git rebase -i 迫使我解决每一个冲突，即使是那些不是我自己提交的冲突。

如何在开始使用 C 语言之前“重置”并压缩所有提交，而无需解决所有其他分支的冲突或将每个提交重新提交为我自己的？

更新：我不完全确定如何，但是使用git reset --soft 在 C 的历史中间提交实际上完全符合我的要求，将我所有的更改都拉到前面的一个更改中。我很好奇上次我尝试时出了什么问题。从那里，我检查了 B 并使用了git merge --squash C

【问题讨论】：

从分支中提取更改以便压缩所有更改的一种方法是：git merge some-branch; (finish the merge if there are conflicts... when the new merge revision is done:) git reset --soft some-branch; git commit -m "single revision, no hassle"。但是你有一种复杂的分支历史，所以我不清楚你应该在哪个分支上合并什么。无论如何，希望这个技巧能让你继续前进。
为什么要进行已经完成的合并？您的工作依赖于A 或B 或main 历史中的哪些工作？您将不得不以某种方式识别它，因为这是您必须在合并回 main 时保留的内容。
解决其他冲突是什么意思？您的图表看起来像 A 和 B 合并到 main 中，所以只剩下您的冲突，对吗？还有什么阻止你做git merge --squash？
为什么B上有+A？ 特别是，因为看起来 A 已经合并到 main！并且B也被合并到main中，包括+A吗？
@ian 如果我尝试使用 git rebase -i 并将我的所有提交压缩成一个，同时仍然使用 pick 标志来处理其他人从 C 的创建到现在的提交，那么我最终不得不解决该变基操作中每个“选择”提交的冲突

标签： git github merge squash

【解决方案1】：

从 main 创建一个新分支。使用 git cherry-pick 获取 B 和 C 提交。

使用 git rebase -i HEAD~4 压缩最后 4 次提交

【讨论】：