Skip To Content


Using one of the most popular version control systems.

Commands #

git add #

For adding all untracked changes for the next commit

git commit #

For taking all tracked changes and saving them as a single commit. Include the -m option for adding a commit message, as a parameter in quotes.

git show <commit> #

Show the basic metadata of a commit and all the included changes. Just good for seeing what happened in a specific commit.

git reset #

git checkout -f #

If you need to forcibly clear out all changes in the working directory, run this command. Be warned that they'll be gone for good, short of a reflog retrieval.

git pull #

If there's any extra commits on the remote repo you don't have locally, it pulls them down and applies them locally.

If there's a lot of changes that you're worried could conflict with changes you've made locally, git fetch downloads the new commits without applying them to your local code.

git branch #

Create a branch to add commits and new changes, and later merge them into the main branch. This is a great way to add changes freely without affecting a live, or fully accepted, version of the site. You can create a branch off an existing one by:

If you no longer need or want this branch, you can use git branch -d <branch_name> to remove it locally. To remove the branch on a remote repo, you'll need to also run git push <remote_repo> --delete <branch_name>.

Sort through lots of branches #

git branch returns a list of all branches. Some repos will have lots of branches, making finding a specific branch a chore. A good way around this is running git branch | grep <string>. This returns a list of branches that contain that string, making it much easier to narrow them down!

Pull Requests are basically people proposing merging a branch into another one. People can look over all the changes, give feedback, request changes, check tests, and later merge the branch.

git diff #

Shows the changes between the last commit and all untracked changes. Also visualizes whether these changes were adding or reducing code.

git status #

Show all current untracked and unstaged changes, and all tracked and staged changes as well. Great for making sense of large amounts of changes made without a commit.

git log #

Shows a record of all the commits in a repo. Each entry includes the name, date, commit hash, and other basic meta data.

git reflog #

Shows a record of all the commands run for this repo. You can get the ID from any of these and go back. It's basically the "catch all, end all" reset if needed. Accidentally lose changes? Use the reflog to get them before they were lost, stash them somewhere, and keep going.

git mv #

Tracks the renaming of a file in version control. Renaming it by hand can confuse git's tracking (especially if also naming it at same time), so using git mv is a safer bet.

Also when renaming files, unless the renaming breaks something else in the repo, it's best to keep those changes in a separate commit.

git ls-files #

Shows all files in the directory, but limited to ones tracked by git. Can be combined with grep as a way to filter through files in the repo.

git stash #

Takes all untracked changes and "stashes" them away, which mbasically means temporarily removing them. Good for quick operations that can't have untracked files while doing them, like needing to quickly check out a new branch before committing changes in a current one.

Rebasing #

Rebasing it taking a branch that may start from the an older commit of the main branch, and copying them all over to the most recent commit of that branch.

Rebasing onto a new branch #

The above command only works if you're rebasing on the same branch as before. If you want to rebase onto a different branch, use the --onto argument.

git rebase --onto <new_parent_branch> <current_parent_branch> <child_branch>

All the current branches commit will be placed on top of the new branch, and any conflicts will be solved like any other git rebase.

Rebasing - using fixup to autosquash commits #

Some commits may be made solely to be squashed into other ones later on. This can be simplified by making them as fixup commits. These are commits marked specifically to be squashed, and will automatically do so during a rebase.

To set rebases to autosquash by default, run git config --global rebase.autosquash true.

To quickly find a recent commit when running the --fixup option, you can tell get to find the most recent commit with a certain string. This command would be git commit --fixup :/[string]/ Only use this when you know that git will find the commit you're thinking of when starting from the most recent ones and going to the older ones. The more unique a string you use, the more likely this is.

Undoing a rebase #

Using a rebase to split commits #

You may have bulky commits you want to split into several smaller ones, without having to rewrite the code. Rebasing lets you do this.

  1. Set up an interactive rebase with git rebase -i <master_branch>.
  2. On the interactive rebase list, change pick to edit for the commit you want to split.
  3. When editing this commit, run git reset HEAD~. This unstages all the changes from the commit, but still tracks them.
  4. Add the select code you want, commit it, and repeat until all the code has been recommitted in new commits.
  5. Run git rebase --continue.
  6. Repeat steps 3-5 for any other commits you want to split.
  7. All set! Happy dance.