到目前为止,我经常在以下两种情况下进行交互式git rebasing:未推送的工作,或者我肯定是唯一可以从事的推送工作。
我知道在进行协作工作时,挤压提交和整体重写历史可能很棘手。
什么是最佳实践,以尽可能减少痛苦?
如果我压挤一些提交并推动,那么回购在他的同事站上时回购将如何?
我知道重写历史这个概念是一场永无止境的辩论,但是在这里,我只是在寻找一种技术解决方案来解决这个问题。
什么是最佳实践,以尽可能减少痛苦?
最佳做法是避免这种情况。
正如ElpieKay所建议的那样,有一个“发布分支”(一个安全的历史记录和稳定的事物)是一个好习惯,而且还有一个“开发/功能分支”,在这里您可以做任何想要的事情,直到将它们合并/重新设置为基础您稳定的主分支。
要回答您的问题:
- 当他没有任何变化而只需要更新时?
当没有做任何更改并拉动时,git会将远程--force
控制器的历史记录作为正确的历史记录(因为有人显然被按下了,所以必须正确。)因此它将覆盖您的协作者的工作并使提交历史记录与历史记录匹配在远程服务器上。它将与附加消息一起显示,就像force update
您强行推入某些东西时一样。
注意,旧的提交实际上并不会被删除-只是“隐藏”,因为它们与其余的提交图没有关联。因此,如果您突然需要再次访问“已删除”的提交,那么只要您在某处拥有丢失提交的SHA哈希,就可以实现。git垃圾清理程序在存储库上进行一定数量的操作后,将删除无法访问的对象。
- 当他做了一些更改,并且想要在提交之前更新吗?
显然,那是最坏的情况。无论如何,通过提交更改(即使您以后要应用这些更改!),并创建一个临时的新副本,确保您拥有所有更改和分支的备份副本。
git add . ; git commit -am "Describe all my changes here" ; git branch backup
现在,您的更改已安全地存储在备份分支中,您可以再次删除提交。
git reset --hard HEAD~
然后拉当前分支
git pull
这应该可以在没有任何合并冲突的情况下正常工作,因为它基本上代表情况#1,其中没有进行任何更改,只会使本地历史记录与远程历史记录匹配。现在,您可以再次应用更改(=backup
分支上的最新提交)来再次应用更改。
git cherry-pick backup
显然,当远程存储库更新代码的相同行时,这可能导致合并冲突。如果没有冲突,则可以删除backup
分支。您的存储库是最新的,并且您的更改已应用到它的顶部。
但是,再次避免这些情况。合并前先在单独的功能分支中进行压缩/重新设置,或者合并后保持提交不变。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句