42

So, I'm fairly new to git and I've after a bit of reading around over the last couple of weeks I've read a few people saying that the master branch shouldn't be changed but rather branched from and then merged to.

I'm happy enough to work with branches but was wondering for the reasons behind not working on the master branch?

Mark Williams
  • 1,240
  • 2
  • 13
  • 28

5 Answers5

66

Other people have made very good cases for not making changes directly in master, and I agree with them. However, always advocating workflows like this sometimes leads people new to git to believe it is needlessly complex, so I wanted to provide a counterpoint.

If you have a one-person or very small team and your development is highly linear, i.e. you rarely work on more than one thing at a time and each feature is usually completed before starting the next, there really is little to no benefit to not work directly out of master. It is very easy to go back and add a branch at any point should the need arise. I highly recommend being aware of the feature branch workflow, but if you feel in your case it's just adding extra steps without buying you anything, I promise I won't tell the git police.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
  • 5
    It's not that often that I see two very different, but equally meritorious answers to a question here. This is such a case. Too bad SO doesn't allow the acceptance of multiple answers. – Dan Moulding Feb 04 '14 at 21:49
36

i guess the usual reasoning is, that the master branch should represent the 'stable' history of your code. use branches to experiment with new features, implement them, and when they have matured enough you can merge them back to master.

that way code in master will almost always build without problems, and can be mostly used directly for releases.

let's take git.git (the official git repository) as an example. there are several branches, most noticable:

so, master contains code which is very likely to end up in the next release of git. next contains tested code, which will potentially be merged into the master branch. pu (proposed updates, iirc) contains quite new (and probably) untested code.

pu is considered unstable and will be reset and rebased to junio's liking. next might get reset after a release or during a release cycle, but this is less common. master is set in stone and never changed after it's been pushed and made publicly available.

you see, that changes will get merged from pu to next and from next to master if they are deemed worthy and don't break stuff.

the branch maint is used to make bugfixes which should also apply to older versions of git. maint is usually merged to next and/or master.

you can inspect the branches on http://git.kernel.org/?p=git/git.git;a=summary

knittl
  • 246,190
  • 53
  • 318
  • 364
  • Thanks. I see the benefit in this in that it would be possible to work on multiple features or bug fixes concurrently in different branches and merge them back to the master branch (trunk?) as they become mature. – Mark Williams Apr 19 '11 at 08:41
  • 1
    @willburt: yes, if you are coming from svn, you are used to call the master branch `trunk`. they are very similar, but with git (and any other distributed vcs) there are many `master` branches (every cloned repository has one), so the tree metaphore does not make much sense anymore – knittl Apr 19 '11 at 08:43
9

The one thing you need to consider with a DVCS (Distributed Version Control System) like Git or Mercurial is the "publication" workflow (orthogonal to the branching workflow).

When you have only branches, you will ask yourself what development effort they represent.
If master is meant to represent stable code, like knittl details in his answer, then yes, you need to branch from/merge to master.

But when you can clone/push/pull (that is publish to different repos, which can have different purposes in themselves), then 'master' can play a different role from repo to repo.

  • a development repo can have many branches, with master usually representing the most stable code.
  • a deployment repo can have only master, and some hotfix maintenance branch for urgent fixes.
  • a local test repo can have only one master branch, rewritten from push to push just in order to run some static analysis code by a hook which monitors only said master branch for that test repo.
  • ...
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • This is an under-appreciated/under-documented aspect of using git that I would love to see more details of. At my workplace, we're still using git as the monolithic repository for all roles, using branches to differentiate the roles. – Toybuilder Mar 14 '12 at 18:17
2

When doing commits on both sides -- that means on your local repository and upstream e.g. from other team members -- it can happen that commits conflict. That means files and in particular lines were edited by both. In this case some manual merge handling is necessary.

The master branch is for having a local branch representing upstream when you cannot access upstream (mobile use or network failure). It is much easier to do merge resolving and other stuff when having a local branch representing the upstream changes.

Daniel Böhmer
  • 14,463
  • 5
  • 36
  • 46
  • the question was not about upstream/downstream, but why we use feature and maintainence branches etc. – knittl Apr 19 '11 at 08:31
  • Interesting answer. I have never heard of anyone using the master branch as a cache for upstream for disconnected merging. – Robin Green Apr 19 '11 at 08:37
  • I cannot exclude other reasons for having `master` and something else. But Wilburt exclicitly asked for why having a `master` which is not changed at all but only used for merging. When I learned Git I was told to leave `master` untouched and it worked quite well. With more experience e.g. in merging one can save that part. – Daniel Böhmer Apr 19 '11 at 08:41
0

Not sure if my understanding is correct, I am new to git.

I think it makes life easier when you have several features.Let's say you have a project, and work on feature A, then later you implement feature B.

Now it can happen, that you decide that the whole feature A was a mistake, and you want to have a version of your project with only feature B, but without A. If everything is on master, this task is tricky.

If each feature is on its own branch, then this task is easy: You take the old master version (without A and without B). You merge branch B. Done.

AndrzejO
  • 1,502
  • 1
  • 9
  • 12
  • 1
    Although this workflow can also be accomplished using [feature flags](https://en.m.wikipedia.org/wiki/Feature_toggle) (assuming each feature is destined for production), it definitely could be easiest in git if, say, the feature on Branch A is so unstable that it will be shelved. – C. Peck Mar 23 '19 at 02:31