Really killer features of GIT
Hi, everyone!
I often see a lot of manuals about git for beginners. I opened a random article and see the notes: “How to change the last commit message? Simply! Just type git commit --amend“. Ah, I think it’s impossible to find something more interesting now. But now you don’t need to think so. I want to show you some of the killer features of GIT, which can save your time. Let’s start!
All constant and variable names below are fictional, but they are based (probably) on real situations.
Power of git logs
In one winter evening in Russia I researched source code of project which I was working on and found really strange constant. If you develop next EA Games FIFA release you can imagine that you find next name: MAX_AMOUNT_OF_FISH. This name has same strangeness how my constant has in my project. I thought “WTF? How we use it? I can understand nothing!” Then I opened console and typed: git blame ‘file_with_strange_constant’ What had I just seen? My workmate (let name him “Rasim”) imported it from another file. I asked: “Rasim, thank God, what does it mean?”. Rasim answered me: “I don’t now, it just works”.
It seems that me and my project had a great problem and I didn’t know how to solve it. Stop. Not today! I remembered one article, forgot the command author used for it, but I remembered that it was useful for that case. I opened my bookmarks in browser and found the article. (A little bit of recursion to give you the note to save this ideas somehow). In article I saw:
git log -S "MAX_AMOUNT_OF_FISH"
This one will show you all commits in which authors has this constant name in their diff. It’s obvious that when you scroll down logs, you will find the first commit with this ugly name. Now you have original author of constant and list with names of guys which used it. It’s time for punishment, right?
Time Traveling
In another day it was summer, 1:00 p.m. In the streets of my city it was hot like January in Alice Springs, but in our office it was even hotter. Every API endpoint answered of requests three times slower, but I remembered awesome performance two weeks ago.
Rasim is very productive software developer and he pushes around 100 commits per day and 200 commits per weekends. He promised that he didn’t change any performance-related code. But.. how I can show him that it was better? Open commit logs and scroll it a lot? Not today! GIT can understand you more quickly. Rasim, let’s see that I’m right. Please, checkout to state of two weeks ago:
git checkout @{two.weeks.ago}
Do you see, Rasim? Good!
Find bugs with O(log N)
Let’s find problematic change with binary search. We use git bisect command for that.
git checkout development
git bisect start
git bisect bad
git bisect good @{two.weeks.ago}Probably you know about this feature. After you type these command git start automatic moving you to some commits and ask you: “Is it good or bad?” If you don’t deceive it, after some questions git will show your commit, which has problem, but has parent without problems.
Joking aside!
In another day, when we fixed bug, which blocks everything, we tried to resolve the problem quickly. In the large file we had a lot of function calls and different variables. We introduced some fixes for that and saw that we changed only this one file:
Changes not staged for commit:
(use “git add <file>…” to update what will be committed)
(use “git checkout — <file>…” to discard changes in working directory)modified: lib/awesomeModule.cppno changes added to commit (use “git add” and/or “git commit -a”)
When we looked at that difference, it had a lot of debugging information. Commands for print variable names, comments, timing metrics. Rasim said “ho-ho, let me open our great text editor again! We need to remove our extra pieces of debugging code!”
I answered: “NOT TODAY! We wouldn’t shame our skills in article about GIT”. He decided I was right and solved the problem with another magical command. Which command, guys? This one:
git add -p lib/awesomeModule.cpp
After typing this, git starts to discuss with you again (like in the last summer) and you can decide together which changes are for committing, and which changes are unnecessary. I won’t describe GIT docs and describe how to talk with GIT here. If you have doubts, input ? , and GIT will help you.
Presented you all tips I committed in my brain. I believe there are a lot of useful another tips, but I won’t write an article just by googling something. I describe ideas based on my experience and hope these four tips will be useful.
Thank you for reading, guys!
