Git分支分叉了。

Question

我对Git很陌生，虽然理解其概念，但不认为我能很好地实践。

我被要求在分支uitest上工作，但由于我可能没有正确地完成推送、提交和拉取，我已经让分支产生了分歧。

由于我是新手，并且我也不想把其他开发人员的代码覆盖成我的代码或更改，因为我的代码或更改只是为了试用Git并学习它如何运作，所以如果需要，我愿意放弃我的更改，因为我有一份所有需要重新做的东西的备份。

$ git status
# On branch uitest
# Your branch and 'origin/uitest' have diverged,
# and have 47 and 6 different commits each, respectively.
#
nothing to commit (working directory clean)

我该如何“取消合并”？放弃我的更改并从最新的更改中拉取最新的更改，然后继续工作而不会干扰其他人的工作。

此外，由于我是新手，请在您的回答中稍微详细说明，因为它可能对我没有多少意义。

- Val

Answer 1

有几种方法。

合并

首先，您可以简单地合并“origin/uitest”，但是这不会留下干净的历史记录，因为它看起来像是一个分支和合并，尽管一直都是同一个分支。我相信Linus称这种合并提交为“无意义”。不幸的是，这也是最简单的方法。

变基

变基往往是一个更高级的主题，如果不小心就会引入一系列其他问题。话虽如此，它也是一种很好的方法，可以获得干净的历史记录而不需要无意义的提交。在这种情况下，您可以执行以下操作：

git rebase origin/uitest

从你的uitest分支开始，它将获取你所做的所有工作，并将其放在origin/uitest工作之上。

但是有一些限制。首先，如果你将其他分支合并到你的分支中，git rebase会删除它们。你需要传递-p标志以保留你引入的任何合并提交，但这并不总是正确的做法。如果你只是提交了自己的更改，那么我给出的命令应该可以胜任。

其次，任何时候使用rebase都应该记住永远不要rebase公共提交。因为父级已经改变，所以rebase会更改提交ID。如果人们正在合并你的工作，而你又对其进行了rebase，他们将在历史记录中得到你的提交的多个副本——这是不好的。因此，在应用此技术时要小心。

尽管如此，你还是想让git rebase成为你的好朋友。它是一个强大而有用的工具，但像任何强大的工具一样，它可能会很危险。

放弃你的工作

如果你只是想放弃你所做的工作，你可以运行：

git reset --hard @{u}

或者

git reset --hard origin/uitest

这将重置您的uitest分支以匹配上游或origin/uitest。它将丢弃您的提交。

个人建议重新基于工作或至少尝试一下。如果失败，或因合并冲突变得太复杂，您可以使用git rebase --abort中止操作，然后回退到合并或放弃更改（虽然合并可能会显示相同的合并冲突）。

- John Szakmeister

---

好的，git reset --hard origin/uitest 对我十分有帮助 :) 谢谢。我能在这里问个傻问题吗？我通常都是这样做的，你能帮我规划一个工作流程以避免这样的问题吗？我想打开文件，在本地进行更改直到我满意为止，然后当我觉得一切都正常时，我想要推送所有的更改... 我的意思是，我应该按什么顺序进行 push、pull、commit、add 等操作呢？我并不完全理解这些命令，因为我是新手，但我非常兴奋和有兴趣学习（GUI 综合症 [笑]）。 - Val

我认为大多数人使用 git pull，但我个人不喜欢这种解决方案。我倾向于使用rebase工作流程。所以我会执行 git fetch --all，git rebase @{u}，测试，然后 git push。第一个命令从远程获取最新的数据，第二个命令将我的更改重新定位到最近的上游提交之上，然后我进行测试，最后推送我的更改。如果有新的内容出现，我会重新开始这个过程。我也经常在单独的分支上进行工作，然后在主分支上执行 git fetch --all，git merge --ff-only @{u}，然后合并分支，测试并推送。这是我最常用的方法。 - John Szakmeister