在 git rebase 后清理分支

Question

3

当涉及到Git时，我通常比较能胜任，但在这种情况下，我不确定发生了什么，并且什么是最好的解决方案。

情境：

在这种情况下，我做错了什么？ 我想保持独立地在我的featureBranch上工作，直到它被修复，在那时，确保我的更改应用于最新的dev以避免冲突。在这种情况下，我的团队鼓励使用rebase。

为什么来自dev的新提交显示在我的PR featureBranch >> dev中，当它们已经在dev上了？

将我的PR带回到原始提交的最佳解决方案是什么？ 我不是指压缩，我是说dev的commits不应该在这里。

- johnny_mac

3个回答

4

git状态显示本地特性分支和远端特性分支发生了分叉，需要进行git pull操作。

当您执行rebase操作时，实际上是在更改您的分支历史记录。这将与origin上的历史记录不同，但这是可以接受的，因为这就是您想要的结果。在此步骤中，您可能应该通过运行push -f到origin/yourFeatureBranch来强制推送。

- eugecm

1

没错，只不过比我晚了11秒钟 ;) - VonC

3

git status显示本地和远程的featureBranch分支已经分叉，需要进行git pull操作。

这是正常的，因为你已经重写了本地分支的历史记录，与原始版本（上游跟踪）不同。

进行git pull操作会打开一个提交信息终端。

是的，你在这里要么不进行pull，本地合并后再推送到远程；要么强制推送到远程，以反映你重写的分支版本。如果你进行pull，就会再次将原始历史记录合并到你的重写历史记录中，这违反了重新设置的目的。

在这种情况下我做错了什么？我想保持独立工作在我的featureBranch上，直到它修复好，并在那时确保我的更改应用于最新的dev以避免冲突。在这种情况下，我的团队鼓励使用rebase。

（在你的情况下）你所做的“错误”是在重新设置后再次拉取分支。相反，你应该小心地进行强制推送（例如：git push myremote mybranchname --force）。如果你养成总是在强制推送时指定远程和分支名称的习惯，你就不太可能覆盖你没有预料到的东西。

为什么dev中的新提交在我的PR featureBranch >> dev中显示，而它们已经在dev中了？

因为你进行了重新设置，但随后又将原始版本拉回到了你的重写版本中，导致分支历史记录混乱。你应该期望成功的重新设置只显示你的提交请求中的你的提交。

将我的PR恢复到1个原始提交的最佳解决方案是什么？我不是指压缩，我是说dev提交不应该在这里。

如果你上次推送到远程以来除了重新设置之外没有更改任何内容，我建议重置并重新设置：

git reset --hard yourremote yourbranchname
git rebase devbranch
git push yourremote yourbranchname --force

希望这能有所帮助。

- scrowler

如果你养成了每次强制推送时都...的习惯，我宁愿一开始就不养成强制推送的习惯。无论如何，非常感谢你详细的回答 :-) - cmaster - reinstate monica

是的，有些人反对它。我想这取决于你所贡献的项目的上下文。有些人会要求您在他们查看之前将您的PR重新基于主干并/或将其压缩为一个提交，而另一些人则认为最好保留未压缩的提交以便更好地查看变更。感谢您的评论 :) - scrowler

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- VonC · Accepted Answer

这个情况下我做错了什么？

第二次执行git pull。当您完成变基后，应该会有一个git status提示您已经分叉。
但是从那里，您应该强制推送（git push --force），以用新的历史记录替换您的PR分支的远程历史记录。
特别是您是唯一在处理此PR的人时，这一点尤为重要。