git workflow: everyone has a branch, or everyone has a master?

Question

When working with multiple people with git, is it better

1. for everyone to just work in master, and merge between each other's masters, or
2. for everyone to work in their own titled branch?

As I see it, in the case of (1), although each master acts as a branch, everyone is expected to merge between each other's work with a mostly linear flow, whereas in (2), everyone is expected to merge a common master into their branch, and push changes from their branch into a common master when they are ready.

Can someone with experience working on medium- to large-sized teams with git make any comments? What works best for your team? I guess a third option is to always use feature branches instead of people branches, although I see this as being basically the same situation as (2) from this question's point of view.

I imagine that in both (1) and (2), a single person is responsible for pulling changes to the "official" master. How would this carry over if more than one person as push access to the official master?

Answer 1

Branch names in git are local to a repository. push and pull can be configured to match identical names on a remote repository, but that's optional behavior. If you have a central repository, you want master there to be definitive. What individual developers call their working branches on their local repositories is really a matter of taste. Some will have their local master be their working branch, and others will use a single named dev branch.

If your devs are up to it, the really savvy way is to use feature or topic branches, so that rather than having a "Mike's work" branch you have a "work on autofrotzification feature" branch that can be pushed and exchanged sanely without everyone needing to do a ton of early merging back and forth.

Answer 2

DVCS introduces the publication as an othogonal dimension to branching.

That means branches in a DVCS have two roles:

1. the classic one: code isolation: you isolate the history (list of revisions) of a code in a branch
2. the new one: publication: you repicate your commits from repos to repos.

Git allows for "private commits", ie you commit as much as you want (and then you can clean your history of commits).
If you do that in master, this is not good for publication: since master is the branch visible by default when a repo is cloned, anyone cloning your repo won't get a stable state, but a snapshot of a work in progress.

Private commits means: commit in branches that aren't published.
You can call those whatever you want.

Any branch which is to be pushed/pulled should never be called after a resource name (like 'VonC_branch'), but always after a feature or a more general release management topic (like 'public', 'next', 'patchV1', ...)

The difference between the private branches and the public ones is the history of commits you allow in each one:

• as many commits you want in a private branch (you need just to assign the right comment to facilitate a future re-ordering through rebase --interactive with !fixup and !squash actions)
• "consistent" commits in public branches (each commit is complete, represent a stable state that at least compile and can be tested, even if those test fail)
  A master branch for instance would have even stricter standard than that (like "the tests must pass)

So to decide on how you will use branches with Git, you need to take into account the publication aspect.

Answer 3

For a medium to large size team, you most likely want to have centralized repository, with the "official" master branch.

The other popular option would be to have an integrator, who is basically an intermediary between the developers and the central repo. How you decide upon this is reliant on what your team decides is the most appropriate method. There is a good write-up on the differences in the Pro Git book.

Going with a shared repo, it comes down to the developers personal preference (and some team agreement) whether to commit directly to their local master, or use a separate dev branch. My thought is that keeping local changes in a dev branch is a better option, but slightly more cumbersome for developers who are used to centralized SCM.

The benefit of the separate dev branch is that makes it easier to track new commits in the code base by just running git pull on master. The clean master lets the devs always check out the latest public code if necessary. If you pull with changes in master, it will merge in the origin/master branch onto your unpublished commits. This will create a new merge commit in the master and will be visible if the changes ever get pushed back to master. Maybe this is what you want, but it can make the commit history somewhat messing looking.

With a dev branch you can easily rebase against the master to keep the commit history linear. Without a dev branch, a git pull --rebase in master will have the same effect, but it is easy to forget this step.

Basically, using a private tracking branch (like dev) gives a developer a little more flexibility on how she accepts public changes into her local branches. It also makes it easier to keep the centralized repo free of excessive merge commits. The only downside is that it requires some additional effort from the developers, but in the long-term will enhance the ultimate utilization of git.