Last Updated on
This is a collection of git commands (for use in terminal windows like Terminal, xterm, putty, etc) that I use and need to keep handy. I have categorized the list by task/problem type. This list does not pretend to be complete or authoritative. If you are looking for the complete reference and manual, you should go to the official documentation.
If you have any suggestions or corrections for my list, please let me know.
Get out of trouble – Undo commits – Restart with a Clean Slate
git reset ‐‐hard
- Resets tree and index to HEAD, discards changes to tracked files. SEE DOC
git reset --hard origin/[branchName]
- This one is great. If you’ve made some bad commits or merges and just want to start over with a clean version from the origin, this will do it for you.
git reset ‐‐soft HEAD~
- Undo a commit but leave existing changes staged. SEE DOC
git revert filename.php
- This reverts local changes in file, back to the original version that was committed.
Start a New Project
- Create a new git repository in the directory you are already in. SEE DOC for recipe for making a new repo from existing code.
git config ‐‐global user.email "[email protected]"
- This is used once at the beginning when setting up your local repo, git seems to need it to push changes back to a remote repo.
git config ‐‐global user.name "John Doe"
- ditto above
git clone [email protected]:path/on/remote/server/from/homedir/to/repo/
- This copies your remote repo to your local dev machine. This is what you do to get started on local development.
GIT_SSL_CAINFO=~/pathToSSL/certChain.pem git clone https://useremail%[email protected]/path/on/remote/server/to/repo.git
- Use this when you are cloning a repo and getting this error: “SSL certificate problem: self signed certificate in certificate chain”. After cloning the repo this way, be sure to cd into the repo, and then do:
“git config http.sslCAInfo ~/pathToSSL/certChain.pem”
This last command will ensure that future git operations on this repo (like push/pull) have the necessary cert chain.
The Daily Grind – Committing, Merging, Updating, etc.
git commit -m'message'
- This commits all staged changes with a message (m).
git add -A
- This adds all new files, and any new changes to existing tracked files, and any file removals, from the working tree to the index, for eventual committing.
- This pushes the latest commits from my local machine repository into the repo’s remote origin.
- This pulls the latest changes from my remote repository into my local machine repository.
git pull --no-commit
- Same as above, but does not commit the merge result that happened from the pull.
git checkout branchname
- This switches your local repository from one branch to the branch called branchname.
git checkout commit-hash
- This checks out the repo at a particular commit, which is very handy for debugging your code ( as in: “but it worked at this commit-hash…”)
git checkout -b newbranchname
- This creates a new local branch from your current branch, and switches to it.
git merge branchname
- This merges branchname into your current branch. If the merge goes well, the changes are automatically committed to your current branch.
git push origin newbranchname
- This pushes your new branch that you created only on your local machine up to your origin repository.
git checkout -m 339c91e filename
- If you do git fetch first, and then git branch -v on the remote branch you just fetched from to learn the hash of the latest commit, you can then run this command, which updates just a single file (filename) with the version that is in the commit hash.
git clean -df
- Removes untracked files from the working tree. SEE DOC
git rm --cached dirname/filename.ext
- This command is used to remove a file from the git index. The scenario that I used it for was to remove a file from git that was being tracked, even though I had added the filename to the .gitignore list. I had first mistakenly added the file to the git index. I then realized that I did not want it tracked. So I added the file to the .gitignore list. But then it was still being tracked. So I had to run this command on the file.
git branch -D branchname
- deletes that branch. Capital -D causes the branch to be deleted irrespective of its merged status.
git rebase -i HEAD~4
- Squash the last 4 commits into one. When the 4 commits come up in the editor, change the bottom 3 (the 3 most recent) to ‘squash’. You’ll have a chance to edit the new single commit message in the next editor window. Then use “git push -f” to force push the single commit to the origin repo. SEE DOC
- This diffs your local branch from its committed state. Useful to remember what you’ve changed.
- Among other things, this tells you what new files are not yet tracked.
git branch -v
- Tells you what branch you are on, the hash of the last commit, and that commit’s message.
# commit just by USERNAME on October 3, 2019, printing only the commit message/subject git log --oneline --after=10/02/2019 --until=10/03/2019 --author=MYUSERNAME --pretty="-%s" # commits since May 5, 2019 git log --oneline --since=05/05/2019
- Get a nice clean list of commits selected by date
git checkout-index -a -f --prefix=/full/path/to/new/directory/
- This is what you use to export your repo to a new location. This command is very useful to deploy flat files from qa to prod, for example. It takes all of the files in the index (-a) and puts them into the new directory. -f is used to overwrite same-named files in the new directory with the new files coming in from the export. Be sure to put the slash at the end of your path. If you don’t, that ‘directory’ will become a prefix on all of your files. Also, don’t use the ~ shorthand for your home directory. Use your full path from root.
git checkout HEAD path/to/changes/ git pull --no-commit
- You can also use git as a low tech way of fetching code from a repo into a production server. The above commands pull code from a repo into a file system without messing with commit history, or other files not in git in the filesystem.
The github team also maintains a similarly organized cheatsheat which you may find handy: this documentation put together by the github team.