What is git?

git is a distributed revision control system created by Linus Torvalds in April 2005

History

For a long while, Linux kernel maintenance was done via tarball patches

Linus hated CVS and SVN and didn't see the point of either system

BitKeeper

In the 1990's BitKeeper was discussed as a solution to the Linux teams source control problems

BitKeeper was one of the first distributed revision control systems, and the Linux kernel was it's highest profile Open Source project

Falling Out

BitKeeper was free for OSS as long as developers didn't work on competing systems

BitKeeper's CEO claimed that an OSS developer, Andrew Tridgell reverse-engineered the BitKeeper protocols and violated the license

After much drama, the Linux team stopped using BitKeeper

Development

Alternatives

Linus evaluated Alternatives. They had to be:

• Distributed
• Fast
• Consistent

Alternatives

Linus' requirements eliminated all existing systems

CVS and SVN met none of the requirements

All other distributed systems were either closed, behind a pay wall, or didn't meet the requirements

Initial Release

Linus went home for the weekend, and early next week released the first version of git on April 7, 2005

It took Linus about a day to get git "self hosting", i.e., able to commit changes to git using git^*

The Name

Why call it git

British slang for "an unpleasant person"

"I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."

Design

Step One

Forget everything you know about CVS and SVN

Requirements

Linus designed git to satisfy the requirements he outlined for a version control system that would be suitable to develop the linux kernel

Distributed, Fast, and Consistent

Distributed

Every copy of the repository has a complete history

git keeps track of other repositories that you can "pull" from and/or "push" to. These are called remotes

Because of this distributed model, there were no politics around who could commit and when. Everyone could commit to the Linux kernel all the time. Even offline!

git's branching and merge strategy strongly supports non-linear development

git's intelligent merge strategies rarely result in users having to manually resolve

Fast

There are a number of factors that make git fast, mainly:

• Repositories are local, ∴ most operations don't use the network
• git doesn't track files, it tracks blobs
• Lightweight branches

Consistent

Each version of the repo is identified by a SHA-1 hash that depends on the complete history of the project

Using a cryptographically secure hash algorithm ensures that history can't be modified without git noticing

git ensures by design that you get back exactly what you committed every time

Common Commands

git is built as a toolkit of small c programs stitched together with scripts

git config

git config

Configure git options globally or locally

First git commands are usually:

$ git config --global user.name "YOUR NAME"

$ git config --global user.email "YOUR EMAIL ADDRESS"

git init

git init

initializes a new repository

Creates a .git directory inside an existing directory

.git directories store all the configuration and history for the repo

git clone

git clone

Clone a remote repo and download locally

Clone from github:

$ git clone git@github.com:hakimel/reveal.js.git

git branch

git branch

Create, list or delete branches

Create a branch:

$ git branch BRANCH_NAME

$ git branch -d BRANCH_NAME

$ git branch -D BRANCH_NAME

$ git branch

git checkout

git checkout

Switch between branches

Switch to a feature branch:

$ git checkout FEATURE_BRANCH_NAME

$ git checkout master

$ git checkout -- path/to/file

$ git checkout -b NEW_BRANCH_NAME

git add

git add

Add file contents to the index or staging area

Add a specific file:

$ git add path/to/file

$ git add .

git commit

git commit

Commit changes staged in index to current branch

Launch editor to write commit message and commit on save:

$ git commit

$ git commit -a

$ git commit -v

$ git commit -m "Commit message!"

git fetch

git fetch

Fetch changes (new commits, branches, tags, etc.) from a remote but don't merge

Fetch from remote origin:

$ git fetch origin

git status

git status

Check the status (modified, staged, deleted, etc.) of files in the working copy

$ git status

git log

git log

Show commit history of this branch

Just show a history of commits on this branch:

$ git log

$ git log --author=user@domain.com

$ git log --graph

git merge

git merge

Merge changes from a branch to current branch

Merge changes from a feature branch:

$ git merge FEATURE_BRANCH_NAME

git pull

git pull

Perform a fetch and then a merge in one step, more common than fetch or merge alone

Pull changes from a remote master branch at the origin:

$ git pull origin master

git push

git push

Push a branch to a remote, creating the branch if it doesn't already exist

Push a feature branch to the origin:

$ git push origin FEATURE_BRANCH

You can set other remotes to push to and pull from, but that is outside the scope of this talk and not very common outside of OSS

Got all that?

Reccomended git workflows

Online Hosting Services

Much to Linus' chagrin, most people find value in using an "official" hosted repository, but the most common workflows aren't too different from his ideal

Github

BitBucket

Common Workflow Types

Centralized Workflow

Forking Workflow

Centralized Workflow

Similar to the workflow of CVS or SVN

Everyone on the team has read and write access to the official hosted repository

A branching strategy is usually employed and team members open pull requests against the master branch

Forking Workflow

Most similar to Linus' ideal distributed workflow

Project owner/maintainer(s) manage the official repo

Team members fork the official repo and have their own hosted versions that they develop on

When team members want changes to make it in to the official repository, they open a pull request against the official repository

The maintainer(s) will review and merge the branch or reject it

Branching Strategy

Three branches: master, test, dev

Branching Strategy ctd.

dev

Where active development happens. Developers make feature branches off of dev

test

Stable pre-release branch. Used for product verification

master

Main production branch. Should always be error free and able to be deployed.

Feature Branching

As was said before, git's branches are super lightweight

A branch is just a pointer to a commit

Create branches off of the dev branch to do edits and merge feature branches back into dev

Homework

try.github.io

Pro Git

Atlassian Tutorials

This is a fantastic git resource. In depth, easy to read tutorials on all the major features of git

• Getting Git Right (Home)
• Git Getting Started Tutorials

Git Submodules

Out of Scope for this talk

I don't like them. Though I understand that sometimes they can make repo organization easier (though they usually end up making it worse)

Here's a link to the submodule chapter of Pro Git for you to read later