Info Visualization | Evan Cohen

Relationship Displays

Breanching and Merging

Repationship Display

Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS (Version Control Systems) tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects, but with Git it's simple!

Rebasing

Repationship Display

Rebasing is very similar to merging, but with rebase you can take all the changes that were committed on one branch and replay them on another one.

Revised

Critique 1

It's a little tricky to figure out what I'm looking at. The only reason I know is that I am familiar with GitHub and the way that version control works. That said, you need to have a key. I can't figure out what is happening here and in what order, only that there are arrow pointing to past commits. I like that you have different colors for merging and rebasing.

Changes made baised on critique: Using a dynamic key to describe contextual content.

Critique 2

Text size under commits is a little small. Add icons for basic, undo combine, etc. (Put a border arround them). Add an arror that points to the git terminal when you select something.

I'm really not sure what is going on with these arrows...

Changes made baised on critique: Removed arraows - nobody understands them.

Critique 3

This doesn't really reflect your color model like your other work.

This is going to need to have a title, or some kind of key to describe what is going on. Show some kind of visual connection from the rebased branch to the applied branch. Maybe turn it so the head is at the bottom. Should be going down as you commit!

Changes made baised on critique: Emulated my models!!!

Final Relationship

After making sure the functionality was right, I set on the task of making sure it emulated all of my modles.

To get started, select an option from above

Why not start with git commit?!

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 hearts 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 hearts 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.