我们的项目已经使用git一个星期左右了,而且我们都非常享受它(在紧密的协作组中,它变成了一个完全不同的git体验).为了使事情尽可能简单,我们不会进行任何变基或历史修改.但我们确实在第一周犯了一些错误.做了一些不应该做的提交,我们设法将一个功能分支合并到错误的集成分支(1.1而不是1.0).在他们长期进入我们的历史之前,我们没有发现这些事情.
现在我看到很多关于重写历史的警告,但我不确定我是否理解所涉及的危险.我们使用共享的裸存储库,并将所有分支推送到那里进行备份.
我希望如果你重写历史记录(比如删除一个提交),后续提交的完整列表将"丢失"该提交(并且可能不会编译/工作).我也希望如果发生这种情况,我实际上可以选择在历史的顶部解决这个问题(并将这部分历史留作非编译).
任何关于这个主题的文章/教程的参考也会非常好.
Gre*_*ill 17
必读参阅是Git用户手册中重写历史记录的问题.
如果我重写历史(并且一切都在所有受影响的分支中编译/工作),我的同事是否需要做任何特殊命令(即如果我做得好,他们会"知道我已经完成了吗？")？
他们会知道,Git会毫不含糊地告诉他们有什么不对劲.它们将获得意外的错误消息,并且可能在尝试解决由此产生的合并冲突的过程中,无意中还原了以前的提交.此问题会创建一个真实的消息,如果您想知道发生了什么,您可以随时在存储库的临时副本上进行尝试.
任何具有我不知道的本地更改的用户是否有资格在git pull上合并失败？
绝对,见上文.
我错过了这里必不可少的东西吗
避免以(几乎)所有成本重写历史记录!
正如其他答案评论中所提到的,实际上每个提交都是唯一的,重写历史记录将进行新的提交.
您可以将其视为切断树枝,然后立即生长新树.他们甚至可能看起来相同但不是.是的,伏都教魔法.在这个类比中,恢复将几乎就像支持一个带有日志的下降分支,因此它将不会下降而增长.
这导致我们有几个很好的理由来重写历史:
那些已经揭示了Greg已经说过的内容:如果存储库是公共的(推送提交),重写历史可能会搞砸每个人.之所以我也提倡不惜一切代价避免这样做,即使是在私人回购中,只是为了保持良好的习惯:所以应该不惜一切代价避免重写历史 (这意味着在做之前要给予足够的考虑:减轻专业人士的负担和缺点!)
至少还有另一个哲学和被忽视的原因:重写历史就是数据丢失.没错,git历史revert可能看起来比一个更混乱reset.但是如果写得恰到好处,那些"乱七八糟"的东西都可以隐藏在分开的分支中,但我们仍然可以准确地看到恢复的完成点.甚至有理由或证据表明为什么要这样做.
回到树的比喻,即使你删除支持日志,回复的分支将显示曲折的生长曲线,它是美丽的!
| 归档时间： |
|
| 查看次数： |
6006 次 |
| 最近记录： |