rod mclaughlinGradually Getting Git (25 dec 13)
Not everyone would spend Christmas Day learning a source control system, but I'm not everyone. Based on this superb and brief explanation of Git's power, I'm learning how to REBASE: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf In a nutshell, this is what rebase does: Suppose you have two branches of the same project, foo and bar (created by simply typing 'git branch foo' or 'git branch bar') start - foo1 - foo2 - foo3 I'm not ready to merge bar back into the main branch, foo. But I am aware that people are working on foo too, and files might be getting more and more divergent, meaning when we do merge, it'll be harder. What I do, is 'rebase'. This makes MY branch look as if I started it by branching off of the LATEST commit in foo, which is foo3, rather than the earlier commit, foo2. So my local branch, bar, will end up looking like this: start - foo1 - foo2 - foo3 - bar1 - bar2 - bar3
This makes it simpler to merge, especially if there are many branches. This is how the Linux kernel is maintained, for example. Rebasing sometimes requires 'resolving conflicts'. For example, suppose I DELETE a file in branch bar, and someone else CHANGES it in branch foo. What happens when I rebase, bar onto foo? # I DO THIS: It's better to deal with this now rather than later: $ git rebase --abort Refer to http://ftp.newartisans.com/pub/git.from.bottom.up.pdf for what to do next. Back
|