git and github

8,498 views

Published on

A short and basic introduction to git and github that I gave at the Sanger Institute on the 15th Dec 2009.

Published in: Technology
3 Comments
20 Likes
Statistics
Notes
No Downloads
Views
Total views
8,498
On SlideShare
0
From Embeds
0
Number of Embeds
194
Actions
Shares
0
Downloads
212
Comments
3
Likes
20
Embeds 0
No embeds

No notes for slide

git and github

  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
  38. person 2
  39. git clone [paste ‘your clone url’] edit something add and commit git push origin master
  40. person 1
  41. git pull origin master see if you have the changes from your partner
  42. somebody
  43. git tag rel_1.0 git push --tags
  44. do we have time?
  45. person 1
  46. git branch new_feature_foo git checkout new_feature_foo edit something, add and commit git push origin new_feature_foo
  47. person 2
  48. git remote show origin git fetch origin new_feature_foo:new_feature_foo git fetch [repo] [remote_branch]:[local_branch]
  49. edit something, add and commit git push origin new_feature_foo cat .git/config - info on repository setup
  50. simulating a conflict
  51. person 1
  52. 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...
  53. 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! ^_^
  54. further reading • http://git-scm.com/documentation • http://learn.github.com/ • http://help.github.com/ • http://www.gitready.com/
  55. further reading
  56. git config some setup i find useful...
  57. git config --global color.diff auto git config --global color.status auto git config --global color.branch auto git config --global color.interactive auto
  58. git config --global alias.st status git config --global alias.ci commit git config --global alias.co checkout git config --global alias.br branch
  59. git config --global core.excludesfile ~/.gitignore echo "*~" >~/.gitignore echo ".DS_Store" >>~/.gitignore

×