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/ > > > (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 > > > (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.
