After my lunch & learn talk, I realized I did not go over the
difference between rebase and merge, two techniques to get work into a
branch from another.
The main difference between testing & master branches:
ec0d: common parent to both creates the file: important_file.txt
c02b: master adds a line to the important_file.txt
c2a5: testing adds a new file: testing_file.txt
Details of common parent to master and testing: ec0d
Details of the commit added to master: c02b
Details of the one commit added to testing: c2a5
Summary of repository branches:
ec0d: common parent, creates important file
c02b: master branch - extends important file
c2a5: testing branch - adds testing file
Let’s get changes from testing (c2a5) onto master (c02b) using the
two common ways in git: merge and rebase.
Merge
Let’s get changes from the testing branch, c2a5, onto the master
branch, c02b by merging, and using a different branch aptly named:
merge_testing_to_master:
Let’s look at the result via $ git log --graph:
Notice that the new merge commit, ea82, points to the testing
branch, c2a5, and master branch, c02b.
Rebase
Now, let’s do the same thing: get changes onto the testing branch,
c2a5, onto the master branch, c02b, using the rebase technique on
a new branch, aptly named: rebase_testing_to_master:
Let’s take a look at the result using $ git log --graph:
Notice that there is no commit between the master and testing branches
as in the merge technique. The master commit, c02b, does not appear
in this branch’s history, BUT there is a new commit, e460, which has
the same commit message as the, c02b master commit:
FIX: Enhance important file
The details of the e460 change is:
Notice that this new commit has exactly the same contents as the
original master commit, c02b:
Even down to the file change: index 0b438af..652404b 100644
Differences
The $ git diff of the branches produces no differences:
History Difference
The only place where there is a difference is the history of the
branches, the merge technique introduced a new merge commit, ea82,
while the rebase technique changed the master commit from: c02b to
e460.
The rebase took the work of the testing branch, c2a5, and put it
underneath the current master branch, c02b, and making a new commit
for it, e460.
Big Picture
Taking a look at all the branches using $ git log --graph --all
--oneline shows:
Both branches share a common parent in current HEAD, ec0d, but where
they end up afterwards is slightly different, both produce their own
path forward:
rebase made everything linear by recommiting the master work on top
of the testing work
merge created a new commit, referencing both master and testing
Options, options
Which one should you use? I prefer to rebase everything so the work of
the branch HEAD points to is ahead of everything else. I am a bit
annoyed with merges since it creates another commit.
Conclusion
To get work from another branch onto the current branch, there are
git rebase and git merge.
Rebasing creates a new commit of the current work and “slides” all the
other branch’s work underneath. Keeping history in a linear fashion.
Merging creates a new commit that points to both the current branch
and the other branch’s work.
Which one to use is a personal preference, but I tend to prefer
rebasing over merging, only to keep history clean.