Git is the most popular version control system in the entire known universe. Somehow, I wasn’t part of this universe until about six months ago. In my last workplace, we got by using SVN. Looking back, I don’t even know why we chose SVN. Oh wait, I know–it was one of those things that belonged to the list of the company'slong-runningtraditions, and nobody took the initiative to change it.
Here are some of the Git commands that I have learned over the past few months. I wish I had known about them the day I started using Git :
1.git commit --amend --no-edit
Earlier, every time I forgot something, I went ahead, made changes, and pushed another commit. This is what my commit history looked like:
However, when you look at those commits, you promptly make it your mission to find out the person who did that. I used to be that person,and somewherealong the way, I decided to take care of that mess I was spreading all around carelessly in my repos.
Simple solution:git commit --amend --no-editlets you add the currently staged changes to your last commit. Exclude the--no-editoption and Git will ask you whether you wish to change the commit message. This command comes in very handy for those cases when you find out that you need to make a little change after you’ve already committed your changes.
2.git rebase -i
Sometimes, while I am working on a feature, somebody else pushes code that would be useful in my current task. To get their changes, I often merge master to my feature branch. However, that may lead to a commit history that includes a few master to feature branch merges. Here comes another nifty Git command to the rescue!
Before pushing my code upstream, I rungit rebase -i origin/master. This is a powerful command that lets us do loads of stuff with commits that are present in our branch.
For example, this message shows up when I try to run the above command.
I can then edit commit log messages or squash commits (hint: squash those last two commits!). The best part: Git opens this in your editor, so operating on those commits becomes as easy as changingpicktodrop(if you want to remove a commit).
3. Deleting all local branches that were merged to master
I often found myself deleting a local branch after I'd merged it to master and deleted it on Github. This was my usual flow for quite some time,and Ifinallygot tired of doing this. Like with all things Git, of course, there indeed was a better way to do it.
git branch --merged master | grep -v '^[ *]*master$' | xargs git branch -dlets us delete local branches that were merged into master.
Let’s check what this command does :
git branch --merged master: This command lists the branches that were merged to master.
grep -v '^[ *]*master$': This part of the command excludes the master branch from getting deleted. I can’t think of a scenario where you’d want to delete the master branch. Well, except when your main branch is not master, then maybe you’d want to delete master. In that case, don’t forget to replace `master` with your main branch’s name in the above command.
xargs git branch -d: This is what actually deletes your branches.
So, instead of going through the list of branches and deleting them one by one, I go nuclear on them and get the job done in 5 seconds. Also, it would be a good idea to add that as an alias, wouldn’t it?
Imagine, you'vejust started working on a feature and suddenly have to switch branches. In such cases, I used to reach out for commit and later would amend that commit when I had more useful changes. Such a waste of commits!
git stashis a cooler way tojuststash (it’s in the name!) your changes and apply them later again. Before switching branches, rungit stash, then switch branches and when you’re back to the feature branch, rungit stash popand those changes will be applied to your branch.
Stashing also helps in cases where you've made changes to a different branch than the one you were supposed to. For instance, the other day, after having worked for 10 minutes, I realised I was on feature2whereas I was supposed to making changes on feature1. Ijustsighed carelessly and ran these commands :
And Ikept on working. Gone are the days when I used to pray to God almighty every time Git said something to me.
All those weeks went by,and Ididn’t have the slightest idea that something broke. No, I haven’t reached this level of mastery yet but this is a command which I found really interesting, and hence it makes the list.
git bisectuses binary search and helps us find the commit where the bug crept in. It’s a powerful, yet simple process that goes as follows:
git bisect start: Telling Git I mean business.
git bisect bad HEAD: Letting Git know that the bug is alive on HEAD.
git bisect good HEAD~10: Marking the commit which I’m sure didn't consist the bug as good.
Now, git will pick a commit between the two I provided above and ask me whether the commit is “good” or “bad”. It will keep on going,and in no time, I can find the culprit. Now, we got to blame someone for this, right?