DPS909 & OSD600 Winter 2017 - Git Walkthrough 2

Git Walkthrough: Working Remote

In the previous walk-through, we looked at the basics of using git for revision control. This time we we'll learn how to use git in a distributed workflow, and how to interact with remote repositories, such as those on Github.

Step 1: Using Git with Github

For this walkthrough, we'll need an account on Github. Think of a Github account like a driver's license: it's what allows you to participate in many open source projects. If you haven't done so before, take a few minutes to do the following:

1. create an account
2. verify your email address
3. consider enabling two-factor authentication
4. add info to your account bio
5. consider changing your profile picture

We'll also need to do a bit more setup with git. Specifically, we need to set some global config options, SSH keys, etc:

1. set your username locally
2. set your email address locally
3. set your line endings
4. consider setting other global defaults while you're at it (e.g., your default editor)
5. set up SSH keys

Step 2: Clones and Forking

Git is a distributed revision control system, which means that unlike client/server systems, git has no concept of a central server that we work against. Instead, everyone who works on a repository first creates his or her own copy. If I want to work with a repository that you made, my first task is to make my own personal copy, then work on that directly.

Git calls this copy of a repository a clone. One of the great advantages of having your own local clone of a repository is that you don't need a network connection in order to work with it (i.e., everything is local), and you have complete control over everything you do (i.e., you don't need permission to commit changes). Cloning a repository copies every commit and version of every file in the original project's history. As a result, git clones can take a lot of disk space.

Every git developer works directly with his or her own local clone of a repository, then uses a combination of git's push and pull commands to sync their work with remote repositories--we'll do this below. Because its so common to want to share our local repositories with one another, and to clone each other's repositories locally, we use Github as a public host.

It's possible with git to clone repositories from a USB key, or copy entire repos across a shared drive. But it's not realistic to do this with people on the other side of the world. Instead, it's more convenient to use the Internet and a shared hosting platform.

Every Github user can have an unlimited number of open source repositories (private/closed source repositories cost money). Because the default workflow with git is to clone a repository before we use it, Github includes this as a central feature, which it calls forking.

What Github calls a fork is really just another name for a clone. You'll see both fork and clone used on Github, and you can think of the difference this way:

• fork: copy an existing Github repository to your Github account. This forked copy will live on Github's servers, but you will have full ownership over it. It's typical to fork any repository to which you want to contribute.
• clone: create a local copy of a repository on Github on your computer. It's typical to clone repositories that you have previously forked.

Let's fork a repository. Follow the instructions in Fork a Repo to fork the Spoon-Knife repository.

While we're at it, let's also fork the Bootstrap repository, so we can carry on with things we were trying in our earlier walkthrough.

Step 3: Cloning a Forked Repository

Now that we have a forked copy of the Spoon-Knife repository, let's clone it to our local computer. In order to clone a Github repository, we need an appropriate URL. NOTE: this is not the URL we use to access the repository in our web browser. Rather, we need a git URL.

Github provides git URLs using various protocols. The one we'll use most often is the SSH URL. To get an SSH URL for a Github repository, you need to have the appropriate rights (i.e., both read and write permissions). Every repository that you fork will automatically have these rights.

In my case, the URL I need is git@github.com:humphd/Spoon-Knife.git, and for you it will be git@github.com:{your-github-username}/Spoon-Knife.git. Using this SSH URL we can clone the repo locally:

$ git clone git@github.com:humphd/Spoon-Knife.git
Cloning into 'Spoon-Knife'...
remote: Counting objects: 16, done.
remote: Total 16 (delta 0), reused 0 (delta 0), pack-reused 16
Receiving objects: 100% (16/16), done.
Resolving deltas: 100% (3/3), done.

This did a few things:

1. created a directory ./Spoon-Knife/
2. created a .git/ database folder in ./Spoon-Knife/.git
3. downloaded all commits in the forked repo from Github, saving them to our ./Spoon-Knife/.git database
4. created remote tracking for the origin repository (i.e., our forked repo on Github, from which we cloned)
5. checked-out the latest version of the code to our ./Spoon-Knife/ working directory

• Client Server (SVN) and Distributed (Git)
• Snapshots vs. versioned files.
  • Walkthrough -
  • Checksums, SHA-1 (try online)
  • Starting a Git Repo:
    • git init
    • git clone
  • File States:
    • Untracked (not known to git)
    • Tracked: modified, staged, committed
  • The staging area
• Basic Git Commands and Concepts
  • git help <command>
  • git add
  • git commit, git commit -m, git commit -a
  • git rm
  • git mv
  • git status
  • git log
  • git diff, git diff --staged
  • .gitignore
  • Branches
    • HEAD, master
    • git checkout, git checkout -b
    • git branch, git branch -a, git branch -d, git branch --merged, git branch --contains
    • git merge
    • git rebase
  • Remotes
    • origin, origin/branch
    • git remote
    • git remote add
    • git fetch
    • git pull
    • git push
  • Github, Pull Requests