tim*_*oil 13 git git-fetch git-remote
使用git fetch --prune删除远程计算机上的分支时删除本地远程跟踪分支.使用以下命令将remote.origin.prune设置为true ...
git config --global fetch.prune true
...使用fetch命令总是隐式使用--prune选项.
我正在为我的小组中不熟悉它的一些开发人员整理git的最佳实践/介绍.在建议他们这样做之前,我想确定我知道这不是一种危险的行为.如果发生一些无关紧要的事故,我至少会让他们了解需要注意的事项.
它似乎不是一个破坏性操作,因为它不会删除任何本地(非远程)分支.如果没有定期指定git fetch --prune或git remote prune,这似乎是一种不构建不再使用的遥控器的好方法.
如果这都是真的,为什么这不是git的默认行为？
tor*_*rek 13
这并不是根本危险,我一直想把它设置在我自己的--global环境中,但我从来没有:主要是因为它对我的价值相对较小.1
正如您所注意到的,本质上,origin/zorg一旦分支zorg不再存在,意图就是删除origin.由于这对你自己没有直接的影响zorg,如果你有一个,它通常是无害的,并且你对远程跟踪分支的观点进行了整理.唯一可能的两个缺点是:
如果某人错误地删除zorg了上游存储库,并且所有下游副本都删除了它们origin/zorg,则会丢失该zorg上游存储库中提示的提交ID(可能还有许多提交本身).所以它放大了一些错误的影响.(当然,如果上游存储库非常重要,那么您可能应该进行备份 - 但是如果您选择使用克隆作为备份,则自动修剪会有一个缺点.当然,您可以始终禁用自动剪枝.备份.)
假设你也有自己的zorg被跟踪origin/zorg,和上游zorg被删除(故意这段时间).请注意,您origin/zorg可以通过它向您提供git status信息,告诉您之前提交的提交数量origin/zorg.假设您现在想要移动这些提交,而不是将那些用于上游的提交移动到您自己的另一个分支.在这种情况下,自动修剪自己origin/zorg使得很难分辨哪些提交是你的,哪些已经在上游.
请注意,在案例2中,您不会丢失任何提交.你失去的是能够告诉你,例如,目前你手中的最后三个提交zorg都是你自己的,之前有几个(现在不在任何其他分支上),最初都是origin/zorg.
1多年来,修剪代码有时会被破坏,主要是在修剪失败方面.这意味着Git开发人员自己可能不会使用它(但现在应该会更好,因为现在Git的内部测试套件中有测试,以确保修剪在新版本中正常工作).因此,在"低价值"和"过去的测试不足"之间,至少在当时,有充分的理由不设定它.
| 归档时间： |
|
| 查看次数： |
1364 次 |
| 最近记录： |