ISU Bootcamp Git Tutorial

Outline

  1. Git Inroduction and Working Locally (slides)
  2. Working with Github (slides)
  3. Branching and Merging (slides)
  4. Extras

Exercise 1: Download and Install Git

Please download and install Git before the tutorial today.

Windows

Install Git Bash. This give you Bash as well as Git.

MacOSX

Download the graphical Git installer from the Google Code page.

Unix

If you are on a Debian-based distribution like Ubuntu, try apt-get:

$ apt-get install git

If you're on Fedora, you can use yum:

$ yum install git-core

top


Exercise 2: Configure Git and Initialize Repository

Configure Git

The first time we use Git on a new machine, we need to configure a few things:

$ git config --global user.name "Your name goes here"
$ git config --global user.email you@yourdomain.com
$ git config --global core.editor vim
$ git config --global color.ui auto

Git commands are written git verb, where verb is what we actually want it to do. In this case, we're telling Git:

  • our name and email address,
  • what our favorite text editor is,
  • to colorize output, and
  • that we want to use these settings globally (i.e., for every project),

The four commands above only need to be run once: Git will remember the settings until we change them. Once Git is configured, we can start using Git.

Check your configuration with:

$ git config --list

Initialize a Git Repository

Create a folder called git_tutorial and initialize an empty git repository:

$ mkdir swc_git_tutorial
$ cd swc_git_tutorial
$ git init

if we use ls -a to see hidden files, we can see the git has created a hidden directory called .git:

$ ls -a
.  ..  .git

This directory stores information about our project in this directory. If you ever delete it, you will lose the history of your project.

top


Exercise 3: Working Locally with Git

This is a great interactive Git cheatsheet to figure out what commands to use for what you want. It will be overwhelming right now! Stick to the workspace, index, and local repository (we will talk about the upstream repository soon)!

  1. Create an AUTHORS.md file, a TODO.md file, and a README.md file in the swc_git_tutorial directory you created in the last exercise.
    • Hint: Remember the touch command.
    • .md is just markdown extension (makes later exercises easier)
  2. Add your name to the AUTHORS.md file and add it to the staging area.
  3. Check the status of the repository.
    • Notice that there are 'untracked' files in the directory. Remember, this means Git has not been told to keep track of them.
  4. Commit your changes to the repository. Make sure to use an informative commit message!
  5. Add your email to the AUTHORS.md file.
  6. Add the AUTHORS.md, TODO.md, and README.md files to the staging area.
  7. Check the status of the repository.
    • Notice that it specifies that files are new or modified from a previous version.
  8. Commit your changes to the repository.
  9. Change the name of the AUTHORS.md file to CONTRIBUTORS.
  10. Check the status of the repository.
    • If you changed the name outside if Git, Git thinks you deleted AUTHORS and let's you know there is a new untracked file.
    • In order to make sure Git keeps track of the changes to this file, we should rename the file in git using git mv. This works just like the mv command in the shell, but it also let's Git keep track of the move.
  11. Rename the AUTHORS file to CONTRIBUTORS using git mv command.
    • Note: You will have to first rename the CONTRIBUTORS file back to AUTHORS in your working directory.
  12. Commit the name change to the repository.
  13. Add "1. Learn Git" to the TODO.md file.
  14. Add the TODO file to the staging area and commit it.
  15. Add "2. Forget Git" to the TODO.md file.
    • Uh-oh, you realize you didn't actually want to change this file (you don't want to foget Git!) and want to revert it back to the staged file.
  16. Use Git to discard your latest changes to the TODO.md file.
    • Hint: You can discard your changes with the git checkout command. The status message will tell you how to do this.
  17. Look at the change history in your repository using git log.
  18. How would you view the last change made to the TODO.md file? * Hint: git diff!
  19. What about the last change made to the AUTHORS.md file when you added your email?

top


Exercise 4: Work with a Remote Repository

  1. Go to github.com and create an account.
  2. Make a new repository on Github a title it swc_git_tutorial.
    • Don't add a README, LICENSE or .gitignore file this time - we are going to push our exisiting repository.
  3. Add the repository you just made as a remote called origin to your local repository we made in the previous exercise.
  4. Push your local repository to Github.
    • Note: Github tells you how to do this after making your repository.
  5. Look at the files you pushed to Github.
    • Notice all of the commit history from your local repository is maintained.
  6. Edit the TODO file on Github. Add "2. Learn Github".
  7. Commit the file to the repository.
  8. Fetch the changes you made on the remote repository and merge them into your local repository.
  9. Check the status of the repository.
  10. Inspect the TODO file and view the changes.

top


Exercise 5: Collaborate on Github

For this exercise we will work in groups of four.

  1. One person in the group create a remote repository on Github called "swc_ex5".
    • This time you can let Github make the README, LICENSE, and .gitignore files.
  2. All other members of the group FORK that repository on Github.
  3. Everyone CLONE a copy of either the original or forked repos onto their local machines.
  4. What remote repositories have already been set up for each of you?
    • Hint: git remote -v
  5. Everyone add a file to the repository titled with their first name and a short sentence about themselves.
  6. Add and commit the file to your repository.
  7. Push your file to your remote repository.
    • Hint: git push origin
  8. Everyone that forked the original repository send pull requests.
  9. The member who made the original repository should merge all pull requests into the original repository.
  10. Everyone fetch all of the changes from the original repository and merge them into their local repository.
    • Hint: git fetch upstream/master, git merge upstream/master - how would you do this if you wanted to fetch a branch called 'fixes'?
    • Note: You can also do a git pull upstream master. This will fetch and merge in one command (as long as you stick with this naming convention).
  11. Add one line to the README.md that says what their favorite thing about version control is so far.
  12. The group member that created the original repository should add, commit, and push this change to the remote repository. (Everyone else sit tight).
  13. All other members should now try to fetch and merge the upstream repository into their local repository.
    • Did it go smoothly?
    • What went wrong?
    • How do you fix it?

Extra time? Check out this cool interactive demo for learning branching with Git.

top


Resources for Learning Git

  1. Git
  2. Branching
  3. SSH Keys

top