This page is part of the “Cheatsheet of Epicness: JD’s incomplete collection”, continue the read at your own risk.
Cheatsheet
| Thing to do | Command to do it |
|---|---|
| Commit code with the message “Hello commit” | git commit -m "Hello commit" |
| Revert pre-commit changes on file src/test.c | git checkout -- src/test.c |
| Revert post-commit changes on file src/test.c to the version on the master branch | git checkout master -- src/test.c |
| Listing remotes | git remote -v |
| Add new remote remote_name with url remote_url | git remote add remote_name remote_url |
| Rename remote old_name to new_name | git remote rename old_name new_name |
| Rebase current branch on top of the local master branch. | git rebase master |
| Rebase current branch on top of the master branch from the origin remote | git rebase origin/master |
| Cherry-pick a range of commits from aaaaaaaa to bbbbbbb | git cherry-pick aaaaaaaa..bbbbbbbb |
| Delete all local branches except for the current one | git branch | grep -v ^* | xargs git branch -D |
| List all the dangling commits. Useful to recover code from local/remote deleted branches. | git fsck --full --no-reflogs | grep commit |
| Reset the very first commit in a repository | git update-ref -d HEAD |
| Display fancy log graph in terminal | git log --graph --oneline |
| Reset all submodules from root project | git submodule foreach git reset --hard |
Older, more verbose version of the cheatsheet
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
Committing code
Commit with a message
I’m not really going to go into detail 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.
Preventing oopsies
Uncommitted
Sometimes you can change a file by accident and not be quite sure what its original state is. Using git reset can be an option if you want to scrap everything but for something more granular you will want to use an individual file checkout.
git checkout -- <filename>This will bring the file back to its last committed state.
If you’ve already committed
Now if you committed your changes but that the version you want to restore is present on another branch named BRANCH_NAME I got you too.
git checkout BRANCH_NAME -- <filename>Contributing to open-source
Remotes
A key element of open-source development is the handling of remotes. You may be of the main development team that has access to the main repository. In that case, handling remotes is not a concern. However, if you wish to contribute to a project you are not part of the only way to help is to work from a fork.
A fork is a copy of the main project repository where you can work from freely. Once you implemented your bit of contribution you open a pull-request. Then after a civilised exchange and potentially corrections, your code may get merged into the main repository.
Git has that concept of remotes which allows you to point your local code to various repositories. The main way I used remotes is to contribute to open-source and usually, I have two: origin and upstream. Origin would be pointing at your fork and upstream at the main project. Wielding these can allow you synchronizing your fork with the main project to avoid code change conflicts.
Listing remote details
git remote -vThe above command lists the repositories you are working with along with their URLs and actions you may use. Here is a sample output with a project I contribute to.
origin [email protected]:CodingNagger/validator.js.git (fetch)
origin [email protected]:CodingNagger/validator.js.git (push)
upstream [email protected]:validatorjs/validator.js.git (fetch)
upstream [email protected]:validatorjs/validator.js.git (push)Add remote
git remote add (remote_name) (remote_url)This command allows you to add a remote by choosing a name and adding the remote URL. You can use both HTTPS and SSH here like you would for a clone command.
Rebase
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 rebaselocal_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 commitI 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 8888888899999999, aaaaaaaa and 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