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.


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

Attachment: pgp9vP1eZei5A.pgp
Description: PGP signature

Reply via email to