Quick intro to Git

  • 2,354 views
Uploaded on

Slides+notes for a talk on Git I did at Techmeetup Edinburgh back in January '09.

Slides+notes for a talk on Git I did at Techmeetup Edinburgh back in January '09.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,354
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
36
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. let’s roll
  • 2. GIT
  • 3. Really Quick Intro To Git Hasan Veldstra <hasan@hypernumbers.com> hypernumbers
  • 4. like CVS or SVN, only much better. fundamental difference – distributed. source control system the logo: an artistic impression:
  • 5. SVN CVS
  • 6. GIT ⋙ { SVN CVS
  • 7. roadmap, disclaimers &c why it’s cool, how it works, how to get started right now. basic stuff – if you like what you see, there’s lots of detailed documentation elsewhere. i am not an expert, just sharing bits i’ve learned.
  • 8. 2005, to manage Linux kernel, spread fast.
  • 9. Linux kernel
  • 10. X11
  • 11. Perl
  • 12. Android
  • 13. Fedora
  • 14. OLPC
  • 15. Ruby On Rails
  • 16. WINE
  • 17. VLC
  • 18. Git itself
  • 19. why Git?
  • 20. why Git? • makes stuff cheap = streamlines things & encourages good practices
  • 21. why Git? • makes stuff cheap • any workflow gets out of your way, doesn’t dictate the way you should work. use it like SVN or use it like the Linux devs.
  • 22. why Git? • makes stuff cheap • any workflow • fast by design & implementation (no network, speed as one of the goals, written in C by great C hackers)
  • 23. SVN is even slower than Bazaar from http://whygitisbetterthanx.com by Scott Chacon of GitHub
  • 24. why Git? • makes stuff cheap • any workflow • fast • small as small or smaller than an equivalent SVN repo.
  • 25. why Git? • makes stuff cheap • any workflow • fastGit has acquired a reputation for being somewhat difficult to get started with and understand but that’s lies. • small • easy to learn
  • 26. $ cd (project directory) $ git init $ (create some files) $ git add . $ git commit -m 'start the project'
  • 27. distributed
  • 28. distributed = no central repository
  • 29. distributed = no central repository (superset of SVN &c)
  • 30. centralized (SVN): repository
  • 31. centralized (SVN): repository !
  • 32. centralized (SVN): repository ! ! devs “check out” the code to create a “working copy”
  • 33. centralized (SVN): repository check in ! !
  • 34. centralized (SVN): repository check in check out ! !
  • 35. centralized (SVN): repository check in check out ! ! make changes
  • 36. centralized (SVN): repository check in check out ! ! make changes check in back to repo
  • 37. centralized (SVN): repository check in check out ! ! make changes check in back to repo update
  • 38. centralized (SVN): repository one-to-many relationship
  • 39. centralized (SVN): repository - - - - - - - - working copy #1
  • 40. centralized (SVN): repository - - - - - - - - - - - working copy #2 - - - - - working copy #1
  • 41. centralized (SVN): repository - - - - - - - - working copy #3 - - - - - - - - - - - working copy #2 - - - - - working copy #1
  • 42. centralized (SVN): • working copies are inferior
  • 43. centralized (SVN): • working copies are inferior • & can’t talk to each other
  • 44. centralized (SVN): • working copies are inferior • & can’t talk to each other • you gotta be online
  • 45. centralized (SVN): • working copies are inferior • & can’t talk to each other • you gotta be online • single point of failure
  • 46. distributed (Git):
  • 47. distributed (Git): checkout
  • 48. distributed (Git): checkout clone we don’t check out, we clone clone = full history, can do anything original can
  • 49. distributed (Git): “canonical” repository "canonical" because it's a social convention, not a technical requirement
  • 50. distributed (Git): “canonical” repository ! local repository #1
  • 51. awesome #1
  • 52. awesome #1 local commits no network => FAST FAST => less “friction” less “friction” => encourages you to commit more often no network => work offline big deal actually, i work in Starbucks a lot, actualy the reason i started using Git in the first place. also nice to be productive on trains, planes &c. it also allows private work, so you can use your revision control system even for early drafts you don't want to publish
  • 53. awesome #1 local commits #1 say you’re working on a feature, & you do the work in several stages, over a couple of days maybe you know, you write the first messy and inefficient version first, and then you refactor it, test it &c &c.
  • 54. awesome #1 local commits #1 #2
  • 55. awesome #1 local commits with SVN you either commit all intermediate steps to the central repo, which clutters up history... ... or you don’t, in which case you’re left on your own and there is no one there to save your butt WHEN you screw up: you can’t roll back to an earlier state, you can only restore clean from the server, losing work. this of course sucks big time. #1 #2 #3
  • 56. awesome #1 local commits (& revision before pushing)
  • 57. distributed (Git): “canonical” repository ! local repository #1
  • 58. distributed (Git): “canonical” repository ! local repository #1 ! local repository #2
  • 59. distributed (Git): “canonical” repository ! local repository #1 ! local repository #2
  • 60. distributed (Git): “canonical” repository clones are full-fledged repositories => exchange patches and merge between them without touching ! the main repo. several people can work together on something new amongst themselves, and then push to main when local repository #1 done. ! = awe local repository #2 some
  • 61. staging area “canonical” repository like a shelf on which to put things that’ll make up the next commit. incremental building of. “chunk commits” = awesome. “tangled working copy” problem gone. local repository - - - - - - - - working copy - - - object database, trees & - - - blobs that represent the stuff on your disk tracked by the repo repo (file contents, staging area
  • 62. as many as you want independent of each other private FAST operations (create, check out, merge, delete) * for new ideas * for bugfixes/features * master for production, one for testing, several for day-to-day work changes the way you work can manage to do some of this with other systems, but is PITA. branching
  • 63. workflows
  • 64. centralized basically like SVN but nicer
  • 65. integration manager blessed repo, integration manager, many devs. “open-source model”.
  • 66. dictator & lieutenants for massive projects, like Linux Kernel
  • 67. infiltration a howto start using Git tomorrow without anyone suspecting a thing.
  • 68. git-svn
  • 69. $ git svn clone (URL) $ git branch bugfix-branch $ git checkout bugfix-branch (make a bunch of changes) $ git commit -m “fixed this bug” $ git rebase -i git-svn $ git checkout master $ git svn rebase $ git rebase bugfix-branch $ git svn dcommit ...all it takes
  • 70. Tools • egit for Eclipse • magit for Emacs • plugins for NetBeans & Visual Studio in the works • so is a TortoiseSvn equivalent • also Gitx on OSX, gitk on Linux • gitweb to serve repos over HTTP
  • 71. Nothing is perfect SVN handles binary files better SVN allows partial check outs
  • 72. MOAR: git-scm.com #git on Freenode github.com Trac + Sourceforge + Facebook :]
  • 73. Questions