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?
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