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

Question

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

Kar*_*k S 66 git github githooks github-api

我们是由60多名开发人员组成的团队,他们正在开发相同的产品,并且正在从SVN迁移到Git和GitHub.我们在SVN中有一个进程,在单个文件被锁定的情况下,每当开发人员想要提交代码时,他都需要由文件所有者解锁.我们三个人是150多个文件的拥有者.解锁之前是代码审查.

在Github中,我们计划使用Fork-Clone模型 - 每个项目正在开发的一组dev将执行fork,每个开发人员都会执行fork的克隆,编写代码并提交到origin,the lead of the功能将向上游执行拉取请求.

虽然这看起来很好,但问题是当一个大项目交付时,它会带来大量的更改以供审阅,从而增加了文件所有者的负担.此外,这可能发生在后期的开发周期中,因此项目可能会受到危害.

我们认为可能有用的一种方法是在git push完成原点(fork)时使用钩子.可以有一个最终评论git pull to upstream.

但是,我们找不到任何github扩展或推送挂钩.有没有一个快速的方法(阅读,现有的扩展)与Github这样做或我们应该使用我们将与git使用相同的钩子？

Answer 1

小智 85

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

这是正确的答案.不是在撰写本文时接受的那个.Upvoted.它甚至不必是用于锁定的二进制文件.以其他问题对iOS故事板发表评论为例. (7认同)
我们的一个用例是高度规范化的 XML 文件。例如我们有一个字符串表。如果有人修改文件中的字符串，则必须更改该表，并假设它是按字母顺序排列的，则其后的每个字符串引用都必须加一。总而言之，对文件中的差异进行了微小的更改，但却是一场合并噩梦。因此我们锁定。尽管如此，差异的存储是作为 UTF-8 文件差异完成的，与存储整个文件相比，差异相对较小。SVN 非常适合这种用例，非锁定系统会出现重大问题。 (2认同)

Answer 2

Nij*_*n22 23

如果您正在使用git LFS(某些git托管提供商支持,如GitHub),您可以使用文件锁定.

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

*.docx lockable
# Make MS Word files lockable

Run Code Online (Sandbox Code Playgroud)

锁定它:

$ git lfs lock example.docx

Run Code Online (Sandbox Code Playgroud)

您可以git lfs unlock example.docx通过添加来解锁您和其他人的文件--force.

Answer 3

小智 5

这个有可能。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/ 。

Answer 4

小智 -28

这个用例是 Git 比 SVN 好得多的原因之一 --> rebase！如果您遵循良好的 git 工作流程，您可以在提交 Pull 请求之前从上游进行 rebase。您无需担心文件锁定、踩踏他人的提交以及合并冲突等……变基会将您的工作放在一边，应用远程提交，然后在顶部应用您的工作。

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

Gitflow是一个非常流行的 git 工作流程，Github 本身也有一些不错的技巧并分享了他们的工作流程。

只要您有可合并文件，此操作就有效。如果您有二进制文件（如 Word 文档），您就会陷入困境。 (96认同)
投反对票是因为你没有提供解决方案，而是让人们相信他们不需要他们想做的事情，因为 Git 还有其他东西。如果您在其他人的更改之上重新调整您的更改，这是否意味着不会有任何冲突（即编辑相同的行）并且您肯定不会覆盖其他人的工作。我真的不这么认为 (51认同)
Git ins 并不比 svn 好多少，反之亦然。Git 非常适合使用非二进制文件的开发人员。在我们公司的二进制文件案例中，我们选择了 svn，因为它比 git 更好地处理大型二进制文件（20mb+，有 100 多个版本）（在我们测试的场景中）ps：我喜欢 git， (11认同)
我不同意这个答案，因为 rebase 并不是处理冲突的灵丹妙药，更糟糕的是！SVN 锁定的目的是警告人们有人正在对文件进行大量修改，除非有人欺骗工作副本或滥用强制窃取锁定。在 Git rebase 中，如果一个人将多个提交应用于其他人修改的同一文件，他将必须解决每个提交重播的冲突。在这种情况下，合并会更便宜，因为您解决了一次冲突，但这不是锁定的目的。当然，良好的项目管理和协调会有所帮助 (5认同)
@pan40你不能。句号 (3认同)
Git 在传统源代码管理认为理所当然的事情上表现得很糟糕，比如防止不可合并文件上的冲突。这就是为什么像 LFS 和 gitlab 这样的东西重新添加到这些基本功能中。这个答案不是解决方案。 (2认同)

归档时间：	12 年，9 月前
查看次数：	76280 次
最近记录：	6 年，4 月前