Reasons for not working on the master branch in Gi

问题:

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?

回答1:

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:

• master
• next
• pu
• maint

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

回答2:

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.

回答3:

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.
• ...

回答4:

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.