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.