Git Cheatsheet- 7 mins
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.
//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 -s --short
git status -b --branch
git status -u --untracked-files
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.
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.
move or rename a file/directory/symlink
$ git diff $ git diff --staged $ git diff --cached $ git difftool
//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 -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
$ 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
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 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
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 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
Reverting is a “safe” operation since it doesn’t change the project history.
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
The git clean command removes untracked files from your working directory.
git commit –amend
A convenient way to fix up the most recent commit.
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.