You can think of git commits like a long chain. Each time you make a commit, you add one more link in the chain. The problem is that sometimes that chain can split into two chains like this:
D | C C2 | | B -- | A
What most people do when they want to move C2 back into the original chain is what is called a merge and it looks like this:
E | \ D | | | C C2 | | B -- | A
In which E is a commit which combines the changes of C, D, and C2 into a new commit . However, with branches and then branches off of branches this can quickly lead to a spaghetti looking history. Instead, let's see what happens when you switch to the branch with commit C2 (let's call it 'dev') and run rebase on the main line (let's call it 'master'). So
git checkout dev git rebase master
C2 | D | C | B | A
This history is much cleaner now, as C2 was simply moved to the end of the line. This is what rebase does. Note that master is still pointing to 'D', and dev is pointing to the new 'C2' location.