1.

How does ‘git rebase’ work? When should you rebase your work instead of a ‘git merge’?

Answer»

There are scenarios wherein one would like to merge a quickfix or feature branch with not a huge commit history into another ‘dev’ or ‘uat’ branch and yet maintain a linear history.

A non-fast forward ‘GIT merge’ would result in a diverged history. Also when one wants the feature merged commits to be the latest commits; ‘git rebase’ is an appropriate way of merging the two BRANCHES.

‘git rebase’ replays the commits on the current branch and place them over the tip of the rebased branch.Since it replays the commit ids, rebase rewrites commit objects and create a new object id(SHA-1). Word of caution: Do not use it if the history is on release/production branch and being shared on the central server. Limit the rebase on your local repository only to rebase quickfix or feature branches.

Steps:

Say there is a ‘dev’ branch that needs a quick feature to be added along with the TEST cases from ‘uat’ branch.

  • Step 1: Branch out ‘new-feature’ branch from ‘dev’.

Develop the new feature and make commits in ‘new-feature’ branch.

[dev ] $git CHECKOUT -b new-feature [new-feature ] $ git add lib/commonLibrary.sh && git commit -m “Add commonLibrary file” Divya1@Divya:rebase_project [new-feature] $git add lib/commonLibrary.sh && git commit -m 'Add commonLibrary file'Divya1@Divya:rebase_project [new-feature] $git add feature1.txt && git commit -m 'Add feature1.txt' Divya1@Divya:rebase_project [new-feature] $git add feature2.txt && git commit -m 'Add feature2.txt'
  • Step 2: Merge ‘uat’ branch into ‘dev’
[dev] $ git merge uat
  • Step 3: Rebase ‘new-feature’ on ‘dev’
Divya1@Divya:rebase_project [dev] $git checkout new-featureDivya1@Divya:rebase_project [new-feature] $git rebase dev First, rewinding head to replay your work on top of it... Applying: Add commonLibrary file Applying: Add feature1.txt Applying: Add feature2.txt
  • Step 4: Switch to ‘dev’ branch and merge ‘new-feature’ branch, this is going to be a fast-forward merge as ‘new-feature’ has already incorporated ‘dev’+’uat’ commits.
Divya1@Divya:rebase_project [new-feature] $git checkout dev Divya1@Divya:rebase_project [dev] $git merge new-feature Updating 5044e24..3378815 Fast-forward feature1.txt         | 1 + feature2.txt         | 1 + lib/commonLibrary.sh | 16 ++++++++++++++++ 3 files changed, 18 insertions(+) create mode 100644 feature1.txt create mode 100644 feature2.txt create mode 100644 lib/commonLibrary.sh

this will result in linear history with ‘new-feature’ results being at the top and ‘dev’ commits being pushed later.

  • Step 5: View the history of ‘dev’ after merging ‘uat’ and ‘new-feature’ (rebase)
Divya1@Divya:rebase_project [dev] $git hist * 3378815 2019-02-14 | Add feature2.txt (HEAD -> dev, new-feature) [divya bhushan] * d3859c5 2019-02-14 | Add feature1.txt [divya bhushan] * 93b76f7 2019-02-14 | Add commonLibrary file [divya bhushan] *   5044e24 2019-02-14 | Merge branch 'uat' into dev [divya bhushan] |\   | * bb13fb0 2019-02-14 | End of uat work. (uat) [divya bhushan] | * 0ab2061 2019-02-14 | Start of uat work. [divya bhushan] * | a96deb1 2019-02-14 | End of dev work. [divya bhushan] * | 817544e 2019-02-14 | Start of dev work. [divya bhushan] |/   * 01ad76b 2019-02-14 | Initial project structure. (tag: v1.0, master) [divya bhushan]

NOTE: ‘dev’ will SHOW a diverged commit history for ‘uat’ merge and a linear history for ‘new-feature’ merge.


Discussion

No Comment Found

Related InterviewSolutions