Thank you Alex and Paul. It's been useful to hear the pros and cons. I'm thinking of trying a front end (perhaps Tower) to see if that makes atomic commits easier.

Roddie


On 24/05/2013 15:46, Alex Lewis wrote:
I'd agree branching is "all that" and should be the way to do
development, it's more of a question of /how many/ branches you go with
and being sensible about it. As your branch count proliferates then it
can become more complicated to keep track of what is going on, what's
being done where, etc. I'm not saying it's difficult to pull things back
into line or clean up the branches once you know what you want to
achieve and Git is incredible, if not sometimes almost magical, at doing
that.

The point is really that you have to find the branching model that fits
your development process and strikes the balance between time spent in
the VCS compared to getting things done and striking that balance
sometimes takes a little thought and practice. You may find that as you
become more proficient and comfortable with Git and branching that you
would benefit from some extra branches, if so then get branching.

It's all about experimentation and finding out what works for you and
its a true testament to Git that it can lend itself to so many
situations, to be so flexible and versatile.

On Friday, May 24, 2013 3:16:37 PM UTC+1, Paul Smith wrote:

    On Wed, 2013-05-22 at 20:02 +0100, Roddie wrote:
     > 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.

    I've read the replies here but unless I'm misunderstanding the problem
    they seem more complex than necessary.

    Yes, of course, ideally in the real world you'd have perfect foresight
    and every change would be self-contained and made on an individual
    branch and you can just use "git merge" to pull them together.  But
    life
    is not perfect, and for sure foresight is not perfect.  Suggesting that
    you can't use branches unless you gain such foresight, or that it's
    more
    painful to branch than not in the "real world", is doing branching (and
    Git) a disservice.

    The first thing to do is get into the habit of making individual
    commits
    that constitute single, relatively atomic changes.  It's not always
    easy
    to retrain yourself but it will pay off big-time.  This is made a LOT
    easier if you have a decent front-end for Git: if you use Emacs I can't
    recommend "magit" enough for this.  With the right front-end, creating
    commits is trivial; it will even let you choose individual patch hunks
    to commit while leaving the rest of the file for later commits.  You
    can
    make lots of changes, then go through later and commit them in parts.

    If you've done that, then if you decide you need one of those
    commits on
    another branch, you can use the "git cherry-pick" command to trivially
    grab a commit from another branch and apply it to your current branch.


    But what if, for whatever reason, you just want the contents of a file
    or two from another branch, but not an entire commit?  It's trivial;
    see
    this Git tip:

    
http://jasonrudolph.com/blog/2009/02/25/git-tip-how-to-merge-specific-files-from-another-branch/
    
<http://jasonrudolph.com/blog/2009/02/25/git-tip-how-to-merge-specific-files-from-another-branch/>


    (TL;DR: use "git checkout <otherbranch> <file1> <file2> ...)


    What if you only want parts of the other file, or the other file is
    changed locally so you want to "merge" it, not just replace it?
      This is
    also trivial, see this SO discussion (a shame no one accepted the
    answer :-/):

    
http://stackoverflow.com/questions/10784523/how-do-i-merge-changes-to-a-single-file-rather-than-merging-commits
    
<http://stackoverflow.com/questions/10784523/how-do-i-merge-changes-to-a-single-file-rather-than-merging-commits>


    (TL;DR: use "git checkout --patch <otherbranch> <file1> <file2> ...)


    Upshot: branches definitely _ARE_ "all that" and you should be using
    them as much as possible.  They do not have any problems whatsoever
    handling the complexity of the real world.

    Cheers!

--
You received this message because you are subscribed to the Google
Groups "Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to