As Revision Control Software I’ve always been using Apache SVN. It’s a good tool, but now, my team in Nokia is using Git. Far be it from me to start a war about which tool is the best, I want only to share how learning Git is turning out to be a real pleasure.
I started with a completely free book: Pro Git. Give it a try.
Already at chapter 3, Git Branching, I was so exciting. Let me quote a sentence from it: “Understanding and mastering this feature gives you a powerful and unique tool and can literally change the way that you develop“. It seems too much, but it’s true.
Leaving behind us Git Branching, what I want to do with this post is sharing a nice Git workflow I used a couple of days ago in the office.
This is the scenario: we are new to the project. There are tons of code lines and classes that we are still studying and assimilating. But we already have a task: we have to add a functionality and we know where things related to it are supposed to be found. We look into the file and… mmmm, something is missing! It seems like the file just got under refactoring some time ago. What we were looking for seems to be moved!
No panic! 😀 …It is also in this kind of situation that a VCS becomes very helpful. Let’s play a bit with Git.
We know the name of the developer that last worked on that piece of code. Than we fire on the shell the following command:
git blame $(find . -name "ModifiedFile") | grep "DevName"
Boom! We have the code’s lines where the Developer worked and these lines present also the SHA-1 hash of the commit. Now we know a little bit more, and it’s so easy to ask Git to show us the commit log related to that commit:
git log "commit SHA-1"
Now, finally, we can read something about what was done. Interesting! For performance reasons, the functionality we were looking for was moved in a special new class. Good to know! But, unfortunately, the commit message doesn’t tell us the name of the new introduced class
Again, no panic! 😀 …Git knows everything, the trick is to ask it the right question:
git diff-tree --no-commit-id --name-only -r "commit SHA-1"
And there they are. All the files modified in that precise commit. Now we know where to find the functionality we were looking for! Let’s break it up! 😛
- git-blame: show what revision and author last modified each line of a file. We have used this command together with two very important Unix commands: find and grep.
- git-log: simply shows the commit logs.
- git-diff-tree: compares the content and mode of the blobs found via two tree objects. If there is only one tree given (like in our case), the commit is compared with its parents.