Git Cheatsheet

Git Notes

Recently I’ve been reviewing git basics for some internal presentation, and found some really useful commands which I barely used before(But I wish I could be using more of them from now on). The slide is here for further reference with useful links.

git alias

//set alias
$ git config --global alias.sts status
$ git config --global alias.hist 'log --pretty=format:"%h %s"'

//remove alias
$ git config --global --unset alias.hist
$ git config --unset alias.lg

git status

git status -s --short
git status -b --branch
git status -u --untracked-files

git rm

git rm <files>
git rm --cached <file>
git rm kicks the file off the stage entirely, so that it’s not included in the next commit snapshot, thereby effectively deleting it.
a git rm file will remove the file from the staging area entirely and also off your disk (the working directory). To leave the file in the working directory, you can use git rm --cached. So if you accidentally add sth you don’t want to track(like third-party vendors) in git in the future, use git rm --cached.

git mv

move or rename a file/directory/symlink

git diff

$ git diff
$ git diff --staged
$ git diff --cached
$ git difftool

Add things

//add changed file, new file, not ignored file, but it does not stage 'rm' actions
$ git add .

//add changed file, or removed file, does not add new files
$ git add -u

//shortcut for both
$ git add -A

git commit -a -m "msg"

-a means automatically stage files that have been modified and deleted, but new files you have not told git about are not affected.

git log

$ git log

$ git log -2

$ git log -p -2

$ git log --stat

$ git log  --pretty=oneline

$ git log --pretty=format:"%h - %an, %ar : %s"

$ git log --pretty=format:"%h %s" --graph

$ git log -Sfunction_name

$ git log --since="2014-12-01"

$ git log --after="2014-12-01"

$ git log --until="2014-12-01"

$ git log --before="2014-12-01"

$ git log --author="someone"

...

Working with remotes

$ git remote -v
$ git fetch + git merge = $ git pull
$ git remote show origin
$ git remote rm testorigin

Inspecting branch

$ git log --oneline --decorate
$ git log --oneline --decorate --graph --all $ git mergetool

Working with branch

When you update files in one branch, but those changes are not ready to commit, but you need to switch branch to work on sth else. You could get error message like this:

error: Your local changes to the following files would be overwritten by checkout:
	README.md
Please, commit your changes or stash them before you can switch branches.
Aborting

Let’s use stash to keep those changes, remember that when using stash, the changes are not saved in working directory or git directory, but it is similar to commit.

$ git stash save "some unfinished stuff"
Saved working directory and index state On newfeature: some unfinished stuff
HEAD is now at d6f58fe test merge conflict

$ git stash list

$ git show [-p] [stashname]

//use stash, leave a copy
$ git stash apply

//use stash and drop them
$ git stash pop

Remote branch

Remote branches are references (pointers) to the state of branches in your remote repositories. They’re local branches that you can’t move; they’re moved automatically for you whenever you do any network communication. It acts as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them.

To track branches, which means local branches that have a direct relationship to a remote branch:

$ git checkout -b [branch] [remotename]/[branch]

//shorhand
$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'

To delete a remote branch:
$ git push origin --delete serverfix

Undo things in Git

git checkout

You can use checkout to checkout a file, a commit, or a branch. In terms of undo things, let’s focus on checkout file and commit.

checkout a commit

Once you’ve built up a project history, git checkout is an easy way to “load” any of these saved snapshots onto your development machine.

During the normal course of development, the HEAD usually points to master or some other local branch, but when you check out a previous commit, HEAD no longer points to a branch—it points directly to a commit. This is called a “detached HEAD” state:

You can decide to save changes by creating a new branch or discard them by checkout to other branch.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.  

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:  

git checkout -b new_branch_name

Checkout a file

Checking out an old file will affect the current state of your repository. You can re-commit the old version in a new snapshot as you would any other file. So, as a matter of fact, this usage of git checkout serves as a way to revert back to an old version of an individual file.

git checkout a1039v hello.py

The old file revision will show up as a “Change to be committed,” giving you the opportunity to revert back to the previous version of the file. If you decide you don’t want to keep the old version, you can check out the most recent version:

git checkout HEAD hello.py

git revert

git revert is to undo what happened in a specific commit, and commit it again. That is, generate a new commit that undoes all of the changes introduced in , then apply it to the current branch. Reverting should be used when you want to remove an entire commit from your project history.

Reverting is a “safe” operation since it doesn’t change the project history.

git reset

If git revert is a “safe” way to undo changes, you can consider git reset as the dangerous method. When you undo things with git reset(and the commits are no longer referenced by any ref or the reflog), there is no way to retrieve the original copy—it is a permanent undo. Care must be taken when using this tool, as it’s one of the only Git commands that has the potential to lose your work.

It should only be used to undo local changes—you should never reset snapshots that have been shared with other developers.

git reset <file>

Remove the specified file from the staging area, but leave the working directory unchanged. This unstages a file without overwriting any changes.

git reset <commit>

• git reset --soft <commit>
  Does not touch the index file nor the working tree at all (but resets the head to

• git reset --mixed <commit> AKA git reset <commit> Resets the index but not the working tree

• git reset --hard <commit> Kindof dangerous.Resets the index and working tree. Any changes to tracked files in the working tree since are discarded.

git clean

The git clean command removes untracked files from your working directory.

Rewriting history

git commit –amend

A convenient way to fix up the most recent commit.

git rebase

The main benefit of rebase is to keep a linear working history so it is easier to understand what happened.

git pull –rebase

git rebase -i

Running git rebase with the -i flag begins an interactive rebasing session. Instead of blindly moving all of the commits to the new base, interactive rebasing gives you the opportunity to alter individual commits in the process.