An Introduction to Git and GitHub

Git vs. SVN

SVN is centralized SCM (Source Control Management). Everyone pushes and pulls from the server. Server goes down, everyone is down.

Git is decentralized — everyone’s local copy is a fully-functional copy of the repository. If the main Git host explodes, you can move to another host in minutes, or just work and commit locally.

Branching and merging are advanced (and potentially dangerous) techniques in SVN — in Git they’re simple and easy, part of your everyday process.

HEAD in SVN is simply the latest revision — In Git HEAD is where your working branch is currently located; you can move around dynamically to any point in the history.

Basic Git

Create a Repository

git init: Creates a new repository in the current directory.

git add: Stages files you’ve created, modified, or deleted to be committed.

git commit: Commits the files you’ve staged with a message.

Adding a Remote, Pushing Code

git remote add:Adds a remote with a given name and URL. Add as many as you need.

git remote (-v):List the remotes we’ve added.

git push/pull (remote) (branch):Push code to and pull from a remote copy of the repo.

Clone an Existing Project

git clone repo-url (directory-name):Now that the repo is made and on a public server, share it with your team — they clone their own local copy of your work to-date.

Branching and Merging

git branch branch-name (branch-from-where):Creates a new branch at the current point, or a point you specify.

git checkout:Switch branches.

git merge another-branch:Merges another branch into the current branch. Use the “no-ff” flag to keep branching history.

.gitignore

With a .gitignore you can specify files for git to… ignore. This is great for cache files, generated code (minconcat, etc.).

Like an .htaccess it works for all children files and directories.

You can specify global ignores for things that you’d never want to version, like DS_STORE and other system files. https://help.github.com/articles/ignoring-files

Branching Structure

Based largely on this excellent post by Vincent Driessen:http://nvie.com/posts/a-successful-git-branching-model/

What does a successful branching plan look like?

We consider the main branches to be develop and master.

From develop, we can create branches for specific features, merging them back into develop as we finish.

When tasks are complete, we create a release branch to prepare a candidate build — bugfixes and the like would go here. Once QA has approved the release, we merge the release into master and tag it.

Hotfixes are branched from master and merged into develop / master on approval.

Walkthrough

Let’s walk through a hypothetical project with developers Jane and John, and Tech Lead Frank.

Feature Branching

Jane starts by branching develop into feature-foo.

Merging back to develop

Once she’s finished her feature, she merges the branch into develop with the no-ff option to preserve her branch’s history.

Merging features, con’t

Meanwhile, John has finished his feature. He checks out develop, pulls down Jane’s work, then merges his branch.

Success!

The result looks like this — note that using no-ff preserved the history of both feature branches’ commits.

Preparing a Release

Frank’s cool with those features, so he forks develop into release-v0.2. QA kicks back a few bugs, which are addressed in this branch.

Merging into Master, Tagging

QA clears the release, so Frank merges the release branch into master, then tags it.

Deleting Branches

Now that v0.2 is released Frank deletes his local branch, and the branch on origin.

Note the syntax for deleting a remote branch:git push origin :branch-name

More Success!

What the tree looks like after the release:

Hotfix Branching

QA finds a critical bug on production, so Frank creates a hotfix branch off of master.

Merging the Hotfix

Frank’s fix looks good, so he merges it back into develop and master, then tags it as v0.2.1

Even More Success!

Here’s the tree reflecting Frank’s hotfix:

GitHub

GitHub

A solid, sharable front-end UI for repo management. @user mentions, subscriptions, inter-project

references. Inline code commenting. Ease of sharing code, commits, and anything

else pertaining to your project.

Gives the option to use a central-server model (as seen in the branching walkthrough) or a blessed/lieutenant model to manage code reviews, complex features, etc.

Creating a Repository

Adding Users

In the admin panel, you can specify which groups have access to your project.

Forking

A developer creates a fork of the “blessed” repository, which is their working environment.

Switching Branches

Once you push a feature branch to your fork, you can switch to it to compare the changes you’ve made, add comments, or open a pull request.

Commenting

If I want to open a discussion around a particular piece of my commit, I can comment inline.

Opening a Pull Request

Once your feature branch is ready, open a Pull Request by specifying what you’d like to merge. In my case I’d like to merge feature-foo into develop.

Submitted for Review

Now that I’ve submitted my request, the project lead can code-review my commit before merging it into the blessed repo’s develop branch.

Labels and Assignments

For complex projects labels help organize what needs to be reviewed, what has been reviewed, and what needs more work.

Assignees also make it easy to delegate review responsibilities to other team members, or a dev on another project that has time to help out.

Adding code to the PR

If I need to add more code, I simply push to my fork’s feature branch to add to the pull request.

Approving a Pull Request

If all looks good, the project lead can approve the changes and merge the code into develop.

Success!

More GitHub Information

More about GitHub’s markdown syntax: http://github.github.com/github-flavored-markdown/

A great talk on “secret” features in GitHub: http://www.youtube.com/watch?v=Foz9yvMkvlA

Getting started articles: https://help.github.com/categories/54/articles

Using Git with SVN

If you’re on a legacy SVN project, you can still use Git with the git-svn module (built in with standard Git installs).

Cloning: git svn clone repo-url

For very large repos, use the –r flag to only grab a set number of revisions: git svn clone -r1600:HEAD repo-url

Locally, you can work with regular Git — add / commit / branch / etc.

To svn ci run git svn dcommit — This will push your local commits up to SVN individually.

To svn up run git svn rebase — This will pull remote changes to your local.

More info: http://git-scm.com/course/svn.html

Git GUIs

Mac: SourceTree

Free.

Works with SVN, using git-svn.

http://www.sourcetreeapp.com/

Mac: Tower

Needs a license

Also works with SVN via git-svn

http://www.git-tower.com/

Win/Mac: GitHub Client

Free

Simple UI — optimized for GitHub repos but will work with any remote.

Does not support multiple remotes.

http://mac.github.com http://windows.github.com

Windows: Git Extensions

Free

http://code.google.com/p/gitextensions/

Or just make CLI prettier.

To get nice logs like the ones earlier in the presentation (using git lg –all, etc.), check out: http://www.jukie.net/bart/blog/pimping-out-git-log

All colors are customizable — here’s a quick way to enable automatic colors: http://faizanshaharyar.com/enabling-colors-in-git-command-line-interface

Autocompletion for branches, and more enhancements:http://en.newinstance.it/2010/05/23/git-autocompletion-and-enhanced-bash-prompt/

Other Resources

Git Project Homepage: http://git-scm.com/

15 Minutes to learn Git — Interactive Tutorial: http://try.github.com/levels/1/challenges/1

Git Cheatsheet: http://byte.kde.org/~zrusin/git/git-cheat-sheet-medium.png

Converting an SVN project to Git: http://john.albin.net/git/convert-subversion-to-git

A great walkthrough on making a self-hosted Git repo: http://kb.mediatemple.net/questions/1594/Using+Git#gs

Confluence Article on GitHub and Project setup: https://confluence.cpbgroup.net/pages/viewpage.action?pageId=6554387