使用 git 时，有没有办法在 fork 上锁定单个文件或目录？答案

【问题标题】：Is there a way to lock individual files or directories on fork when using git?使用 git 时，有没有办法在 fork 上锁定单个文件或目录？
【发布时间】：2012-11-19 16:18:28
【问题描述】：

我们是一个由 60 多名开发人员组成的团队，致力于同一产品，并且正在从 SVN 迁移到 Git 和 GitHub。我们在 SVN 中有一个进程，其中单个文件被锁定，每当开发人员想要提交代码时，他需要让文件所有者解锁它。我们三个人是总共 150 多个文件的所有者。解锁之前是代码审查。

在 Github 中，我们计划使用 Fork-Clone 模型 - 一组开发人员正在处理的每个项目都会进行一次 fork，每个开发人员将进行一次 fork 的克隆，编写代码并提交到 origin，该功能的负责人将向上游发出拉取请求。

虽然这看起来不错，但问题是，当一个大项目交付时，它会带来很多需要审核的更改，因此会增加文件所有者的负担。此外，这可能会发生在后期的开发周期中，因此项目可能会受到威胁。

我们认为可能有效的一种方法是在 git push 完成到源（fork）时使用钩子。可以有一个最终审查 git pull 到上游。

但是，我们找不到任何 github 扩展或相同的推送挂钩。有没有一种快速的方法（阅读，现有的扩展）可以用 Github 来做这件事，还是我们应该使用与 git 相同的钩子？

【问题讨论】：

我不觉得文件锁定是 Git 缺少的东西（这在 SVN 中很烦人）。在大多数情况下，我很确定拉取请求和分支是适合您的方式。您甚至可以使用子模块将项目的不同部分分隔在不同的 repo 中，然后在团队之间进行更清晰的分隔（文件保护）。因此，文件所有者将成为主要子模块的所有者，并且他会修改他的团队在其主分支上提出的每个拉取请求。然后每个用户都有自己的分叉。
programmers.stackexchange.com/questions/184435/…
@SimonBoudrias 如果将 git 用于不存在合并工具的任何文档类型（几乎总是如此），那么您的想法完全不起作用。使用 TortiseSVN/WebSVN 我们可以避免 MS Exchange，但使用 git 我们不能。在我看来，这是 git 的一个非常不幸的后备。
Locking binary files using git version control system
这不是技术问题；这是一个过程问题。为什么你需要 60 个开发人员来处理 150 个文件？似乎问题从那里开始。你使用什么编程语言？您的 150 个文件可能应该是 1500 个文件，然后您可以将其划分为模块。然后将您的开发“团队”（60 人，这不是一个团队，它是一个小村庄）拆分为由 7 人组成的更小的单元，这些人实际上可以作为一个团队发挥作用，并赋予他们对模块的所有权。这样，您和您的 2 位同事看门人将不再是瓶颈，每个人都会更快乐。而且你不需要锁。

标签： git github githooks github-api

【解决方案1】：

没有机会，如果文件不可合并并且您需要锁定它，请使用集中式解决方案而不是 GIT，即 SVN 或 ClearCase。

【讨论】：

这是正确答案。不是在撰写本文时接受的。赞成。它甚至不必是二进制文件就可以进行锁定。以另一个问题的 iOS 故事板评论为例。
iOS 故事板？ “其他”问题？可以给个链接吗？
我相信@Harindaka 的意思是“其他答案”，而不是“其他问题”。引用的评论是：stackoverflow.com/questions/13662255/…
我们的一个用例是一个高度规范化的 XML 文件。例如，我们有一个字符串表。如果有人修改了文件中的字符串，则必须更改表并假设它是按字母顺序排列的，它之后的每个字符串引用都必须加一。总而言之，文件中差异的微小变化，但合并的噩梦。因此我们锁定。尽管如此，差异的存储是作为 UTF-8 文件差异完成的，与存储整个文件相比，差异相对较小。 SVN 非常适合这种用例，非锁定系统会出现重大问题。
听起来像是可以/应该自动生成而不提交到存储库的东西。还是我们手动完成所有这些更改？

