[ACCEPTED]-Reasons for not working on the master branch in Git-dvcs

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

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

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

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

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

• master
• next
• pu
• maint

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

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

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

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

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

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

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

But when you can 4 clone/push/pull (that is publish to different 3 repos, which can have different purposes 2 in themselves), then 'master' can play a different 1 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.
• ...

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

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

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

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

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

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