版本控制-适用于混合角色小团队的DVCS策略



我读了很多书,一直在试用GIT、GIT Tortoise、Tortoise SVN和PlasticSCM,为我们的小团队(5-10个用户)找到合适的源代码管理。

我们团队的一些背景:6名文案/编辑(2名远程),2名开发人员,2名平面设计师。我们并不总是一起做项目,有时我们中可能有5个人在做一个特定的项目。我不关心DVCS的开发人员,我关心的主要是其他角色,他们(以最好的方式)的技术能力有限。我们的一些复制作者将多个源文件(HTML、PDF和添加概念图)更新为实时的、未转换的构建目录(备份为build.23.06.11.new.new.final.zip!)。复制和GD团队将没有时间,或者说实话,没有合并/解决冲突的倾向,甚至可能记得切换分支。

一些SO问题揭示了什么似乎是一种相当一致的方法——主干道(主干道中没有垃圾!),团队有自己的分支,并有发布分支等。

每次我重读链接。。。

  • https://stackoverflow.com/questions/3854583/version-control-system-for-small-in-house-team
  • 版本控制入门
  • http://svn-ref.assembla.com/subversion-how-tos.html

和谷歌,我最终仍然会问自己同样的问题:

  1. 为"麻烦点"(复制团队)创建特定于角色的分支,在那里他们可以推送到回购,然后我们的开发人员将他们的工作合并到实际的项目分支中,这是一个坏主意吗
  2. 我还应该尝试为其他所有人强制执行每个分支的任务吗
  3. 我是否应该为每个执行每个分支的任务,但让复制团队创建非常广泛的任务
  4. 是否通常有一个团队/小组/人员被视为回购的"管理员"角色,负责进行关键的合并
  5. (是否有其他建议的工作流程,即复制作者不接触来源?)

不幸的是,在开发过程中,复制团队在更新文件方面发挥着至关重要的作用,而这些文件反过来又会影响布局和各种事情。我不能把它们放在一个泡泡里,直到项目结束,然后把它们的工作扔进去。

好消息是,希望在几年后,我已经准备好迫使每个人都转向版本控制!我们还选择了PlasticSCM,以实现其直观的GUI和Windows集成。

这个问题的最佳答案是尝试回答上面的4点-如果你愿意,解决第5点-如果可能,解释弱点,并提供建议、gotchyas等。

欢呼!

所以基本上你想知道如何让不同技能水平的团队成员使用SCM,并与彼此友好相处。

获得团队的支持是首要任务。如果你不能他们学习,那么你只能提供一条阻力最小的道路。所以你真的需要灵活。使用该工具可能有错误的方式正确的方式,但如果用户不接受的正确方式,那么错的方式比他们根本不使用要好。对于每支球队来说,你如何实现这种平衡将是不同的。

为"麻烦点"(复制团队)创建特定于角色的分支,在那里他们可以推送到回购,然后我们的开发人员将他们的工作合并到实际的项目分支中,这是一个坏主意吗?

不,也许这不是最佳的,但如果这对复制团队来说很容易,那么这就是你剩下的。您可能会更进一步,为每个用户设置自己的分支。然后,他们就再也不用担心融合其他民族的变化了。

我还应该尝试为其他所有人强制执行每个分支的任务吗?

每个dev都应该有一个唯一的"本地"分支,不跟踪上游分支。例如,使用类似mydev的泛型。这使得他们可以很容易地在本地代码和当前上游分支之间切换。

你不一定需要强迫每个人为每个任务创建一个本地分支,因为最终,你只希望他们将工作分支重新设置为上游分支,并进行提交,这样它就变成了一个快进(即线性提交)。

现在,对于多个开发人员正在处理的任务,或者这是一个涉及较小提交组的功能,那么强制他们创建一个新的特定任务分支是有意义的。当他们合并时,他们可以确保强制合并提交,然后很明显,一组提交被分组在一起,并且都是特定任务的一部分。合并提交将显示为类似merged branch feature-X

我应该为每个人执行每个分支的任务,但让复制团队创建非常广泛的任务吗?

这实际上取决于你能从复制团队获得多少支持。我认为,如果他们真的与DVCS工具混淆了,那么你必须缩小规模,直到你能找到不会造成太大影响的东西。

一个解决方案是让你的一个开发人员帮助将复制团队的更改集成到其他人都会关注的另一个分支中。这将有助于将工具的学习曲线转移到复制团队之外的人身上。

是否通常有一个团队/小组/人员被视为回购的"管理员"角色,负责进行关键的合并?

是的,这很有道理。然而,SCM的伟大之处在于,每个人都可以返回并对合并进行代码审查。因此,如果合并破坏了代码,您可以在合并后附加更正,也可以删除合并,然后重新执行。

(是否有一种替代建议的工作流程,即复制作者不接触来源?)

一种可能的技术是Integration Manager模型。开发人员将更改提交给他们自己的共享仓库,但这取决于集成经理,将更改合并到幸运的存储库中。

我相信还有其他方法可能适用于您的用户,但这个问题有点模棱两可。

最新更新