什么是“正确”的方法来确保其他人在进行耗时的合并/ rebase操作时不推送git远程仓库并且希望repo在这样做时保持稳定？是否有一种优雅的方式以只读模式 锁定 repo，直到一个人完成冗长的操作或运行测试套件以确保一切正常？
目前，我们正在使用....的创意（阅读：稍微非正统？）解决此问题的方法 - 我们在本地独立的SVN存储库上有一个特殊文件，每个团队成员都必须手动< / em> checkout（即执行'lock'）然后再推送到远程git repo。现在，这种方法（例如它）可以工作，但很容易出现错误和心灵滑动（有人，通常是新的团队成员，推动其他人的合并/改组）。
必须有一种更优雅的方式来做到这一点。
现在，我不是任何方式的git专家（我只是一个普通用户）但写一个自定义命令来做锁定不应该太繁重。但这并没有解决阻止 其他用户推送到远程仓库的问题，即如何让git repo意识到那里的某个地方，有一个标志 - 如果被提出 - 应该阻止用户推送回购。
有没有更标准的方法来解决这个问题，人们使用的现有模式是什么？有没有办法将整个仓库置于只读模式？
我对任何和所有建议持开放态度，但肯定希望避免引入新的存储库和/或专门的人员，这些人是唯一一个提出要推送到遥控器的人 - 我们希望所有的开发人员都拥有这种能力只是为了防止踩到对方的脚趾。
答案 0 :(得分：4)
是执行此操作的标准方法。正常使用git，这种情况永远不会发生。
Git是分布式版本控制系统。当您从存储库fetch进入A时，您会在您的存储库中获得副本的分支，名为A/branch_name。例如，在执行git merge origin/master时，您可能已经看到了这一点。更改远程存储库上的分支不会影响您的本地副本，直到您的下一个fetch，只要您决定就会发生这种情况。
那么，这是什么意思？让我们考虑以下行动：
A有分支branch。A获取并合并到您的本地branch。branch上推送A。所以在这一点上，你知道一切都在你的本地存储库上运行。但是，当你试图推动时，你不能。一些观察：
A的人与你并行做了同样冗长的测试，但是早些时候完成了。所以他确保branch上A的所有内容都可以。A锁定为只读，则在步骤6之前您不会知道，因为您无论如何都是从存储库读取。所以让repo只读是不会改变任何东西。现在这意味着你必须重复上述步骤。所以你必须再次fetch，merge再次进行冗长的测试。但这没关系，通常是做了什么，但并不像你想象的那么糟糕。
有两种可能性：
在第二种情况下，没有问题。合并将顺利进行，您不需要重复冗长的测试，因为每个子系统的测试是分开的（它们是，对吗？！）。也许你会在完全集成上运行测试。
在第二种情况下，会出现合并冲突，这意味着更多的合并冲突工作和再次运行测试。但无论你是否锁定了存储库，合并冲突迟早会表现出来。但是，如果你锁定了存储库，那么你的同事就必须处理冲突。最后，要么你或他必须这样做。