Git tips and tricks

I am big fan of git and git usage from command line. In this short article and folowing ones, I will try to explain few git features which can bust your development and solve daily problems.

Oh no, we have a regression…

No matterhow hard developers are trying to implement feature and solve bug while keeping rest of functionality intact, from time to time, regressions happen.

Regression search usually takes 2 steps:

• Find which version doesn’t have regression
• Find exact which change cause regression

Best suggestion for first problem is to check one older version. Usually that one doesn’t have problem. I am that’s why it’s called regression in first place, problem was not found in previous version. 😊

Suggestion for second problem will be explained in rest of article

Let look of next example. This project has 2 versions v1.0.0 and v2.0.0. Between those versions there are 10 changes. Just for exercise, let’s say version v1.0.0 is good, meaning it doesn’t have any problem, while QA team found problems on version v2.0.0 which is marked as regression.

How to find exact which change cause a problem in project?

vranic@lenovo-ideapad-vranic:/mnt/e/workspace/true/medium/bisect$ git log --oneline
5570f18 (HEAD -> master, tag: v2.0.0) Change #10
ee1c4ae Change #9
4edbcb5 Change #8
2f86ae0 Change #7
ead7c4d Change #6
2a11eb2 Change #5
e7976ae Change #4
5dc806f Change #3
51324fc Change #2
48283b2 (tag: v1.0.0) Change #1

There are several ways how to do it:

• By intuition, if developer knows what a problem is and with experience what was changed problem can be easily identified
• Brute force: let’s check every change between versions. This could be an option if there are only few changes, but in our example there are 10 changes, please let’s just don’t check each of them.
• User git bisect command!

Bisect command is powerful tool which allows developer to quick find problematic change in big set of git commits. Instead of checking for every change, bisect start checks from last known good change, then split by half remaining set of “bad” changes and let developer to verify result.

Example git project

Let’s see command in action. To start type start:

vranic@lenovo-ideapad-vranic:/mnt/e/workspace/true/medium/bisect$ git bisect start

Select last known good change. Let’s use one with version v1.0.0:

vranic@lenovo-ideapad-vranic:/mnt/e/workspace/true/medium/bisect$ git bisect good v1.0.0

Select last change which was notice to be wrong:

vranic@lenovo-ideapad-vranic:/mnt/e/workspace/true/medium/bisect$ git bisect bad v2.0.0
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[2a11eb211b6ccb83334f3ab74147dfb4bc50bc4d] Change #5

Bisect will split set of 10 changes into half and will ask developer to check and confirm is current state of code good or bad.

vranic@lenovo-ideapad-vranic:/mnt/e/workspace/true/medium/bisect$ git log --oneline
2a11eb2 (HEAD) Change #5
e7976ae Change #4
5dc806f Change #3
51324fc Change #2
48283b2 (tag: v1.0.0, refs/bisect/good-48283b2c48c5da9d5a0d34c4eb05672000511555) Change #1

Okay, but wow this help? If it’s good then problem is on other side of set, if it’s bad problem in in current side of set. In any case, bisect will cut on half appropriate set of changes and keep looking for wrong one.

Example git project, split set in 2 subsets

Let’s say that there is still problem, meaning something in changes from #1 to #5 is wrong:

vranic@lenovo-ideapad-vranic:/mnt/e/workspace/true/medium/bisect$ git bisect bad
Bisecting: 1 revision left to test after this (roughly 1 step)
[5dc806f4357748b6b29d85e0865c0880590e57d1] Change #3

Bisect will keep working with red set and in next iteration will split remaining it in 2 subsets.

vranic@lenovo-ideapad-vranic:/mnt/e/workspace/true/medium/bisect$ git log --oneline
5dc806f (HEAD) Change #3
51324fc Change #2
48283b2 (tag: v1.0.0, refs/bisect/good-48283b2c48c5da9d5a0d34c4eb05672000511555) Change #1

Is current set good or bad? Let’s say it’s good, meaning changes from #1 to #3 doesn’t have any problem.

Example git project, something is wrong in changes #4 or #5

vranic@lenovo-ideapad-vranic:/mnt/e/workspace/true/medium/bisect$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[e7976ae2cb34db02c5b1db9d0305b9621d3a97d8] Change #4

In last stage which wrong one? Bisect will position on #4 so if put good, meaning change #5 is wrong one or if we but bad then change #4 is wrong one.

vranic@lenovo-ideapad-vranic:/mnt/e/workspace/true/medium/bisect$ git log --oneline
e7976ae (HEAD) Change #4
5dc806f (refs/bisect/good-5dc806f4357748b6b29d85e0865c0880590e57d1) Change #3
51324fc Change #2
48283b2 (tag: v1.0.0, refs/bisect/good-48283b2c48c5da9d5a0d34c4eb05672000511555) Change #1

Example git project, something is wrong in change #5

Let’s say current state is good.

And we have a winner! Problem is in change #5.

vranic@lenovo-ideapad-vranic:/mnt/e/workspace/true/medium/bisect$ git bisect good
2a11eb211b6ccb83334f3ab74147dfb4bc50bc4d is the first bad commit
commit 2a11eb211b6ccb83334f3ab74147dfb4bc50bc4d
Author: Nikola Vranic <nikola.vraniC@truedigital.com>
Date: Mon Sep 20 08:23:10 2021 +0200
Change #5
file.txt | 1 +
 1 file changed, 1 insertion(+)

Once problematic change is found, it’s time to fix it. How? There are many ways:

• Amend change
• Interactive rebase
• Create new branch
• …

Conclusion

Hope you enjoy reading. If you are not a wizard who can found regression just looking at git log, or don’t have time machine to check all possible changes, use bisect git command.

In presented example, instead of taking 10 steps to check every change, only 3 were needed to find problematic change. This difference is even bigger in case of larger change set.