What is Version Control?

What is Version Control?

VCS Info

There are a number of Version Control Systems out there. This alone should prove that version control is incredibly important. Three of the most popular version control systems are :

• Git
• Subversion
• Mercurial

There are two main types of version control system models :

• the centralized model — all users connect to a central, master repository
• the distributed model — each user has the entire repository on their computer

Further Research

• Centralized vs. DVCS from the Atlassian Blog
• Distributed version control on Wikipedia

Terminology

Version Control System / Source Code Manager

A version control system (abbreviated as VCS) is a tool that manages different versions of source code. A source code manager (abbreviated as SCM) is another name for a version control system.

Git is an SCM (and therefore a VCS!). The URL for the Git website is https://git-scm.com/ (see how it has “SCM” directly in its domain!).

Commit

Git thinks of its data like a set of snapshots of a mini filesystem. Every time you commit (save the state of your project in Git), it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. You can think of it as a save point in a game — it saves your project’s files and any information about them.

Everything you do in Git is to help you make commits, so a commit is the fundamental unit in Git.

Repository / repo

A repository is a directory which contains your project work, as well as a few files (hidden by default on Mac OS X) which are used to communicate with Git. Repositories can exist either locally on your computer or as a remote copy on another computer. A repository is made up of commits.

Working Directory

The Working Directory is the files that you see in your computer’s file system. When you open your project files up on a code editor, you’re working with files in the Working Directory.

This is in contrast to the files that have been saved (in commits!) in the repository.

When working with Git, the Working Directory is also different from the command line’s concept of the current working directory which is the directory that your shell is “looking at” right now.

Checkout

A checkout is when content in the repository has been copied to the Working Directory.

Staging Area / Staging Index / Index

A file in the Git directory that stores information about what will go into your next commit. You can think of the staging area as a prep table where Git will take the next commit. Files on the Staging Index are poised to be added to the repository.

https://www.youtube.com/watch?v=dVil8e0yptQ

 

SHA

A SHA is basically an ID number for each commit. Here’s what a commit’s SHA might look like: e2adf8ae3e2e4ed40add75cc44cf9d0a869afeb6.

It is a 40-character string composed of characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. “SHA” is shorthand for “Secure Hash Algorithm”. If you’re interested in learning about hashes, check out our Intro to Computer Science course.

https://www.youtube.com/watch?v=rFtUkk-sCqw

 

 

Branch

A branch is when a new line of development is created that diverges from the main line of development. This alternative line of development can continue without altering the main line.

Going back to the example of save point in a game, you can think of a branch as where you make a save point in your game and then decide to try out a risky move in the game. If the risky move doesn’t pan out, then you can just go back to the save point. The key thing that makes branches incredibly powerful is that you can make save points on one branch, and then switch to a different branch and make save points there, too.

Installing Git

Git is actually installed on MacOS, but we’ll be reinstalling it so that we’ll have the newest version:

1. go to https://git-scm.com/downloads
2. download the software for Mac
3. install Git choosing all of the default options

Once everything is installed, you should be able to run git on the command line. If it displays the usage information, then you're good to go!

Configuration Steps

To configure the terminal, we’ll perform the following steps:

1. download the zipped file from the Resources pane, or the bottom of this page
2. move the directory udacity-terminal-config to your home directory and name it .udacity-terminal-config (there's a dot at the front, now!)
3. move the bash_profile file to your home directory and name it .bash_profile (there's a dot at the front, now!)

• if you already have a .bash_profile file in your home directory, transfer the content from the downloaded bash_profile to your existing .bash_profile

https://www.youtube.com/watch?v=h00n9QLfbqU

 

First Time Git Configuration

Before you can start using Git, you need to configure it. Run each of the following lines on the command line to make sure everything is set up.

# sets up Git with your name
git config --global user.name "<Your-Full-Name>"

# sets up Git with your email
git config --global user.email "<your-email-address>"

# makes sure that Git output is colored
git config --global color.ui auto

# displays the original state in a conflict
git config --global merge.conflictstyle diff3

git config --list

Git & Code Editor

The last step of configuration is to get Git working with your code editor. Below are three of the most popular code editors. If you use a different editor, then do a quick search on Google for “associate X text editor with Git” (replace the X with the name of your code editor).