混合角色小团队的 DVCS 策略？

发布于 2024-11-16 15:18:09 字数 1500 浏览 1 评论 0原文

我读了很多书，并一直在尝试 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问题揭示了似乎相当一致的方法 - 主干（主干中没有垃圾！），团队拥有自己的分支，并拥有发布分支等。

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

...和一般的谷歌一样，我最终仍然会问自己同样的问题：

为“麻烦点”（复制团队）创建特定于角色的分支（他们可以在其中推送到存储库）是一个坏主意吗？然后我们的开发人员将合并他们的工作进入实际的项目分支吗？
我是否还应该尝试为其他人强制执行每个分支的任务？
我是否应该为每个人执行每个分支的任务，但让文案团队创建非常广泛的任务？
通常是否有一个团队/组/人员被视为执行关键合并的存储库的“管理员”角色？
（是否有另一种建议的工作流程，其中文案编写者不接触源代码？）

不幸的是，文案团队在更新文件方面发挥着至关重要的作用，而这些文件反过来又会在开发过程中不断影响布局和各种事物。我不可能将它们保留在泡沫中，直到项目结束，然后将他们的工作投入其中。...

好消息是，希望在几年后，我准备好迫使每个人转向版本控制！我们还选择了 PlasticSCM，因为它具有直观的 GUI 和 Windows 集成。

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

干杯！

原文

I've done a lot of reading, and have been trialing GIT, GIT Tortoise, Tortoise SVN and PlasticSCM, to find the right source control for our small team (5-10 users).

Some background on our team: 6 copy writers/editors (2 remote), 2 developers, 2 graphic designers. We are not always working on projects together, sometimes up to 5 of us might be working on a given project. I'm unconcerned about the developers with DVCS, my concern is mainly around the other roles who are (in the nicest way) limited in their technical capability. Some of our copy writers update multiple source files (HTML, PDFs and adding concept graphics) to live, unversioned build directories (backed up as build.23.06.11.new.new.final.zip!). The copy and GD team will not have time, or to be brutally honest, the inclination to merge/resolve conflicts, or probably even remember to switch branches.

A few SO questions have shed light on what what seems to be a fairly consistent approach - main trunk (no junk in the trunk!) with teams having their own branches, and having release branches etc.

Every time I've re-read the links...

...and google in general, I still end up asking myself the same questions:

Is it a Bad Idea to create role-specific branches for "trouble points" (copy team), where they can push to the repo, then our developers will merge their work into the actual project branch?
Should I still try to enforce a task-per-branch for everyone else?
Should I do task-per-branch for everyone but let the copy team create very broad tasks?
Is there usually a team/group/person who is considered an "admin" role for a repo who does crucial merges?
(is there an alternative suggested workflow where copy writers don't touch source?)

Unfortunately, the copy teams play a vital role in updating files which in turn affect layouts and all sorts of things, on a continual basis during dev. Its not like I can keep them in a bubble until the end of a project and chuck their work in.

... the good news is that hopefully, after a number of years, I'm ready to force everyone to move to version control! We've also settled on PlasticSCM for its intuitive GUI and Windows integration.

The best answer to this question would try to answer the 4 points above - tackle point 5 if you like - explain weak points if possible, and provide advice, gotchyas, etc.

cheers!

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

抠脚大汉 2024-11-23 15:18:09

基本上，您想知道如何让不同技能水平的团队成员使用 SCM 并彼此融洽相处。

团队的支持是第一要务。如果您不能让他们学习，那么您只能提供一条阻力最小的路径。所以你真的需要保持灵活性。使用该工具可能有错误的方式和正确的方式，但如果用户不接受正确的方式 ，那么错误的方式比他们根本不使用它要好。每个团队如何实现这种平衡都会有所不同。

<块引用>
为“问题点”（复制团队）创建特定于角色的分支，他们可以推送到存储库，然后我们的开发人员将他们的工作合并到实际的项目分支中，这是一个坏主意吗？

不，也许这不是最佳选择，但如果这对文案团队来说很容易，那么这就是你剩下的。您可能可以更进一步，为每个用户设置自己的分支。然后他们就不必担心合并其他人的更改。

<块引用>
我是否仍然应该尝试为其他人强制执行每个分支的任务？

每个开发人员都应该有一个唯一的“本地”分支，该分支不跟踪上游分支。例如，使用诸如 mydev 之类的通用内容。这使他们可以轻松地在本地代码和当前上游分支之间切换。

你不一定需要强迫每个人为每项任务创建一个本地分支，因为最后，你会希望他们只是将他们的工作分支重新定位到上游分支，然后提交，这样它就变成了一个快速的分支。向前（即线性提交）。

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

<块引用>
我应该为每个人执行每个分支的任务，但让文案团队创建非常广泛的任务吗？

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

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

<块引用>
通常是否有一个团队/组/人员被视为负责进行关键合并的存储库的“管理员”角色？

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

<块引用>
（是否有替代的建议工作流程，其中文案撰写者不接触源代码？）

好吧，一种可能的技术是集成管理器模型。开发人员将更改提交到他们自己的共享存储库，但要由集成经理将更改合并到blessed存储库中。

我确信还有其他方法可能适合您的用户，但这个问题有点含糊。

So basically you want to know how to get team-member of different skill-levels to use SCM and play nice with each other.

Buy-in from your team is priority #1. If you can't make them learn it, then you're left with providing a path of least resistance. So you really need to be flexible. There might be a wrong-way and a right-way to use the tool, but if the users won't accept the right-way, then the wrong-way is better than them not using it at all. How you achieve this balance is going to be different for every team.

Is it a Bad Idea to create role-specific branches for "trouble points" (copy team), where they can push to the repo, then our developers will merge their work into the actual project branch?

No, maybe its not optimal, but if this makes it easy for the Copy Team, then thats what you're left with. You could probably go even further and setup each user with their own branch. Then they never have to worry about merging other peoples changes.

Should I still try to enforce a task-per-branch for everyone else?

Each dev should have a unique "local" branch, that is not tracking an upstream branch. For example, use something generic like mydev. This makes it easy for them to switch between their local code and the current upstream branch.

You don't necessarily need to force everyone to create a local branch for every task, cause in the end, you're going to want them just to rebase their working branch onto the upstream one, and commit so it just becomes a fast-forward (i.e. linear commit).

Now for tasks that multiple devs are working on, or it is a feature that involves groups of smaller commits, then yes it does make sense to force them to create a new specific task branch. When they merge they can make sure to force a merge-commit, then it is clear that a set of commits are grouped together and all were part of a specific task. The merge commit will display like merged branch feature-X.

Should I do task-per-branch for everyone but let the copy team create very broad tasks?

It's really up to how much buy-in you can get from the Copy Team. I think if they really get confused with the DVCS tools, then you have to scale back until you can find something that does not cause too much of an impact.

One solution, is to have one of your devs help integrate the Copy Teams changes into another branch that everyone else will look at. That will help offload the learning-curve of the tool onto someone outside of the Copy Team.

Is there usually a team/group/person who is considered an "admin" role for a repo who does crucial merges?

Yes, this makes sense. However the great thing about SCM, is that everyone will be able to go back and do a code review on a merge. So if a merge breaks the code, you can either append the corrections after the merge, or remove the merge, and do it over.

(is there an alternative suggested workflow where copy writers don't touch source?)

Well, one possible technique is the Integration Manager model. The developers commit changes to their own share repos, but its up to the integration manger, to merge in the changes to the blessed repository.

I'm sure there are other methods that might work for your users, but this question is slightly ambiguous.

回复收藏 0 原文

~没有更多了~