一年半以来,我一直关注着git社区,希望能够远离SVN.阻碍我的一个特殊问题是无法锁定二进制文件.在过去的一年里,我还没有看到这个问题的发展.我知道锁定文件违反了分布式源代码控制的基本原则,但我没有看到Web开发公司如何在有可能发生二进制文件冲突时利用git跟踪源代码和映像文件更改.
为了实现锁定的效果,必须识别"中央"存储库.无论git的分布式特性如何,大多数公司都将拥有一个软件项目的"中央"存储库.我们应该能够将文件标记为需要从指定地址的管理git存储库进行锁定.也许这很难,因为git跟踪文件内容而不是文件？
你们有没有经验处理应该在修改前锁定的git和二进制文件？
注意:看起来Source Gear的新开源分布式版本控制项目Veracity已将锁定作为其目标之一.
Subversion有锁,它们不仅仅是建议性的.可以使用svn:needs-lock属性强制执行(但如果需要,也可以故意破坏).这是管理不可合并文件的正确解决方案.我在商店中为Subversion工作,并使用svn:needs-lock所有不可合并的文件.
我不同意"锁只是一种沟通方法".它们比推送通知(如电话或电子邮件)更有效.Subversion锁是自我记录的(谁拥有锁).另一方面,如果您必须通过其他传统的推送通知渠道(例如电子邮件)进行通信,您是否将通知发送给谁？您事先并不知道谁可能想要编辑该文件,尤其是在开源项目上,除非您拥有整个开发团队的完整列表.所以那些传统的传播方法并不那么有效.
中央锁服务器虽然违反了DVCS的原则,但却是不可合并文件的唯一可行方法.只要DVCS没有中央锁定功能,我认为这将使我在公司工作使用Subversion.
更好的解决方案是为所有二进制文件格式创建合并工具,但这是一个永远不会"完成"的长期和持续目标.
这是关于这个主题的有趣读物.
我同意锁定二进制文件是某些环境的必要功能.我只是想过如何实现这个,但是:
有办法将文件标记为"需要锁定"(如"svn:needs-lock"属性).
在结账时,git会将此类文件标记为只读.
新命令git-lock将联系运行某处的中央锁服务器以请求锁定权限.
如果锁定服务器授予权限,请将文件标记为读写.
git-add 将通知锁服务器锁定文件的内容哈希.
锁服务器将监视该内容哈希出现在主存储库的提交中.
当哈希出现时,释放锁.
这是一个非常半生不熟的想法,到处都有潜在的漏洞.它也违背了git的精神,但它在某些情况下肯定是有用的.
在特定的组织中,这种事情也许可以使用脚本包装器和提交钩子的适当组合来构建.
回应马里奥对二进制文件中多个地方发生的变化的额外关注.所以场景是Alice和Bob都在同时对同一个二进制资源进行更改.他们每个人都有自己的本地仓库,从一个中央遥控器克隆.
这确实是一个潜在的问题.所以爱丽丝先完成并推到中央alice/update分支.通常情况下,如果发生这种情况,Alice会发布一条通知应该进行审核.鲍勃看到并审查它.他可以(1)将这些变化自己纳入他的版本(从中alice/update进行分支并对其进行更改)或者(2)将自己的更改发布到bob/update.他再次宣布了这一消息.
现在,如果爱丽丝推动master,鲍勃在拉动master并尝试合并到他的本地分支时会陷入两难境地.他与爱丽丝的冲突.但同样,相同的程序可以适用于不同的分支机构.即使Bob忽略了Alice的所有警告和提交,也总是可以撤出Alice的修复提议.这只是一个沟通问题.
由于(AFAIK)Subversion锁只是建议性的,因此电子邮件或即时消息可以用于相同的目的.但即使你不这样做,Git也可以让你修复它.
不,本身没有锁定机制.但是锁定机制往往只是良好沟通的替代品.我相信这就是为什么Git开发人员没有添加锁定机制.
我们刚刚开始使用Git(之前使用过Subversion),我发现工作流程的更改可能有助于解决您的问题,而无需锁定.它利用了git的设计方式以及分支的简单性.
基本上,它归结为推送到非主分支,审查该分支,然后合并到主分支(或目标分支中的任何一个).
git是"有意"使用的方式,每个开发人员都会发布他们自己的公共存储库,并请求其他人从中提取.我发现Subversion用户遇到了麻烦.因此,我们推动在中央存储库中分支树,每个用户都有自己的分支树.例如,像这样的层次结构可能有效:
users/a/feature1 users/a/feature2 users/b/feature3 teams/d/featurey
随意使用自己的结构.注意我也在展示主题分支,另一种常见的git习语.
然后在用户的本地回购中:
feature1 feature2
并将它到中央服务器(原点):
git push origin feature1:users/a/feature1
(这可以通过配置更改来简化)
无论如何,一旦feature1被审查,谁负责(在我们的例子中,它是该功能的开发者,你可以让一个用户负责合并到master),执行以下操作:
git checkout master git pull git merge users/name/feature1 git push
pull执行获取(将任何新的主更改和功能分支拉出)和更新主数据到中央存储库具有的内容.如果用户a完成了他们的工作并正确跟踪了master,那么合并应该没有问题.
所有这些意味着,即使用户或远程团队对二进制资源进行了更改,也会在将其合并到主分支之前进行审核.关于什么时候进入主分支,有一个明确的描述(基于过程).
您也可以使用git hooks以编程方式强制执行此方面,但同样,我还没有使用过这些,所以不能谈论它们.
当我使用Subversion时,我虔诚地svn:needs-lock在所有二进制文件甚至难以编辑的文本文件上设置属性.我从未真正经历过任何冲突.
现在,在Git中,我并不担心这些事情.记住:Subversion中的锁实际上不是强制锁,它们只是通信工具.并猜测:我不需要Subversion进行通信,我可以通过电子邮件,电话和IM进行管理.
我做的另一件事是用纯文本格式替换许多二进制格式.我用新结构化或LaΤ Ε Χ而不是字,而是CSV的Excel,ASCII艺术,而不是Visio中,YAML而不是数据库,SVG的,而不是面向对象的绘制,ABC,而不是MIDI,等等.
Git LFS 2.0增加了对文件锁定的支持.
使用Git LFS 2.0.0,您现在可以锁定正在处理的文件,防止其他人推送到Git LFS服务器,直到您再次解锁文件.
这将防止合并冲突以及文件系统级别的不可合并文件的丢失工作.虽然它似乎与Git的分布式和并行性相矛盾,但文件锁定是许多软件开发工作流程的重要组成部分 - 特别是对于使用二进制资产的大型团队而言.
值得检查当前的工作流程,看看是否真的需要锁定图像.两个人独立编辑图像是相对不寻常的,一点点沟通可以走很长的路.
京公网安备 11010802040832号 | 京ICP备19059560号-6 