1

我似乎搞砸了我的 git 存储库，可能是犯了“不要对已推送到公共存储库的提交进行变基”的罪过。

场景是这样的：

  • 我在我的 master 分支中跟踪来自上游存储库的更改，我将自己的更改保存在一个名为 devel 的分支中。
  • 当上游存储库发生更改时，我将其拉入主分支。
  • 然后我结帐开发并rebase master对其进行操作，以在主分支之上进行我自己的更改。这会导致冲突，在几次提交时会出现以下错误消息（我在下面仅包括其中一个作为示例）：

回退到修补基础和 3 路合并... 自动合并 public/scala/qscript/org/broadinstitute/sting/queue/qscripts/AlignWithBWA.scala CONFLICT（内容）：在 public/scala/qscript/org 中合并冲突/broadinstitute/sting/queue/qscripts/AlignWithBWA.scala 未能合并更改。补丁在 0038 失败 添加了对索引文件的检查。

解决此问题后，运行“git rebase --continue”。如果您希望跳过此补丁，请运行“git rebase --skip”。要检查原始分支并停止变基，请运行“git rebase --abort”。

  • 然后我使用git rebase --skip跳过导致问题的提交，最后得到我想要的代码。

现在，问题是，每次我想变基时，我都必须经历这个过程。我有什么办法可以避免将来发生同样的冲突吗？我的想法是使用push --force origin devel, 覆盖远程存储库中的历史记录，而不会导致冲突的提交。这是要走的路吗？或者有没有其他方法可以解决这个问题？

4

3 回答 3

1

假设上游没有重写公共历史，您应该调整您的提交以在 master 的最新代码之上工作。相反，您正在跳过该冲突的提交。您需要改为解决冲突，然后使用git add, 标记它们已解决，然后git rebase --continue(not --skip)。

冲突不断发生的原因是因为您每次都在跳过它们。

这样做git push --force会为使用该分支的其他人重写公共历史记录（您可能会删除或重新排序他们已经拉下并在其上工作的提交）。最好避免这种情况。

于 2012-09-21T12:17:51.463 回答
1

推力只能在最可怕的情况下进行。

如果自您开始工作以来其他任何人对远程分支进行了任何更改，您实际上将覆盖它们。

所以你最好手动解决冲突。

如果代码在同一行有更改，您需要手动解决它们。使用武力不是“解决”它们的方法。

你不会每次都遇到冲突，如果这是你的经验，那只是在你学习的时候，而在你这样做、实验和学习的时候，有些事情可能会发生。

要考虑的另一个选择可能是只获取代码，制作副本，删除 -r .git 目录并为其创建一个新的 git repo (git init)。

于 2012-09-21T12:23:51.207 回答
1

我认为git push --force这里不是一个好主意。在任何情况下，在使用之前，git push --force您都应该做类似的事情git fetch，并git diff devel origin/master查看您在推送中添加和删除的内容，并记住，在--force其他开发人员收到警告之后，可能需要重新调整并重新推送他们的更改。

  1. 我希望git rebase --skip您跳过开发者的提交，而不是获取主人的提交；
  2. 在“rebase”之后应该能够在没有“--force”的情况下推送（除非新的提交足够快地到达那里需要另一个 fetch/rebase 周期）。

一些注意事项：

  • 如果您不想一遍又一遍地解决相同的冲突，可以使用“git rerere”
  • Git 自动将远程内容镜像为“origin/master”，您可以使用“git fetch”对其进行更新。然后你可以在你的开发中使用“git rebase origin/master”，而无需在“master”分支之间来回切换。
于 2012-09-21T12:52:12.970 回答