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 回答