我做了很多阅读,并一直在试用 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
...和一般的谷歌,我最终还是会问自己同样的问题:
- 为“问题点”(复制团队)创建特定于角色的分支是不是一个坏主意,他们可以在其中推送到 repo,然后我们的开发人员会将他们的工作合并到实际的项目分支中?
- 我是否仍应尝试为其他所有人强制执行每个分支的任务?
- 我应该为每个人都做每个分支的任务,但让副本团队创建非常广泛的任务吗?
- 通常是否有一个团队/组/人被认为是进行关键合并的仓库的“管理员”角色?
- (是否有其他建议的工作流程,文案作者不接触源代码?)
不幸的是,副本团队在更新文件方面发挥着至关重要的作用,这反过来又会在开发过程中持续影响布局和各种事情。它不像我可以让他们在一个项目结束之前保持泡沫,然后把他们的工作扔进去。
... 好消息是,希望在多年之后,我已经准备好迫使每个人都转向版本控制!我们还选择了 PlasticSCM,因为它具有直观的 GUI 和 Windows 集成。
这个问题的最佳答案是尝试回答上面的 4 点——如果你愿意,可以解决第 5 点——如果可能的话,解释弱点,并提供建议、问题等等。
干杯!