3

基本上我一直在开发一个功能，但是当我将该功能推回主仓库进行代码审查时，他们喜欢将整个功能作为一个提交推送。我通常使用git rebase -i它并设置除了第一次提交到壁球和第一次编辑之外的所有内容。然后，每次发生冲突时，我都会粘贴最新的文件。

我宁愿不必在冲突期间粘贴各种文件。我希望能够保留最新的文件，并基本上以更简单的命令删除它们的历史。

编辑：

我正在寻找与此 bash 脚本等效的 Git 命令：

for file in `git diff --name-only master foo`
git checkout foo $file
4

2 回答 2

12

使用压扁的合并

你想要的是一个压扁的合并。这会将您的所有更改合并到工作树中，但实际提交取决于您。例如：

git checkout foo
git rebase -i master
git checkout master
git merge --squash foo
git commit -m 'Squashed commit.'

您从重新定位的分支中所做的所有更改都将作为单个提交进行，并带有单个提交消息。只要您解决了与foo分支中的 rebase 的任何冲突，当您合并到 master 时，合并应该不会产生冲突。

于 2012-07-17T19:20:56.173 回答
0

如果你git rebase -i '@{upstream}'（如描述的挤压）你可能有真正的冲突，需要真正的解决方案。如果您只是复制粘贴更改，那么您可能正在撤消自您开始功能开发回归功能以来发生的远程更改。

如果您知道这对单个文件是安全的，那么在变基期间您总是git checkout --theirs $file可以避免复制粘贴，尽管这将替换整个文件，这可以替换自动合并的大块；在这种情况下，“他们的”是正在应用的更改集，即您的更改。

如果您确定始终如此，则可以设置合并策略，例如git rebase -m -s merge-recursive -X theirs -i '@{upstream}'.

注意：这只适用于最新版本的 Git 中的交互式变基。

在我看来，一个更简单的方法是做git rebase -i\ git merge-base HEAD '@{upstream}'\（如所描述的挤压）有效地将分支重新定位到自身上。结果将不会在此步骤中解决合并冲突，因为更改是按照它们在相同代码上创建的相同顺序应用的。然后git rebase '@{upstream}'，您将以正常方式解决与上游的冲突。

更容易，假设您可以很好地管理文件，将是git reset\ git merge-base HEAD '@{upstream}'\。此时，您只需将更改的文件添加到阶段并进行新的提交，该提交可以重新设置，如上一段所述。

于 2013-07-19T01:06:06.893 回答