有没有办法在使用 git 时锁定 fork 上的单个文件或目录？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/13662255/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is there a way to lock individual files or directories on fork when using git?
提问by Karthick S
We are a team of 60+ developers working on the same product and are moving from SVN to Git and GitHub. We have a process in SVN where in individual files are locked and whenever a developer wants to commit code, he needs to get it unlocked by the owner of the file. Three of us are the owners of the total 150+ files. The unlocking is preceded by a code review.
我们是一个由 60 多名开发人员组成的团队，他们正在开发相同的产品，并且正在从 SVN 迁移到 Git 和 GitHub。我们在 SVN 中有一个进程，其中单个文件被锁定，每当开发人员想要提交代码时，他都需要让文件所有者将其解锁。我们三个人是总共 150 多个文件的所有者。解锁之前需要进行代码。
In Github, we are planning to use the Fork-Clone model - each project a group of dev is working on will do a fork, each developer will do a clone of the fork, write the code & commit to origin, the lead of the feature will do a pull request to upstream.
在 Github 中，我们计划使用 Fork-Clone 模型 - 一组开发人员正在进行的每个项目都将进行一次 fork，每个开发人员将进行一次 fork 的克隆，编写代码并提交到 origin，负责人功能将向上游发出拉取请求。
Though this seems fine, the problem is when a big project gets delivered, it brings in lots of changes for review and hence, increases the load for the file owners. Also, this might happen in the later cycles of development and hence the project might be jeopardized.
虽然这看起来不错，但问题是当一个大项目交付时，它会带来很多变化以供，因此增加了文件所有者的负担。此外，这可能会发生在后期的开发周期中，因此项目可能会受到威胁。
One method we thought might work is to have hooks when the git push is done to the origin (fork). There can be one final review git pull to upstream.
我们认为可能有效的一种方法是在 git push 到原点（fork）时使用钩子。可以有一个最终 git pull 到上游。
However, we could not find any github extensions or push hooks for the same. Is there a quick way (read, existing extension) to do this with Github or should we use the same hooks that we would use with git?
但是，我们找不到任何 github 扩展或相同的推送钩子。有没有一种快速的方法（阅读，现有的扩展）可以用 Github 来做到这一点，还是我们应该使用与 git 相同的钩子？
采纳答案by Kyle Campos
This use case is one of the reasons Git is so much better than SVN --> rebase! If you follow good git workflow you rebase from upstream before submitting your Pull Requests. You don't need to worry about file locking and stomping on another person's commits and merge conflicts etc... a rebase sets your work aside, applies the remote commits and then applies your work on top.
这个用例是 Git 比 SVN 好得多的原因之一 --> rebase！如果您遵循良好的 git 工作流程，则在提交 Pull Request 之前从上游变基。您无需担心文件锁定和踩踏其他人的提交和合并冲突等...... rebase 将您的工作放在一边，应用远程提交，然后将您的工作应用到上面。
I think this just takes a rethinking in your process and relying on the strengths of git versus force fitting a Subversion workflow on top of git. Your "fork-clone" model might need another look as well. Most often every developer has their own fork, you can share repos via remotes between teams if you want. But contributors sharing the same origin sets up some bad habits.
我认为这只是需要重新思考您的过程，并依靠 git 的优势与强制在 git 之上拟合 Subversion 工作流程。您的“fork-clone”模型可能也需要再看看。大多数情况下，每个开发人员都有自己的分支，如果需要，您可以通过团队之间的远程共享存储库。但是同源的贡献者会养成一些坏习惯。
Gitflowis a very popular git workflow, and Github themselves has some nice tips and shares their workflow.
Gitflow是一个非常流行的 git 工作流程，Github 自己也有一些不错的技巧并分享了他们的工作流程。
回答by user5694595
No chance, if file is not mergeable and you need to lock it, use a centralized solution instead of GIT, i.e. SVN or ClearCase.
没机会，如果文件不可合并并且您需要锁定它，请使用集中式解决方案而不是 GIT，即 SVN 或 ClearCase。
回答by Nijin22
If you are using git LFS(which is supported by some git hosting providers, like GitHub) you could use File Locking.
如果您正在使用git LFS（某些 git 托管提供商支持，例如 GitHub），您可以使用File Locking。
Mark a file type as lockable by editing the .gitattributesfile:
通过编辑.gitattributes文件将文件类型标记为可锁定：
*.docx lockable
# Make MS Word files lockable
And lock it with:
并锁定它：
$ git lfs lock example.docx
You can unlock your files with git lfs unlock example.docxand those of somebody else by adding --force.
您可以git lfs unlock example.docx通过添加--force.
回答by Michael
Not exactly locking, but Github has introduced a concept called "Code Owners". Allows you to restrict part of your codebase to only allow commits after review by the code owners
不完全锁定，但 Github 引入了一个称为“代码所有者”的概念。允许您将部分代码库限制为仅允许在代码所有者后提交
回答by erradi mourad
this is possible. git-lfs 2.0 introduces the ability to lock files: see these links: https://github.com/git-lfs/git-lfs/wiki/File-Locking. Support for this feature is available starting from TFS 2017.2: https://docs.microsoft.com/en-us/vsts/release-notes/.
这个有可能。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/ 。
回答by Leonardo Torok
Git does not provide any locking functionality, since it is decentralized. However, if you host your code on GitLab Enterprise Edition Premium, you can use the web interface to lock individual files or folders, achieving exactly what you want to do.
Git 不提供任何锁定功能，因为它是分散的。但是，如果您在GitLab Enterprise Edition Premium上托管您的代码，您可以使用 Web 界面锁定单个文件或文件夹，从而实现您想要做的事情。
If you do not want to host your project on someone else's server (their website), you can also download GitLab and host it on your own webserver.
如果您不想在其他人的服务器（他们的网站）上托管您的项目，您也可以下载 GitLab 并将其托管在您自己的网络服务器上。
回答by Camilo Pineda
You can use LFS and you could lock individual files, or instead jus add the files to .gitattributes file,
您可以使用 LFS 并锁定单个文件，或者将文件添加到 .gitattributes 文件中，
回答by txinto
There is no way of doing it in Git. As others said, if the document is "mergable", you can try rebasing, changing the way you act.
In our case, we have a convention: if you REALLY need to lock it, rename it. But we only do such things in office documents, etc.
This constribution is not giving a solution, it is a workaround trick (but stackoverflow does not allow me to add this as a comment.
在 Git 中没有办法做到这一点。正如其他人所说，如果文档是“可合并的”，您可以尝试变基，改变您的行为方式。在我们的例子中，我们有一个约定：如果你真的需要锁定它，重命名它。但是我们只在办公文档等中做这样的事情。
这个贡献并没有给出解决方案，它是一种解决方法（但 stackoverflow 不允许我将其添加为评论。
