If you’re like me who working on Git all the time, you will fall in love with Git easily.
Git is a powerful yet convenient version control tool and fit perfectly our daily development workflow.
I know we have a lot of Git tutorial out there already. So inside this article, I will list up 3 Git commands that we maybe use not very often, but It will be very useful when we need.
*) Create a sharable diff
Is it cool that we can make a sharable diff from this famous diff text?
Git call this: “patch”. Here’s how to generate a patch file from your source code changes:
$ git diff > DescriptString.patch
Now you can distribute this patch file the way you want. Maybe you need to share the file to your co-workers, or to apply it to another branch.
$ git apply DescriptString.patch
*) Contributing statistic
In open source projects, you usually see Contributors page, where listed out all the developers involved in source code. Here’s how to calculate by git command
$ git shortlog –no-merges –summary –numbered
*) Narrow down a mystery bug
Have you heard of binary search?
Do you know that you can ultilize binary search with git to narrow down a mystery bug?
If you don’t know what is breaking, and there have been dozens or hundreds of commits since the last state where you know the code worked, you’ll likely turn to git bisect for help. The bisect command does a binary search through your commit history to help you identify as quickly as possible which commit introduced an issue.
By using “git bisect”, we mark the first (say, the last working version on production) and the last commit (say, new feature introduced) that are safe, and start narrowing it by half.
$ git bisect start # Start the process
$ git bisect bad # Mark the current commit is ‘bad’
$ git bisect good v4.6 # Mark the tag version 4.6 is ‘good’, which should be the last-known-working-well-commit
After running this, Git will calculate that, for example, there’re 12 commits included since v4.6 to the current commit,
Git then will checkout to the middle of those 12 commits (which is 6 commits after v4.6)
Then our job is running test to verify if you can reproduce the issues.
If you can, the problem was introduced in the first 6 commits after v4.6
If you cann’t, the problem was introduced in the last 6 commits after 4.6
Go on, you can narrow down where’s the problem is. In reality, “12 commits” would likely be hundreds of commits, and “git bisect” will be our savior in such cases.
$ git bisect good v1.0
Bisecting: 6 revisions left to test after this
[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo
$ git bisect good
Bisecting: 3 revisions left to test after this
[b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing
One special note on git bisect is: on the way finding bad commit, we can setup git automatically run script test at each time git checkout new commit, by running this command:
$ git bisect run test-error.sh
Git is not just a powerful tool, but also a good friend to us developers. Understand & appreciate our friends!