我最近开始在个人项目上进入Git,我可以看到DVCS如何让我们在工作中受益(这是一家大型企业软件公司,目前正在运行Perforce).我的团队中的功能工作主要包括开发人员创建自己的分支; 有时这些是由小型开发团队共享的.我认为在这种情况下使用DVCS会更有效率.
然而,在更一般的情况下,我有兴趣听到在工作中使用DVCS的人,大中型团队.
你如何处理N路合并？这甚至是一种常见的情况吗？Mercurial仅通过执行(N-1)2路合并(并且读取这是其他DVCS中的首选解决方案)来支持N路合并,这对于相对较小的N来说听起来是非常费力的过程.
您是使用单一的中央权威存储库,还是真正的P2P？
开发人员经常会相互推送和拉取代码,还是通过中央存储库完成所有工作？
Ben Collins.. 13
我以前雇主的团队使用Git,它对我们很有用.我们不是那么大(可能是16个左右,可能有8个真正活跃的提交者？),但我对你的问题有答案:
N路合并并不常见.我们提出了一些关于分支命名的约定,这些约定允许我们编写简化"发布工程"过程的脚本(我使用恐慌报价,因为我们没有发布工程师),人们会创建私有功能分支,但我们很少合并两个以上的分支有问题(见下一个).
(和#3).我们在开发服务器上有一个中央存储库有三个原因:(a)开发机器有RAID5(更容错)和夜间备份(开发工作站不是每晚),(b)生产版本是在开发服务器上构建的, (c)使中央存储库简化脚本.结果,N路合并根本就没发生过.我们对N-way最接近的是当有人横向合并然后垂直合并时.
Git对我们来说是一件非常棒的事情,因为它具有高度的灵活性; 但是,我们确实必须建立一些约定(分支和标记名称,repo位置,脚本等,进程)或者它可能有点混乱.一旦我们设置了惯例,我们的灵活性就非常棒.
更新:我们的惯例基本上是这样的:
我们的NFS服务器上的一个目录,它包含所有中央存储库
我们有几个共享组件的项目,因此我们将它们分解为库,基本上是使用自己的存储库,可交付项目将它们作为git子模块包含在内.
我们从上面强加了版本字符串和版本名称,所以我们只使用了那些作为分支名称的变体
同样,对于标签,它们遵循过程指定的版本名称
可交付项目包含一个属性文件,我将其读入shell脚本,这使我能够编写一个脚本来管理所有项目的发布过程,即使每个项目在过程中都有轻微的变化 - 这些变化都被考虑在内在那些属性文件中
我编写了可以从任何标签重建可交付包的脚本
使用git允许我们使用PAM和/或普通用户权限(ssh等)控制访问
还有其他一些公约更难以列入项目符号列表,例如合并时应该发生.真的,我和另一个人是内部的"git guru",我们帮助每个人弄清楚如何使用分支以及何时合并.
让人们以小块的形式提交而不是在主分支中丢弃差异炸弹是一个挑战.一个人将大约两个星期的工作投入到一次提交中,我们最终不得不解开它.一个巨大的浪费时间,和令人沮丧的一切.
提交信息和详细的评论
当您的团队经验丰富并学会彼此合作时,您还会学到其他一些东西,但这足以让我们开始.
更新:任何关注这些事情的人现在都已经知道了,但是Vincent Dreissen已经使用Git写了一篇关于分支和发布工程的可靠而且非常全面(但不是激进)的文章.我强烈建议将他的过程作为起点,因为有两个原因:
很多团队都是这样做的,或者正在使用一些密切的变体(包括Linux,Git和许多其他OSS项目团队),这意味着这种方法已经过测试和调整,在大多数情况下都是成功的.您不太可能面临在此模型的约束下未遇到并解决的问题.
由于上述原因,几乎所有具有Git经验的工程师都会理解正在发生的事情.您不必撰写有关发布过程基本性质的详细文档; 您只需要记录仅针对您的项目或团队的内容.
没有......分支修复了Git中的差异炸弹问题.这家伙做的是做了两个星期没有做任何事情.然后他把所有东西都卷成了一个提交.Git非常灵活,但提交是原子单元.解决此问题的唯一方法是在不提交结果的情况下合并其提交,并有选择地分解合并提交的更改. (2认同)
Wim Coenen.. 7
来自whygitisbetterthanx的工作流程架构:
与集成经理http://whygitisbetterthanx.com/images/workflow-b.png一起使用alt git work-flow
要将此扩展到更多开发人员,您只需在集成管理器和开发人员之间添加另一层"可信赖的副官".
我以前雇主的团队使用Git,它对我们很有用.我们不是那么大(可能是16个左右,可能有8个真正活跃的提交者？),但我对你的问题有答案:
N路合并并不常见.我们提出了一些关于分支命名的约定,这些约定允许我们编写简化"发布工程"过程的脚本(我使用恐慌报价,因为我们没有发布工程师),人们会创建私有功能分支,但我们很少合并两个以上的分支有问题(见下一个).
(和#3).我们在开发服务器上有一个中央存储库有三个原因:(a)开发机器有RAID5(更容错)和夜间备份(开发工作站不是每晚),(b)生产版本是在开发服务器上构建的, (c)使中央存储库简化脚本.结果,N路合并根本就没发生过.我们对N-way最接近的是当有人横向合并然后垂直合并时.
Git对我们来说是一件非常棒的事情,因为它具有高度的灵活性; 但是,我们确实必须建立一些约定(分支和标记名称,repo位置,脚本等,进程)或者它可能有点混乱.一旦我们设置了惯例,我们的灵活性就非常棒.
更新:我们的惯例基本上是这样的:
我们的NFS服务器上的一个目录,它包含所有中央存储库
我们有几个共享组件的项目,因此我们将它们分解为库,基本上是使用自己的存储库,可交付项目将它们作为git子模块包含在内.
我们从上面强加了版本字符串和版本名称,所以我们只使用了那些作为分支名称的变体
同样,对于标签,它们遵循过程指定的版本名称
可交付项目包含一个属性文件,我将其读入shell脚本,这使我能够编写一个脚本来管理所有项目的发布过程,即使每个项目在过程中都有轻微的变化 - 这些变化都被考虑在内在那些属性文件中
我编写了可以从任何标签重建可交付包的脚本
使用git允许我们使用PAM和/或普通用户权限(ssh等)控制访问
还有其他一些公约更难以列入项目符号列表,例如合并时应该发生.真的,我和另一个人是内部的"git guru",我们帮助每个人弄清楚如何使用分支以及何时合并.
让人们以小块的形式提交而不是在主分支中丢弃差异炸弹是一个挑战.一个人将大约两个星期的工作投入到一次提交中,我们最终不得不解开它.一个巨大的浪费时间,和令人沮丧的一切.
提交信息和详细的评论
当您的团队经验丰富并学会彼此合作时,您还会学到其他一些东西,但这足以让我们开始.
更新:任何关注这些事情的人现在都已经知道了,但是Vincent Dreissen已经使用Git写了一篇关于分支和发布工程的可靠而且非常全面(但不是激进)的文章.我强烈建议将他的过程作为起点,因为有两个原因:
很多团队都是这样做的,或者正在使用一些密切的变体(包括Linux,Git和许多其他OSS项目团队),这意味着这种方法已经过测试和调整,在大多数情况下都是成功的.您不太可能面临在此模型的约束下未遇到并解决的问题.
由于上述原因,几乎所有具有Git经验的工程师都会理解正在发生的事情.您不必撰写有关发布过程基本性质的详细文档; 您只需要记录仅针对您的项目或团队的内容.
来自whygitisbetterthanx的工作流程架构:
与集成经理http://whygitisbetterthanx.com/images/workflow-b.png一起使用alt git work-flow
要将此扩展到更多开发人员,您只需在集成管理器和开发人员之间添加另一层"可信赖的副官".
我使用Darcs在Glasgow Haskell编译器团队工作了几年.我最近(几个月)开始使用git作为我自己的回购副本,无论是为了表现还是为了提高我的教育水平.
你如何处理N路合并？
没有N路合并.每个开发人员发起一个补丁流,并在每个回购中一次合并一个流.因此,如果N个开发人员同时进行更改,则会成对合并.
您是否使用单一的中央权威存储库？
绝对.这是告诉什么是GHC和什么不是GHC的唯一方法.
开发人员经常会相互推送和拉取代码,还是通过中央存储库完成所有工作？
我认为这取决于您使用的开发人员和VCS.在GHC项目中,我看到几乎所有的拉动和推动都通过中央存储库.但是有一个重量级(自我管理)看门人推送到中央回购,如果一个同事现在需要修复错误,我会直接从他或她的回购中提取.使用darcs很容易只拉一个补丁(而不是像git那样整个状态),而且我知道我的同伴deveopers,他们对darcs有更多的经验,比我更多地使用这个功能---他们非常喜欢它.
有了git,当我与一个其他开发人员紧密合作,我经常会创建一个新的分支,只是为了与另外一个人分享它的目的.那个分支永远不会打到中央回购.
京公网安备 11010802040832号 | 京ICP备19059560号-6 