并行开发：开发人员应该在同一分支内工作吗？
多个开发人员是否应该在同一个分支中工作并更新-修改-提交？或者每个开发人员都应该拥有自己的专属分支吗？共享分支将如何影响您进行日常维护而不是未维护的代码流的环境？另外，如果您在完成并通过测试后立即部署每个开发人员的工作（快速，而不是将他们的所有工作放入一个版本中），那么这将如何工作。
Should multiple developers work within the same branch, and update - modify - commit ? Or should each developer have his/her own each branch exclusively? And how would sharing branches impact an environment where you are doing routine maintenance as opposed to unmaintained code streams? Also, how would this work if you deploy each developers work as soon as it is done and passes testing (rapidly, as opposed to putting all of their work into a single release).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一般来说，我发现让开发人员（从事同一个项目）使用同一个分支可以更好地更快地发现集成问题。如果开发人员每个人都使用单独的分支，那么您只是将可能的集成问题推迟到稍后合并分支时。
当然，让开发人员在同一个分支上工作意味着您需要在这些开发人员之间进行实际的沟通，但这是一个社会问题而不是技术问题。
当该分支首先存在的充分理由（例如软件先前版本的补丁版本，或针对特定客户的特殊构建）时，开发人员将在单独的分支上工作。
请注意，Git 和 Mercurial 等工具允许开发人员轻松创建自己的私有分支来组织自己的工作。这与多个开发人员共享一个分支机构的情况不同，并且（通常是短期的）私人分支机构应该受到鼓励。
In general, I have found that having developers (who are working on the same project) use the same branch is better for finding integration problems sooner. If developers are each using an individual branch, then you're just delaying possible integration problems until later, when you merge the branches.
Of course, having developers work on the same branch means you need to have actual communication between those developers, but that's a social problem and not a technical one.
Developers would work on separate branches when there is a good reason for that branch to exist in the first place (such as a patch release of a previous version of the software, or a special build for a specific customer).
Note that tools such as Git and Mercurial allow developers to easily create their own private branches to organise their own work. This is a different situation from more than one developer sharing a branch, and (usually short-lived) private branches should be encouraged.
分支是对可能破坏主线/主干的任何功能或实验代码进行版本控制的一种方式。
虽然开发人员通常拥有自己的个人分支来进行深入实验，但分支通常以添加的新功能为中心。这些新功能通常需要多个人参与。
例如，在一个网络项目中，两名开发人员和一名设计师可能正在对其公司网站进行改版。他们仍然需要保持主线/主干代码干净，以防在整容完成之前需要对其进行快速更改。因此，他们创建了一个“整容”分支并致力于此。当开发人员提交 JavaScript 时，设计人员可以提交 CSS 和图像。一旦改版功能完成，他们就可以将其合并到主线中并实时发送。
他们中的任何一个人需要个人分支机构的唯一原因是为了进行实验。例如，设计者可能正在尝试实现“滑动门”选项卡，但无法在 IE6 中获得正确的填充。如果他解决了问题，他可以将其合并到整容分支中，如果不能，他只需忽略它并继续将设计的其余部分返回整容分支。
Branches are meant as a way to version control any feature or experimental piece of code that may break the mainline/trunk.
While it is common for developers to have their own personal branches for deep experimentation, often branches center around a new feature being added. These new features often require more than one person to be committing.
For example, on a web project, two developers and a designer may be doing a facelift to their company website. They still need to keep their mainline/trunk code clean in case they need to make a quick change to it before the facelift is complete. So they create a "facelift" branch and work on that instead. While the developers are committing javascript, the designer can be committing CSS and images. Once the facelift feature is complete, they can merge it into the mainline and send it live.
The only reason any of them would need personal branches would be for experimenting. Perhaps the designer is trying to implement "sliding door" tabs and can't get the padding right in IE6, for example. If he solves the problem, he can merge it into the facelift branch, if he can't, he simply ignores it and continues with the rest of the design back in the facelift branch.
在某种程度上，您正在使用的版本控制软件会促使您采用特定的方法。 GIT 面向开源贡献者，类似于“一个开发人员”模型（分支在 GIT 中甚至不是一个概念。GIT 更多的是关于管理变更）。 Clearcase 更具企业性，因此一个分支上确实有多个开发人员，但每个开发人员都可以按照自己的观点进行操作。
我同意格雷格的回答，这更多的是一个社会规划问题。一个分支上的许多开发人员会互相踩对方的脚趾。我参与过一个项目，其中开发人员的数量多于单个源文件的数量:)
To some extent, the version control software you are using will nudge you into a particular approach. GIT is geared toward open-source contributors and resembles the "one developer" model (branching isn't even a concept in GIT. GIT is more about managing changes). Clearcase is more corporate, so you do have multiple developers on a branch, but each developer gets to play in his or her own view.
I agree with Greg's answer, this is more a social planning issue. Lots of devs on one branch will step on each other's toes. I've been on a project where there were more developers than individual source files :)
我认为，无论源代码控制工具有多好，分支的合并可能会出现问题（功能被删除或不一致）。我更愿意选择多个开发人员在一个主分支上工作。可能还有其他分支用于诸如生产错误修复或概念验证（POC）之类的事情，其中合并可以/应该在更改（错误修复）后很快发生，或者很有可能不需要发生合并（POC）。
I think that merging of branches can be problematic (dropped or inconsistent functionality), regardless of how good the source control tools are. I would more readily opt for multiple developers working on a single main branch. There could be other branches for things like production bug fixes or proof-of-concepts (POCs), where merging could/should happen very soon after change (bug fixes) or good chance that merging may not need to happen (POCs).