你能解释一下为什么你会在 Git 中锁定一个远程分支吗？答案

【问题标题】：Can you explain why you would lock a remote branch in Git?你能解释一下为什么你会在 Git 中锁定一个远程分支吗？
【发布时间】：2014-10-27 02:37:24
【问题描述】：

当观众中有人问我如何锁定远程分支以防止其他人推送时，我正在举行 GIT 的介绍性演示。

我理解为什么一直在使用 TFS 的人对此感到疑惑，但是有什么理由需要在 GIT 中锁定远程存储库吗？如果有，有哪些？

【问题讨论】：

相关：stackoverflow.com/questions/2471340/…
下面的 cmets 对“锁定远程分支”的含义存在一些争论。你能澄清一下吗？你的意思是“阻止任何进一步的推送”到那个远程分支吗？
另外，如果他们的意图不清楚，也许你应该让观众自己在这里发表他们的问题！

标签： git version-control tfs

【解决方案1】：

在 TFS 中锁定一个分支使其只读（参见“Making a TFS Branch Read-Only”）

Git 本身无法将分支设为只读：如果您有权访问 git 存储库，则将其全部克隆（及其所有分支），然后您可以在任何分支中提交。

您可以控制推送的内容：

server-side hook，就像一个更新挂钩（为每个推送的分支调用，see example）
authorization layer 和 gitolite 类似，可以用 access rules 保护分支。

这意味着您可以制定一个策略（hook 或 gitolite），以防止将修改后的分支推送到 upstream repo。

【讨论】：

【解决方案2】：

在大多数情况下，git 有不同的方式来处理这种情况（主要是：标记分支，删除分支）但是，回答你提出的问题——你为什么要这样做？ -- 答案是：防止分支发生变化。

这是一个有用的例子：很多 SCM 组织在产品快要发货时创建一个分支，以便分支可以受到严格的变更控制，但开发可以继续在 master (/main/trunk/等其他环境中）。

因此，例如，您可能有一个专用于 v2.1 的分支，该分支在发货前已发送给 QA，而在 v2.1 分支上允许的唯一更改将是管理层认为足够重要的那些更改包含在 v2.1 中。与此同时，团队的其他成员正在处理master，或分支v2.2，或v2.5，或Experimental-feature-branch等。

然后v2.1 发货。

同样，在 git 中，通常只标记交付的东西（SCM/SQA 中的一个重要概念是始终能够从用于创建客户的完全相同的源重新创建交付的构建has) 但是，既然有一个具有该名称的分支，那么在其生命周期结束时“冻结”该分支以便没有人可以进一步更改它不是很方便吗？

这主要是从 svn 和类似的其他环境中遗留下来的。一个以 git 为中心的商店可能会说“标记它并删除分支！”，但旧习惯很难改掉，人们喜欢继续使用熟悉的东西，所以他们最终会做一些事情，比如冻结分支。

我肯定是这样解决这个问题的，寻找一种方法来冻结我的 git 分支！ :)

【讨论】：

【解决方案3】：

“锁定”唯一代码状态的 git 方法是创建和推送标签。最常见的动机是跟踪代码的实际发布版本，例如：

git tag v0.1.37
git push --tags

现在可以签出该标签，就像它自己的分支一样。对标签有一个强大的命名约定很重要，因为您希望它绝对清楚任意状态代表什么。例如，如果它是应该由命名约定指示的 beta 版本。由于 git 是一个分布式系统，从技术上讲，提交者可以覆盖已发布的标签（使用--force），但这种行为并不常见（当然远不如重新定位分支常见）。

作为替代或附加，您可以使用gitosis、gitloite 和其他高级工具来提供更精细的安全性。

【讨论】：

我认为这个答案完全不合时宜。有一些方法可以防止推送到远程分支（使用像 update 这样的服务器端钩子就是其中之一），但是标签与 nothing 无关。
用户问“是否有理由需要在 GIT 中锁定远程存储库？如果是，是哪些原因？”这足够广泛，可以包括锁定代码状态的所有原因，从而引出我对标签的描述。
OP 询问锁定远程分支，而不是标记。标记未锁定。
标记保留了代码状态，这不仅是您在早期 VCS 中锁定分支的原因之一，而且是最常见的一个原因。对于其他任何事情，我将 gitosis 和 gitolite 关联起来以处理 repo 访问控制。
标签允许您将特定提交固定为具有某些历史重要性（例如发布，例如v1.2）；他们不允许您阻止进一步推动分支，这就是问题（据我所知）的意义所在。如果对此有任何疑问，OP 应该插话。