【解决方案2】：

如果您使用git LFS（一些 git 托管服务提供商支持，例如 GitHub），您可以使用File Locking。

通过编辑.gitattributes 文件将文件类型标记为可锁定：

*.docx lockable
# Make MS Word files lockable

并将其锁定：

$ git lfs lock example.docx

您可以使用git lfs unlock example.docx 解锁您的文件，也可以通过添加--force 解锁其他人的文件。

【讨论】：

【解决方案3】：

这是可能的。 git-lfs 2.0 引入了锁定文件的能力：请参阅以下链接：https://github.com/git-lfs/git-lfs/wiki/File-Locking。从 TFS 2017.2 开始支持此功能：https://docs.microsoft.com/en-us/vsts/release-notes/。

【讨论】：

【解决方案4】：

您可以使用 LFS 并且可以锁定单个文件，或者将文件添加到 .gitattributes 文件中，

https://github.com/git-lfs/git-lfs/wiki/File-Locking

【讨论】：

请在此处自己写下答案的相关部分，因为链接可能会随着时间而改变。

【解决方案5】：

Git 不提供任何锁定功能，因为它是分散的。但是，如果您将代码托管在 GitLab Enterprise Edition Premium 上，则可以 use the web interface to lock individual files or folders 实现您想要做的事情。

如果您不想将项目托管在其他人的服务器（他们的网站）上，您也可以下载 GitLab 并将其托管在您自己的网络服务器上。

【讨论】：

这与 Gitlab 无关，使用 git lfs 也可以。 git-lfs 2.0 引入了锁定文件的能力：github.com/git-lfs/git-lfs/wiki/File-Locking。 TFS 2017.2 中提供了对此功能的支持：docs.microsoft.com/en-us/vsts/release-notes。

【解决方案6】：

不完全是锁定，但 Github 引入了一个名为“Code Owners”的概念。允许您将部分代码库限制为仅允许在代码所有者审核后提交

【讨论】：

【解决方案7】：

这个用例是 Git 比 SVN 好得多的原因之一 --> rebase!如果您遵循良好的 git 工作流程，您可以在提交拉取请求之前从上游进行 rebase。您无需担心文件锁定和踩踏其他人的提交和合并冲突等...... rebase 将您的工作放在一边，应用远程提交，然后将您的工作应用到上面。

我认为这只是需要重新考虑您的流程并依靠 git 的优势而不是强制在 git 之上安装 Subversion 工作流程。您的“分叉克隆”模型可能还需要另一种外观。大多数情况下，每个开发人员都有自己的分支，如果需要，您可以通过远程在团队之间共享存储库。但是同源的贡献者会养成一些坏习惯。

Gitflow 是一个非常流行的 git 工作流，Github themselves has some nice tips and shares their workflow。

【讨论】：

只要您有可合并的文件，它就可以工作。如果你有二进制文件（如 Word 文档），你会被卡住。
Git 并不比 svn 好多少，反之亦然。 Git 非常适合使用非二进制文件的开发人员。在我们公司的二进制案例中，我们选择了 svn，因为它比 git（在我们测试的场景中）更好地处理大型二进制文件（20mb+ 和 100+ 版本）ps：我喜欢 git，
投了反对票，因为你没有提供解决方案，而是让人们相信他们不需要他们想做的事情，因为 Git 还有其他东西。如果您在其他人的更改之上重新调整您的更改，这是否意味着不会有任何冲突（即编辑相同的行）并且您肯定不会覆盖其他人的工作。我真的不这么认为
@pan40 你不能。句号
我不同意这个答案，因为 rebase 不是处理冲突的灵丹妙药，甚至更糟！ SVN 锁的目的是警告人们有人正在对文件进行大量修改，除非有人对工作副本进行欺骗或滥用强制窃取锁。在 Git rebase 中，如果一个人将多个提交应用于其他人修改的同一个文件，他将不得不解决每个提交重放的冲突。在这种情况下，合并会更便宜，因为您解决了一次冲突，但这不是锁定的目的。当然，良好的项目管理和协调会有所帮助