The document provides an overview of version control systems and introduces Git and GitHub. It discusses the differences between centralized and distributed version control. It then covers the basics of using Git locally including initialization, staging files, committing changes, branching and merging. Finally, it demonstrates some common remote operations with GitHub such as pushing, pulling and tagging releases.

1. git and github
darren oakley

2. 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

3. what we’ll cover
• brief discussion on version control
- ‘traditional’ v’s distributed
• git - the basics
• github - the basics

4. what we won’t cover
• advanced git
• rebase
• sub-modules
• git-svn

5. version control

6. version control
• what most people are (probably) used to:
• concurrent version system (cvs)
• subversion (svn)

7. version control
• cvs and svn
• central source control server
• users check code into server
• requires connection to the server to
perform commits, updates etc.

8. distributed version
control
• the new hotness...
• git
• mercurial (hg)
• bazaar (bzr)

9. 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)

10. git

11. 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!

12. normal workflow

13. local operations
working staging git directory
directory area (repsoitory)
checkout the project
stage files
commit

14. staging files
git add [filenames]
• add all changed files to the staging area:
git add .
• these changes are NOT committed yet

15. 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

16. 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...

17. committing
git commit -m “commit message”
git commit -a -m “commit message”

18. branching / merging

19. branching
git branch
git branch [new branch name]
git checkout [new branch name]

20. merging
git checkout [target branch]
git merge [other branch]
git merge --squash [other branch]

21. rewriting history
git rebase
• will leave that as an exercise for you to
investigate...

22. remote operations

23. remote repositories
git push [repository] [repository branch]
git pull [repository] [repository branch]

24. remote operations
user
repository
(github)
user one user
user
repository
(internal)
example - group using open source code internally with
modifications specific to them can easily push/pull from
user two
the project ‘master’

25. some rules i tend
to follow...

26. • 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

27. If you want it to work
like cvs / svn
• 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

28. github

29. github
• http://github.com
• popular git repository hosting site
• home to many open source projects:
• ruby on rails, jquery to name two...

30. a quick hands-on
with github

31. the plan...
• get yourselves into pairs
• person 1:
• create a repository
• check in some code
• add person 2 to project

32. the plan...
• person 2:
• pull code from person 1’s repository
• make some changes and push back to
repository
• person 1:
• pull these changes

33. the plan...
• somebody:
• tag a release of the code
• push this tag to github
• stare in awe at the auto-generated tarball

34. 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

35. if we have more time
• simulate a conflict and resolve it

36. let’s get going...

37. person 1

43. person 2

45. git clone [paste ‘your clone url’]
edit something
add and commit
git push origin master

46. person 1

47. git pull origin master
see if you have the changes from your
partner

48. somebody

49. git tag rel_1.0
git push --tags

52. do we have time?

53. person 1

54. git branch new_feature_foo
git checkout new_feature_foo
edit something, add and commit
git push origin new_feature_foo

55. person 2

56. git remote show origin
git fetch origin new_feature_foo:new_feature_foo
git fetch [repo] [remote_branch]:[local_branch]

57. edit something, add and commit
git push origin new_feature_foo
cat .git/config
- info on repository setup

59. simulating a conflict

60. person 1

61. 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...

62. 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! ^_^

63. further reading
• http://git-scm.com/documentation
• http://learn.github.com/
• http://help.github.com/
• http://www.gitready.com/

64. further reading

65. git config
some setup i find useful...

66. git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto
git config --global color.interactive auto

67. git config --global alias.st status
git config --global alias.ci commit
git config --global alias.co checkout
git config --global alias.br branch

68. git config --global core.excludesfile ~/.gitignore
echo "*~" >~/.gitignore
echo ".DS_Store" >>~/.gitignore