34

我们的项目已经使用 Git 大约一周了，我们都非常喜欢它（在紧密协作的团队中使用它，结果证明是完全不同的 Git 体验）。为了使事情尽可能简单，我们不做任何变基或历史修改。但是我们在第一周确实犯了一些错误。进行了一些不应该进行的提交，我们设法将功能分支合并到错误的集成分支中（1.1 而不是 1.0）。直到它们进入我们的历史很久之后，我们才发现这些东西。

现在我看到很多关于重写历史的警告，但我不确定我是否理解所涉及的危险。我们使用共享的裸存储库，所有分支都推送到那里进行备份。

我希望如果您重写历史记录（例如删除提交），后续提交的完整列表将“丢失”该提交（并且可能不会编译/工作）。我还希望，如果发生这种情况，我实际上可以选择在历史的顶部解决这个问题（并将历史的那部分保留为非编译）。

  • 如果我重写历史记录（并且所有内容都在所有受影响的分支中编译/工作），我的同事是否需要执行任何特殊命令？（换句话说，如果我做得好，他们会“知道我做到了”吗？）
  • 任何具有我不知道的本地更改的用户是否有资格合并失败git pull？
  • 我在这里错过了什么重要的东西吗？

对有关此主题的文章/教程的任何引用也将非常好。

4

2 回答 2

22

必读是Git 用户手册中重写历史的问题。

如果我重写历史（并且所有内容都在所有受影响的分支中编译/工作），我的同事是否需要执行任何特殊命令（即，如果我做得好，他们会“知道我已经完成了吗”？）？

他们会知道，Git 会毫不含糊地告诉他们出了什么问题。他们将收到意外的错误消息，并且可能在尝试解决由此产生的合并冲突的过程中，无意中恢复以前的提交。这个问题会产生一个真实的消息，如果您想知道会发生什么，您可以随时在存储库的临时副本上尝试它。

任何具有我不知道的本地更改的用户是否有资格在 git pull 上合并失败？

绝对的，见上文。

我在这里错过了什么重要的东西吗？

避免（几乎）不惜一切代价重写历史！

于 2009-09-29T07:08:58.057 回答
8

正如其他答案评论中提到的，实际上每个提交都是唯一的，重写历史将进行新的提交。

你可以把它想象成砍掉一棵树的树枝，然后立即长出新的树枝。它们甚至可能看起来相同，但实际上并非如此。是的，巫毒魔法。在这个类比中，还原几乎就像用一根原木支撑一根落下的树枝，所以它会按照自己的方式生长而不会倒下。

这让我们有几个很好的理由来重写历史：

  • 在公开之前精简私有存储库：例如，创建一个新的本地私有分支、测试、测试、重写、推送。
  • 在公开之前从私人仓库中删除敏感数据。

这些已经揭示了 Greg 已经说过的内容：如果存储库是公开的（推送提交），重写历史可能会搞砸每个人。为什么我也主张不惜一切代价避免在私人回购中这样做的原因，只是为了保持好习惯：因此应该不惜一切代价避免重写历史 （这意味着在这样做之前要给予足够的考虑：权衡利弊和缺点！）

而且至少还有另一个哲学上被忽视的原因：重写的历史就是数据丢失。诚然，一个 git 历史revert可能看起来比一个更混乱reset。但是，如果编写得当，所有这些“混乱”都可以隐藏在单独的分支中，我们仍然可以准确地看到在什么时候完成了还原。甚至有理由或证据说明为什么这样做。

回到树的类比，即使去掉了支撑原木，恢复的树枝也会呈现出蜿蜒的生长曲线，很漂亮！

于 2013-09-17T20:16:55.540 回答