What is git?
Git is a widely used version control system for software development. It is a distributed revision control system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005 [1].
For those of you who don't know the basis of version control, refer to this video to learn about the basis:
For those of you who know the basis of version control but want a quick introduction to git:
Installing Git
Linux
If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora for example, you can use yum:
$ sudo yum install git
If you’re on a Debian-based distribution like Ubuntu, try apt-get:
$ sudo apt-get install git
For more options, there are instructions for installing on several different Unix flavors on the Git website.
Mac
There are several ways to install Git on a Mac. The easiest is probably to install the Xcode Command Line Tools. On Mavericks (10.9) or above you can do this simply by trying to run git from the Terminal the very first time. If you don’t have it installed already, it will prompt you to install it.
If you want a more up to date version, you can also install it via a binary installer. An OSX Git installer is maintained and available for download at the Git website.
You can also install it as part of the GitHub for Mac install. Their GUI Git tool has an option to install command line tools as well. You can download that tool from the GitHub for Mac website.
Windows
There are also a few ways to install Git on Windows. The most official build is available for download on the Git website. Note that this is a project called Git for Windows, which is separate from Git itself.
Another easy way to get Git installed is by installing GitHub for Windows. The installer includes a command line version of Git as well as the GUI. It also works well with Powershell, and sets up solid credential caching and sane CRLF settings. You can download this from the GitHub for Windows website. Make sure you use the bash version of Git for this class, to completely learn the basis.
Setting computer up to use the archive
Configurating SSH
The first thing we need to do is to obtain the keys for the archive you want to use, which in this case are distributed by Neil via email to the accepted students. This will contain two files: classes and classes.pub. The former being the private key and the latter being the public one. We now need to place them in a logical directory located in ~/.ssh/keys. Let's first check that the directory exists:
$ ls ~/.ssh/keys
If the directory doesn't exist, you can create it by using the following command:
$ mkdir ~/.ssh/keys
Now that we have the folder created, copy the archive keys you're going to use into the folder. You can do this in many different ways. The simplest is probably to open a finder window and drag and drop the key files into the folder. Because folders that start with a . are hidden folders on UNIX operating systems, you can use the command line to open the finder to the correct location:
$ open ~/.ssh/keys
Alternatively, you can use the copy command to copy the correct files. Remember you can use wildcards like * to copy multiple files at once
Key file permissions
As discussed in the SSH overview above, we need to make sure the keys have the correct permissions set, otherwise it represents a risk and SSH won't let you connect to the archive. Let's check the permissions of the files in the Keys folder:
$ ls -la ~/.ssh/keys
Permissions for the .pub key(s) should be:
$ -rwxr-xr-x
and permissions for the private key file(s) should be:
$ -rw-------
This is unlikely to be the case right out of the box. So type the following commands to respectively change the public files in the folder:
$ chmod u+rwx *.pub
$ chmod go+rx *.pub
$ chmod go-w *.pub
and the private file of interest, in this case classes:
$ chmod u+rw classes
$ chmod go-rwx classes
Cloning the class archive
Now that we have the SSH keys configured correctly, we need to clone the archive to our local computer. First let's create a config file to create an alias for a host 'fabclasses' so that it is easier to refer to when we want to clone our repo. Create a file config in .ssh folder, and copy the following code (make sure the code is correctly indented, otherwise it won't work).
host fabclasses
hostname fab.cba.mit.edu
user git
user git
port 846
identityfile ~/.ssh/keys/classes
Here, the 'host fabclsses' is an alias that tells the command using it as a reference, that it refers to hostname 'fab.cba.mit.edu' with port '846', etc. This is where our repos are stored.
Let's clone our repo now. Open the terminal (git bash on Windows), navigate to the folder where you want to clone your repo, and type one of the following commands based on the section you're in:
git clone fabclasses:classes/863.15/section.Architecture
git clone fabclasses:classes/863.15/section.CBA
git clone fabclasses:classes/863.15/section.Harvard
Note that this is an example for How to make (almost) anything class, year 2015. You would need it to change it for your corresponding year.
Pulling from the archive
This one is easy. The command is below.
git pull
A good config option to note is:
git config --global pull.rebase true
This eliminates the most common merge, which is two people doing unrelated development on the same branch.
Adding and committing changes
Show the current status of your local archive
The first thing you need to do when adding changes to the archive is to check the status of the archive using the following command:
git status
This would give you the breif summary of the situation and will tell you which changes are unstaged, and which files are ready to be commmitted etc.
Adding files
In this case, I recently created this index.html page, and want to include it in the next commit. To do that, I use the command below:
git add people/jain/index.html
Re-running the status command should now show that the file will be added to the next commit:
Changes to be committed:
modified: index.html
Changes not staged for commit:
modified: about.html
If I wanted to add all the files that I've changed in one go, I can use the command:
git add -A
Re-running the status command:
Changes to be committed:
modified: index.html
modified: about.html
Committing
Once you have selected the files that should go into your commit, you can commit your version by using the following command:
git commit -m "Your commit message"
Try to be descriptive in your commit message, it will be extremely helpful when you have to look back and understand what was done.
Merging
Merging occurs when you have two parrallel branches of development that need to be unified. This often happens when you have been offline (aka haven't pulled and updated your archive) in a while and changes have been made in parallel. Sometimes, these changes will conflict with eachother and you will need to actively choose which changes to keep and which you throw.
In order to merge your changes into the current head commit type:
git merge
Pushing to the archive
Pushing to the archive uploads your commit history to the server. This means that you can make intermediary versions as you go along, even if you can't reach the server. Once you restore your ability to connect to the git repository server, you can upload your changes using:
git push
Useful tips
For an extensive tutorial on git, my recommendation is git-scm.com.
For a very nice spoon feeding tutorial, visit danielmiessler.com. Thanks Ani for this incredible find.
References
- Git (software). Wikipedia, the free encyclopedia. Accessed Oct 2015
- VSC Tutorial. Charles Fracchia, MAS863.14. Accessed Oct 2015