gpt4 book ai didi

version-control - 混合角色小型团队的DVCS策略?

转载 作者:行者123 更新时间:2023-12-04 07:01:26 26 4
gpt4 key购买 nike

我已经读了很多书,并且一直在试用GIT,GIT Tortoise,Tortoise SVN和PlasticSCM,以找到适合我们的小型团队(5-10个用户)的源代码控制。

我们团队的背景知识:6名拷贝作者/编辑(2名远程人员),2名开发人员,2名图形设计师。我们并非总是一起进行项目,有时可能有多达五个人在进行给定项目。我对使用DVCS的开发人员并不担心,主要关注的是其他角色(以最好的方式)其技术能力受到限制。我们的一些拷贝编写者将多个源文件(HTML,PDF和添加概念图)更新为实时的,未版本控制的构建目录(备份为build.23.06.11.new.new.new.final.zip!)。复制和GD团队没有时间,或者说实话,没有合并/解决冲突的意愿,甚至可能还记得切换分支机构。

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

每次我重新阅读链接...


https://stackoverflow.com/questions/3854583/version-control-system-for-small-in-house-team
Getting started with Version Control
http://svn-ref.assembla.com/subversion-how-tos.html


...和一般的google一样,我仍然会问自己同样的问题:


为“麻烦点”(复制团队)创建特定于角色的分支是一个坏主意,在那里他们可以推送到仓库,然后我们的开发人员将其工作合并到实际的项目分支中?
我是否仍应尝试对其他所有人执行每个分支的任务?
我应该为每个人执行每个分支任务,但让复制团队创建非常广泛的任务吗?
通常是否有团队/小组/人员被视为执行关键合并的仓库的“管理员”角色?
(是否有替代的建议工作流程,其中撰稿人不接触源文件?)


不幸的是,复制团队在更新文件中起着至关重要的作用,而文件更新又会在开发期间持续影响布局和各种事物。我不希望我在项目结束前让他们陷入泡沫,然后放弃他们的工作。

……好消息是,希望几年后,我准备强迫所有人转向版本控制!我们还选择了PlasticSCM来实现直观的GUI和Windows集成。

这个问题的最佳答案将是尝试回答上述4点-如果您愿意,请解决5点-如果可能的话,解释弱点,并提供建议,解决方法等。

干杯!

最佳答案

因此,基本上,您想知道如何让不同技能水平的团队成员使用SCM并彼此打成一片。

从您的团队买入是第一要务。如果您不能让他们学习它,那么您将获得最小的阻力。因此,您确实需要保持灵活性。使用该工具可能会有错误的方法和正确的方法,但是如果用户不接受正确的方法,那么错误的方法总比根本不使用它要好。每个团队的平衡方式将有所不同。



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



不,也许不是最佳选择,但是如果这对复制团队来说很容易,那就是您所剩下的。您可能甚至可以更进一步,为每个用户设置自己的分支。这样,他们就不必担心合并其他人的更改。



我是否仍应尝试对其他所有人执行每个分支的任务?



每个开发人员应有一个唯一的“本地”分支,该分支不会跟踪上游分支。例如,使用诸如mydev之类的通用名称。这使他们很容易在本地代码和当前上游分支之间切换。

您不必强迫每个人都为每个任务创建一个本地分支,因为最终,您只希望他们只是将其工作分支重新建立到上游分支上,然后进行提交,这样就变得快速了。转发(即线性提交)。

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



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



这实际上取决于您可以从复制团队获得多少支持。我认为,如果他们真的对DVCS工具感到困惑,那么您就必须缩减规模,直到找到不会造成太大影响的东西为止。

一种解决方案是让您的一名开发人员将复制团队的更改集成到其他人可以查看的另一个分支中。这将有助于将工具的学习曲线转移到复制团队之外的人员身上。



通常是否有团队/小组/人员被视为执行关键合并的仓库的“管理员”角色?



是的,这很有道理。但是,关于SCM的伟大之处在于,每个人都可以返回并在合并时进行代码审查。因此,如果合并破坏了代码,则可以在合并之后追加更正,或者删除合并,然后重新进行合并。



(是否有替代的建议工作流程,其中撰稿人不接触源文件?)



嗯,一种可能的技术是Integration Manager模型。开发人员将更改提交给他们自己的共享存储库,但要由集成管理器来进行更改,以将更改合并到受祝福的存储库中。

我确定还有其他方法可能对您的用户有效,但是这个问题有点模棱两可。

关于version-control - 混合角色小型团队的DVCS策略?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/6447722/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com