我们是一个由60多名开发者组成的团队，他们正在开发同一个产品，并且正在从SVN转向Git和GitHub。我们在SVN中有一个过程，在这个过程中，单个文件被锁定，当开发者想要提交代码时，他需要由文件的所有者解锁。我们中的三个人是总共150多个文件的所有者。解锁之前需要进行代码审查。
在Github中，我们计划使用Fork-Clone模型-每个项目一组开发人员将进行一次fork，每个开发人员将进行一次fork的克隆，编写代码并提交到源代码，功能的负责人将向上游发出拉取请求。
虽然这看起来不错，但问题是当一个大项目交付时，它会带来大量的修改以供审查，因此增加了文件所有者的负担。而且，这可能发生在后面的开发周期中，因此项目可能会受到危害。
我们认为一个可行的方法是在git push到origin（fork）时使用钩子，可以有一个最终的检查git pull到上游。
然而，我们找不到任何github扩展或push钩子。有没有一种快速的方法（读取现有扩展）可以在Github中实现这一点，或者我们应该使用与git相同的钩子吗？
8条答案
按热度按时间cig3rfwq1#
没有机会，如果文件是不可合并的，你需要锁定它，使用一个集中的解决方案，而不是GIT，即SVN或ClearCase。
ubbxdtey2#
如果你使用的是
git LFS（一些git主机提供商，比如GitHub，都支持它），你可以使用File Locking。通过编辑
.gitattributes文件将文件类型标记为可锁定：并使用以下命令锁定：
你可以用
git lfs unlock example.docx解锁你的文件，也可以通过添加--force解锁其他人的文件。ddhy6vgd3#
这是可能的。git-lfs 2.0引入了锁定文件的功能：请参阅以下链接：https://github.com/git-lfs/git-lfs/wiki/File-Locking。从TFS 2017.2开始提供对此功能的支持：是的。
nsc4cvqm4#
不完全是锁定，但是Github引入了一个叫做“Code Owners“的概念。允许你限制你的代码库的一部分，只允许在代码所有者审查之后提交
yhuiod9q5#
Git不提供任何锁定功能，因为它是去中心化的。但是，如果你将代码托管在GitLab Enterprise Edition Premium上，你就可以use the web interface to lock individual files or folders，实现你想要的功能。
如果您不想将项目托管在其他人的服务器（他们的网站）上，您也可以下载GitLab并将其托管在您自己的Web服务器上。
ego6inou6#
您可以使用LFS，并且可以锁定单个文件，或者只是将文件添加到.gitattributes文件中，
https://github.com/git-lfs/git-lfs/wiki/File-Locking
8yparm6h7#
供参考：
Git是一个分布式版本控制工具，所以集中文件来锁定它们是违背它的开发理念的，所以这是不可能的。
然而，我们也有办法达到同样的结果。
一种是使用
git-lfs，用于大型文件系统。但这需要你迁移git repo，安装git-lfs会改变git repo，卸载需要你再次迁移到git repo。如其文档中所述。这在其他答案中已经解释得更清楚。另一个解决方案是以某种方式使用git来达到同样的效果。比如使用
git pull的upload-pack来触发服务器上的命令，该命令将调用服务器上的某个命令（手动编写），该命令将以某种方式处理文件锁定。|post）--如果不是最初锁定它的人，而是其他人推送的，则接收钩子以禁止更改。你也可以修改git-upload-pack命令，以在某些文件被锁定时触发警告，或者在pull请求或repo更新时触发警告，如果你愿意，但我不对此进行评论，因为这会使git更新/升级变得困难。作为背景，在我们的项目中，导入/导出功能会在导出时生成XML，当有多个人推送XML时，手动合并XML会变得非常困难，因为每次导出时XML的结构都会发生变化。因此，即使两个XML在技术上是相同的，但从文件和git的Angular 来看，它们总是非常不同的文件，因此，我们使用聊天组进行协调，以便在其他人已经在处理某个XML时停止处理该XML，这里使用git-pull上载包，现在我们在团队中进行协调，只是为了发出警报，有时不这样做，而是通过我的脚本来处理锁，所以即使有人没有收到警报，仍然可以放心地工作。
tp5buhyn8#
这个用例也是Git比SVN --〉rebase好很多的原因之一！如果你遵循好的Git工作流程，你可以在提交Pull Request之前从上游进行rebase。你不需要担心文件锁定、践踏他人的提交和合并冲突等问题... rebase会把你的工作放在一边，应用远程提交，然后在上面应用你的工作。
我认为这需要你重新考虑一下你的开发过程，并依靠git的优势，而不是在git之上强行安装Subversion工作流.你的“fork-clone”模型可能也需要重新审视.通常每个开发者都有自己的fork，如果你愿意，你可以通过remote在团队之间共享repos.但是共享相同来源的贡献者会养成一些坏习惯.
Gitflow是一个非常流行的git工作流，而Github themselves has some nice tips and shares their workflow。