git and githubdarren oakley

disclaimer

• i use git daily in my work and manage to not have many problems

• i’ve been asked to share the basics i know with others

• i am not a git expert - i may (most probably) not be able to answer all of your questions

what we’ll cover

• brief discussion on version control - ‘traditional’ v’s distributed

• git - the basics

• github - the basics

what we won’t cover

• advanced git

• rebase

• sub-modules

• git-svn

version control

version control

• what most people are (probably) used to:

• concurrent version system (cvs)

• subversion (svn)

version control

• cvs and svn

• central source control server

• users check code into server

• requires connection to the server to perform commits, updates etc.

distributed version control

• the new hotness...

• git

• mercurial (hg)

• bazaar (bzr)

what’s the difference?

• not a lot really...

• you store a complete copy of a repository within your working copy

• this means you can work offline

• there is no default ‘central’ server - if you want one, you (and your team) just nominate where it is (i.e. a github)

git

getting started

• move to a directory with code you’d like to manage with git:

git init

• you’ve now created your first git repository!

normal workflow

local operations

working directory

stagingarea

git directory(repsoitory)

checkout the project

stage files

commit

staging files

git add [filenames]

• add all changed files to the staging area:

git add .

• these changes are NOT committed yet

the git staging area

• git has a concept of a ‘staging area’

• you first stage all of the changes that you are happy with

• then you commit them

isn’t this more work?

• in short - yes

• but it allows you to craft the exact commit you want - you eventually get to love this feature

• you can get around it if you like...

committing

git commit -m “commit message”

git commit -a -m “commit message”

branching / merging

branching

git branch

git branch [new branch name]

git checkout [new branch name]

merging

git checkout [target branch]

git merge [other branch]

git merge --squash [other branch]

rewriting history

git rebase

• will leave that as an exercise for you to investigate...

remote operations

remote repositories

git push [repository] [repository branch]

git pull [repository] [repository branch]

remote operations

user one

user two

repository(github)

repository(internal)

user

user

user

example - group using open source code internally with modifications specific to them can easily push/pull from the project ‘master’

some rules i tend to follow...

• NEVER pull when you have uncommitted changes - commit your work first

• if working on a feature, use a local branch, then this leaves the master open for other fixes

• NEVER rebase or amend commits that you have pushed

• simply...

• ‘pull’ at the start of the day and at regular intervals (as often as you’d checkout your code in cvs/svn)

• ‘push’ after every commit

If you want it to work like cvs / svn

github

github

• http://github.com

• popular git repository hosting site

• home to many open source projects:

• ruby on rails, jquery to name two...

a quick hands-on with github

the plan...

• get yourselves into pairs

• person 1:

• create a repository

• check in some code

• add person 2 to project

the plan...

• person 2:

• pull code from person 1’s repository

• make some changes and push back to repository

• person 1:

• pull these changes

the plan...

• somebody:

• tag a release of the code

• push this tag to github

• stare in awe at the auto-generated tarball

if we have time...

• person 1:

• create a local branch of the code

• push this branch to github

• person 2:

• pull and work with this remote branch

if we have more time

• simulate a conflict and resolve it

let’s get going...

person 1

person 2

git clone [paste ‘your clone url’]

edit something

add and commit

git push origin master

person 1

git pull origin master

see if you have the changes from your partner

somebody

git tag rel_1.0

git push --tags

do we have time?

person 1

git branch new_feature_foo

git checkout new_feature_foo

edit something, add and commit

git push origin new_feature_foo

person 2

git remote show origin

git fetch origin new_feature_foo:new_feature_foo

git fetch [repo] [remote_branch]:[local_branch]

edit something, add and commit

git push origin new_feature_foo

cat .git/config

- info on repository setup

simulating a conflict

person 1

without doing a git pull!

edit the file that person 2 just edited

save, add and commit changes

git push origin new_feature_foo

O_o ooops...

git pull origin new_feature_foo

(git will inform you of a conflict)

edit the file - resolve the conflict

git add, commit, push

conflict resolved! ^_^

further reading

• http://git-scm.com/documentation

• http://learn.github.com/

• http://help.github.com/

• http://www.gitready.com/

further reading

git configsome setup i find useful...

git config --global color.diff auto

git config --global color.status auto

git config --global color.branch auto

git config --global color.interactive auto

git config --global alias.st status

git config --global alias.ci commit

git config --global alias.co checkout

git config --global alias.br branch

git config --global core.excludesfile ~/.gitignore

echo "*~" >~/.gitignore

echo ".DS_Store" >>~/.gitignore