Git makes working on a project flexible by allowing teams to work in parallel and concurrently. When a team’s work is done, they can bring their work on to the main public branch either by rebasing it or merging it.
Lets take for example two commits from two different branches, live and staging. We assume that both branches have a common snapshot.
For example,
– the staging branch commit history is:
1 2 3 |
Commit A Commit C Commit D |
while the
– live branch commit history is :
1 2 |
Commit A Commit B |
Both branches have a common snapshot in history according to their commit histories.
Rebasing
If we would like to rebase the work that now exits on live, onto our staging branch. We will have to :
1 2 3 |
git checkout staging git rebase live |
This operation will go to the common ancestor for both branches (the live and the staging). It will get the commit history of the staging branch and save the diffs to temporary files. It will then reset the staging branch to the same commit history as the live branch, i.e staging will now be fast forwarded to the commit B snapshot. It will then apply the commits of the staging branch which were previously copied to a temporary files on top of that.
This will simply fast forward the staging branch, with all the changes that were made on the live branch. This really makes your commit history clean and as if the changes were made in sequence while in reality they changes could have happened in parallel.
Keeping the history clean for a remote / public branch is important. It removes any need for additional work and the branch only needs to fast-forward to bring the changes forward.
