This page is part of the “Cheatsheet of Epicness: JD’s incomplete collection”, continue the read at your own risk.
If you are here, one of two things happened. Either my SEO is great or you saw the cheatsheet collection entry point and my SEO is still pretty good plus you felt like engaging further. I’d thank you for passing by but you came here to grab some of that git sheet. For that, I have two words for you: git
That being said, say goodbye to the world of children using graphical user interfaces on top of
git commit -m
I’m not really going to go in details for that one as you probably know what it does. If you don’t you can go check it out. Here I want to throw at you a tip. The command I execute over sixty times a day.
git commit -m "Write your message without the awful vi UI"
Yes, you don’t need to deal with a UI for the sixties by appending a simple parameter and your message directly behind it. You will not know how much time it saves you until you have to do it more than twenty times a day. You can thank me later.
Ah, the good old rebase. Wielded correctly it can do great good, especially through the command line. You will move faster in an environment where you have a team working on the same branch. However, the smallest mistake will turn the rebase into your greatest foe. Now you can pick some easy commands or look for more details there.
Rebasing on top of a local branch
git rebase (local_branch_name)
Some would think is the least confusing use of
local_branch_name. You may commonly use
git rebase my_other_local_branch_name
Rebasing on top of a remote branch
git rebase (remote_name)/(remote_branch_name)
That one is your best friend if you need to pull remote changes, especially when dealing with open-source projects. Using
git rebase origin/master sometimes is the difference between an approved and a denied pull request. Be wary of not forgetting the
/ between the remote and the branch name. I did that a few times because I did not remember the about the
/. When the branch you want to rebase on top of is the main branch of your remote you will be fine. However, when that is not the case you’re in for an ocean of pain. This is why I always create a branch of my current development branch before attempting a rebase. That way if I screw it up I scrap it and restart.
git cherry-pick but with a range
You may already know about
git cherry-pick but did you know you can go faster and grab multiple commits at once? Say you have the following history:
Me ffffffff Somebody help got it all broken again Me eeeeeeee All fixed Me dddddddd Broken commit due to refactoring Me cccccccc Some more refactoring Me bbbbbbbb Clean up code Me aaaaaaaa Implement fixes for bug 101 Me 99999999 Writing tests for bug 101 Me 88888888 Something commit Me 77777777 Last stable commit
I don’t know for you but it doesn’t look like the most stable branch for which the latest commit is
77777777. Now, imagine you need the fix for the bug 101 asap but cannot merge it to the main development branch nor master. Because of the
bbbbbbbb. This is one of the cases where a ranged cherry-pick is useful. Here is how you can apply these commits on another branch off of your main one in one command.
git cherry-pick 99999999..bbbbbbbb