Concepts and Workflows Flashcards
What is a forked history
You work in a feature branch.
Meanwhile someone updates the master branch with new commits.
This results in a forked history.
If these commits are relevant to your branch you will consider to incorporate the new commits to your feature branch with git rebase or git merge.
How to merge
To merge commits from another branch into your local branch
git checkout feature
git merge master
Or condense this into a one liner
git merge feature master
What is a merge
A merge will result in a new “merge commit” in the feature branch that ties together the histories of both branches.
Merging is a non-destructive operation. The existing branches are not changed in any way.
On the other hand this also means that the feature branch will have an extraneous merge commit everytime you need to incorporate upstream changes.
If master is very active, this can pollute your feature branch’s history quite a lot (advanced git log can mitigate this issue). It can make it harder to understand the history of the project.
How to rebase
You can rebase a feature branch onto a master branch using the following command:
git checkout feature
git rebase master
What is a rebase
A rebase moves the entire feature branch to begin in the tip of the master branch, effectively incorporating all of the new commits in master.
But, instead of using a merge commit, rebasing rewrites the project history by creating brand new commits for each commit in the original branch.
It merges another branch into the branch where you are currently working, and move all of the local commits that are ahead of the rebased branch to the top of the history on that branch.
What are the benefits of rebasing
You get a much cleaner project history.
It illuminates the unnecessary merge commits required by git merge. Rebasing also results in a perfectly linear project history (you can follow the top of the feature all the way to the beginning of the project without any forks. This makes it easy to navigate your project with commands like git log, git bisect and gitk
Two trade-offs for git rebase strategy
Safety when rewriting project history follow the golden rule of rebasing and traceability as rebasing loses the context provided by a merge commit - you can’t see when upstream changes were incorporated into the feature.
The golden rule of rebasing
Never use it on public branches.
e.g. If you rebased master onto your feature branch
The rebase moves all of the commits in master onto the tip of feature.
The problem is this only happened in your repository.
All other developers are still working with original master.
Since rebasing results in brand new commits, Git will think that your master branch’s history has diverged from everybody else’s.
The only way to synchronise the two master branches is to merge them back together, resulting in an extra merge commit and two sets of commits that contain the same changes (the original ones and the ones from your rebased branch).
Before running got rebase it’s important to know if anyone else is working on that branch
Interactive rebasing
Gives you the opportunity to alter commits as they are moved to the new branch. This is even more powerful than automated rebase since it offers complete control over the branches commit history.
Typically this is used to clean up a messy history before merging a feature branch into master.
To begin an interactive rebasing session pass the i option to the git rebase command
git checkout feature
git rebase -i master
This will open up a text editor listing all of the commits that are about to be moved.
This listing defines exactly what the branch will look like after the rebase is performed.
By changing the pick command and/or reordering entries you can make the branches history look like whatever you want.
e.g. if the second commit fixes a small problem in the first commit you can condense them into a single commit with the fixup command.
This eliminates insignificant commits which makes your features history much easier to understand. This is something git merge simply cannot do
