On Wed, May 22, 2013 at 08:02:50PM +0100, Roddie wrote: > I'm fine with Git and branches when it's simple, but as soon as > things get a little complicated, I get baffled and frustrated. > > For example... > > I've set up a members' log in system for a website, including a > log-in form on the home page. The template for the home page was > amended in the process. That's all committed on branch "memlogin". > > That work is on hold because I have to get adverts on the home page, > and I've made a new branch - "adverts". This was branched from the > master branch, so does not include any of the work on "memlogin". > But I need the revised home page template file because the log-in > form affects the position of the adverts. > > This is just an example. The general point is about how branches are > not, in reality, completely independent, and work on one can affect > another. > > What should I do? > > I have the feeling that I'm missing the point about branches. > Everyone raves about them, but they seem to fail as soon as the > complexity of the real world kicks in. > > BTW, I'm familiar with the diagram from nvie.com, but it doesn't > answer this problem - its feature branches are completely > independent until merged into the develop branch. In my experience > the world is not that neat and tidy. > > I'd appreciate any advice.
With the risk of sounding a bit patronising it seems you've forgotten the other side of the coin -- merging. If, and this is a big if, your changes to your work on the home page template file is contained in self-contained patches, then you can merge those changes from 'memlogin' to 'adverts'. If that's not possible you might be facing the risk of having to progressing 'memlogin' to a point where it can be deployed. Merge it into 'master' and then restart 'adverts' from there. I think feature branches are the bee's knees too, but they aren't as easy as in all the examples one reads -- they require some up-front thinking. In particular it's problematic when dependencies between features emerge during development. In essence you then only have two options, finish them in order of dependency, A then B, or don't. If you don't you'll probably end up hacking up certain aspects of B just to make it good enough, then when A is finished you can revisit B. Unfortunately not an answer to "What should I do?" Because that's really only an answer you, or your project manager, can answer. But hopefully it aids in thinking about the trade-offs of your options. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay
pgp9vP1eZei5A.pgp
Description: PGP signature
