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).
+5
A:
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.
Greg Hewgill
2010-04-29 20:16:26
I see your point on integration, but what if you are using something like Hudson or Cruise Control?
Zombies
2010-04-29 20:23:21
@Zombies: Continuous integration systems help find integration problems sooner, but only if you actually *do* the integration sooner. If two developers are working on separate branches of the same project, a CI tool won't try to combine that work for you. Indeed it can't, if there are merge conflicts.
Greg Hewgill
2010-04-29 20:24:57
I would like to add that a nightly builds system will address any compilation issues that may come up due to different engineers working on same code. It will also help in release process too, knowing that a branch atleast compiles as of last night.
omermuhammed
2010-04-29 20:25:41
@Greg Hewgill: Can you elaborate one what needs to be communicated between the developers?
Zombies
2010-04-29 20:43:09
@Zombies: developers need to talk to each other so they don't end up (a) doing the same work twice, (b) doing work that is incompatible with each other, or (c) unnecessarily waiting on each other when they don't collectively understand the project priorities.
Greg Hewgill
2010-04-29 20:53:35
+2
A:
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.
Soviut
2010-04-29 20:21:51
A:
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 :)
Mike Yam
2010-04-29 20:34:25
I think it's misleading to say that "branching isn't even a concept in Git" when there are important commands such as [`git branch`](http://www.kernel.org/pub/software/scm/git/docs/git-branch.html).
Greg Hewgill
2010-04-29 20:59:40
Sorry for the late response. Yes, Git supports branching, but not in the traditional sense. Please read Joel On Software about the non-concept of branching: http://www.joelonsoftware.com/items/2010/03/17.html. Also, google "Git from the Bottom Up".In the abstract, it's all well and good to discuss branches, updates, modifies and commits, but real version control software will influence, in both subtle and gross ways, how you organize your code and how you organize your team. I am using Perforce now... blech.
Mike Yam
2010-05-16 15:24:51
A:
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).
Sherwin James
2010-04-30 17:10:45