Visualizing Git Concepts

We are going to skip instructing you on how to add your files for commit in this explanation. Let's assume you already know how to do that. If you don't, go read some other tutorials.

Pretend that you already have your files staged for commit and enter git commit as many times as you like in the terminal box.

git branch name will create a new branch named "name". Creating branches just creates a new tag pointing to the currently checked out commit.

Branches can be deleted using the command git branch -d name.

Type git commit and git branch commands to your heart's desire until you understand this concept.

git checkout has many uses, but the main one is to switch between branches.
For example, to switch from master branch to dev branch, I would type git checkout dev. After that, if I do a git commit, notice where it goes. Try it.

In addition to checking out branches, you can also checkout individual commits. Try it.
Make a new commit and then type git checkout bb92e0e and see what happens.

Type git commit, git branch, and git checkout commands to your heart's desire until you understand this concept.

You can combine git branch and git checkout into a single command by typing git checkout -b branchname. This will create the branch if it does not already exist and immediately check it out.

git reset will move HEAD and the current branch back to wherever you specify, abandoning any commits that may be left behind. This is useful to undo a commit that you no longer need.

This command is normally used with one of three flags: "--soft", "--mixed", and "--hard". The soft and mixed flags deal with what to do with the work that was inside the commit after you reset, and you can read about it here. Since this visualization cannot graphically display that work, only the "--hard" flag will work on this site.

The ref "HEAD^" is usually used together with this command. "HEAD^" means "the commit right before HEAD. "HEAD^^" means "two commits before HEAD", and so on.

Note that you must never use git reset to abandon commits that have already been pushed and merged into the origin. This can cause your local repository to become out of sync with the origin. Don't do it unless you really know what you're doing.

To undo commits that have already been pushed and shared with the team, we cannot use the git reset command. Instead, we have to use git revert.

git revert will create a new commit that will undo all of the work that was done in the commit you want to revert.

git merge will create a new commit with two parents. The resulting commit snapshot will have the all of the work that has been done in both branches.

If there was no divergence between the two commits, git will do a "fast-forward" method merge.
To see this happen, checkout the 'ff' branch and then type git merge dev.

git rebase will take the commits on this branch and "move" them so that their new "base" is at the point you specify.

You should pay close attention to the commit IDs of the circles as they move when you do this exercise.

The reason I put "move" in quotations because this process actually generates brand new commits with completely different IDs than the old commits, and leaves the old commits where they were. For this reason, you never want to rebase commits that have already been shared with the team you are working with.

git fetch will update all of the "remote tracking branches" in your local repository. Remote tracking branches are tagged in grey.

A git pull is a two step process that first does a git fetch, and then does a git merge of the remote tracking branch associated with your current branch. If you have no current branch, the process will stop after fetching.

If the argument "--rebase" was given by typing git pull --rebase, the second step of pull process will be a rebase instead of a merge. This can be set to the default behavior by configuration by typing: git config branch.BRANCHNAME.rebase true.

A git push will find the commits you have on your local branch that the corresponding branch on the origin server does not have, and send them to the remote repository.

By default, all pushes must cause a fast-forward merge on the remote repository. If there is any divergence between your local branch and the remote branch, your push will be rejected. In this scenario, you need to pull first and then you will be able to push again.

One simple example of the use of git reset is to completely restore your local repository state to that of the origin.
You can do so by typing git reset origin/master.

Note that this won't delete untracked files, you will have to delete those separately with the command git clean -df.

Below is a situation in which you are working in a local branch that is all your own. You want to receive the latest code from the origin server's master branch. To update your local branch, you can do it without having to switch branches!

First do a git fetch, then type git rebase origin/master!

git branch -d is used to delete branches. I have pre-created a bunch of branches for you to delete in the playground below. Have at it.

Do whatever you want in this free playground.