Git - (a) Gentle InTroduction

  • 2,515 views
Uploaded on

Git speech at Jug Torino november 2010 meeting

Git speech at Jug Torino november 2010 meeting

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

Views

Total Views
2,515
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
1
Likes
15

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. Git! (a) Gentle InTroduction Bruno Bossola
  • 2. Git!
      • Disclaimer: this is limited by my own experience:)
  • 10. About version control Picture courtesy of globalnerdy.com All rights kindly reserved
  • 11. Version control: centralized Picture courtesy of progit.org. All rights kindly reserved
  • 13. Version control: distributed Picture courtesy of progit.org. All rights kindly reserved
  • 16. Concepts
  • 17. Concepts
    • Snapshots, not deltas
    • 18. Nearly every operation is local
    • 19. Integrity is a priority
    • 20. The “three states
  • 21. Snapshot, not deltas
    • Deltas are maintained
      • CVS, SVN, Bazaar
    Picture courtesy of progit.org. All rights kindly reserved
  • 22. Snapshot, not deltas
    • Full file is mantained
      • Git , BitKeeper
    Picture courtesy of progit.org. All rights kindly reserved
  • 23. Most operations are local
    • Your local database contains a full copy of the remote(s)
    • 24. Browsing, changes, search all happening locally
    • 25. You can do almost everything without network
    • 26. ...and all the db is in a nice, clean , separate .git folder :)
  • 27. Integrity is a priority
    • Everything in Git is check-summed
      • SHA-1 hash
      • 28. 40-character string such as:
    • It's impossible to make a change withoug Git knowing it!
    • 29. Git generally only adds data
    95b87297210672b16bb70ded20626c9c551ccd58
  • 30. The Three States Picture courtesy of progit.org. All rights kindly reserved
  • 33. Git Setup (1)
    • Install git
    • apt-get install git-core
    • 34. yum install git-core
    • 35. http://code.google.com/p/git-osx-installer
    • 36. http://code.google.com/p/msysgit
  • 37. Git Setup (2)
    • Set your identity
    • 38. Double check!
      > git config --global user.name "Mark Joyce" > git config --global user.email mj@xyz.com
      > git config --list –-global user.name=Mark Joyce user.email=mj@xyz.com http.sslverify=false
      > git config --global user.name "Mark Joyce" > git config --global user.email mj@xyz.com
  • 39. Working with repos and files Picture courtesy of questionhub.com. All rights kindly reserved
  • 40. Create a repository
    • Move into an empty folder...
      • Creates an empty repository
      • 41. .git folder contains the database
      > git init
  • 42. Clone a repository
    • Move into an empty folder...
      • Different protocols are available
    • It's called “clone” because you get a full copy of the repository!
      > git clone <url>
  • 45. File status Picture courtesy of progit.org. All rights kindly reserved
  • 46. Initial status
    • Right after a clone:
      > git status # On branch master nothing to commit (working directory clean)
  • 47. Add a file
    • The new file is now untracked
      > vi readme.txt > git status # On branch master # Untracked files: # (use &quot;git add <file>...&quot; to include in what will be committed) # # readme.txt nothing added to commit but untracked files present (use &quot;git add&quot; to track)
  • 48. Track the file
    • The new file is now tracked and staged
      > git add readme.txt > git status # On branch master # Changes to be committed: # (use &quot;git reset HEAD <file>...&quot; to unstage) # # new file: readme.txt #
  • 49. Change existing file
      > vi annotation.txt > git status # On branch master # Changes to be committed: # (use &quot;git reset HEAD <file>...&quot; to unstage) # # new file: readme.txt # # Changed but not updated: # (use &quot;git add <file>...&quot; to update what will be committed) # (use &quot;git checkout -- <file>...&quot; to discard changes in working directory) # # modified: annotation.txt
  • 50. Track the changed file
    • The changed file is now staged
      > git add annotation.txt > git status # On branch master # Changes to be committed: # (use &quot;git reset HEAD <file>...&quot; to unstage) # # modified: annotation.txt # new file: readme.txt #
  • 51. Change already staged file
      > vi annotation.txt > git status # On branch master # Changes to be committed: # (use &quot;git reset HEAD <file>...&quot; to unstage) # # new file: readme.txt # # Changed but not updated: # (use &quot;git add <file>...&quot; to update […]) # (use &quot;git checkout -- <file>...&quot; to […]) # # modified: annotation.txt #
  • 52. WTF?
    • We have two version of the same file
    • 53. If you commit now the first one will go in
    • 54. to stage the existing version:
      > git add annotation.txt > git status # On branch master # Changes to be committed: # (use &quot;git reset HEAD <file>...&quot; to unstage) # # modified: annotation.txt # new file: readme.txt
  • 55. Committing
    • A commit will put files in the staging into the repo
    • 56. This will invoke your editor, better do this:
      > git commit
      > git commit -m '[GTN-44] scheduler fix' [master 019a938] [GTN-44] scheduler fix 2 files changed, 5 instions(+), 1 dltions(-) create mode 100644 readme.txt
  • 57. Remove existing file (1)
    • The removal is detected
      > rm annotation.txt > git status # On branch master # Changed but not updated: # (use &quot;git add/rm <file>...&quot;) to ...) # (use &quot;git checkout -- <file>...&quot;) to ...) # # deleted: annotation.txt # no changes added to commit (use &quot;git add&quot; and/or &quot;git commit -a&quot;)
  • 58. Remove existing file (2)
    • The removal is staged: if you commit it will be removed from the repo
      > git rm annotation.txt rm 'annotation.txt' > git status # On branch master # Changes to be committed: # (use &quot;git reset HEAD <file>...&quot; to unstage) # # deleted: annotation.txt #
  • 59. From staged to modified
      > git reset HEAD annotation.txt Unstaged changes after reset: M annotation.txt > git status # On branch master # Changed but not updated: # (use &quot;git add/rm <file>...&quot; to upd...) # (use &quot;git checkout -- <file>...&quot; to dis...) # # deleted: annotation.txt # no changes added to commit (use...)
  • 60. Discarding changes
    • File recovered!
    • 61. Yes, “checkout” is a bit weird :)
      > git checkout annotation.txt > ls annotation.txt readme.txt > git status # On branch master nothing to commit (working directory clean)
  • 62. Changing a commit
    • Takes staging area and uses to amend the previous commit
      > git commit –amend -m 'oops!' [master 5793792] oops! 2 files changed, 6 insertions(+), 1 deletions(-) create mode 100644 readme.txt
  • 63. Looking into commits
      > git log commit 57937924f8423d79b5cc50d4fea807b271dc0383 Author: Bruno Bossola <bbossola@gmail.com> Date: Tue Nov 2 23:26:39 2010 +0000 oops! commit 8aefe45413517f71ceb64783cfae58e20031af52 Author: Bruno Bossola <bbossola@gmail.com> Date: Tue Nov 2 22:35:00 2010 +0000 annotations fixed [...]
  • 64. Looking into one commit
    • ...this is reeallly useful!
      > git show --pretty=&quot;format:&quot; --name-only d13c1a17cc0599d3ed44cfe98ed3a194df048b15 annotation.txt readme.txt
  • 65. Working with remotes Picture courtesy of useit.com. All rights kindly reserved
  • 66. Working with remotes
    • You can have multiple remote repos
      • usually one, “origin”
      • 67. sometimes one main r/w, other r/o,
      • 68. rarely multiple
    • Collaborating means pushing and pulling data from the remote repos
  • 69. Branching Picture courtesy of campus.houghton.edu. All rights kindly reserved
  • 70. How Git stores data
    • Git has an internal object database
    • 71. It contains
  • 75. After a commit... Picture courtesy of progit.org. All rights kindly reserved
  • 76. After three commits... Picture courtesy of progit.org. All rights kindly reserved
  • 77. A branch is a pointer
    • A branch is simply a movable pointer
    Picture courtesy of progit.org. All rights kindly reserved
  • 78. Creating a branch
    • Create a branch:
    Picture courtesy of progit.org. All rights kindly reserved
      > git branch testing
  • 79. Head
      • Git knows what branch you’re currently on with a special pointer called HEAD
    Picture courtesy of progit.org. All rights kindly reserved
  • 80. Switching to a branch Picture courtesy of progit.org. All rights kindly reserved
      • Git moves HEAD pointer to the branch pointer
      > git checkout testing Switched to branch 'testing'
  • 81. Changing a file (on a branch) Picture courtesy of progit.org. All rights kindly reserved
      • Git keeps following with HEAD the branch pointer
      > vi readme.txt > git commit -a -m 'readme file updated'
  • 82. Switch to master Picture courtesy of progit.org. All rights kindly reserved
      • Git moves back HEAD to point to masterpointer
      > git checkout master
  • 83. And change again! Picture courtesy of progit.org. All rights kindly reserved
      • Git still keeping separate pointers to the branches
      > vi readme.txt > git commit -a -m 'readme file now rocks!'
  • 84. Now... merge! Picture courtesy of progit.org. All rights kindly reserved
      • A new “merge” commit is generated
      > git merge testing Merge made by recursive. readme.txt | 1 + 1 files changed, 1 instions(+), 0 dltions(-)
  • 85. The Stash
    • Temporary storage area to store changes
    • 86. you don't want to commit “half-done” and you want to change branch
    • 87. Very useful for “dirty” works :)
      • Usage: git stash push/pop/clean
  • 88. Remote branches Picture courtesy of maps.google.com. All rights kindly reserved
  • 89. Remote branches
    • Reference to state of branches on a remote repository
    • 90. They're local, but cannot be moved
    • 91. They're moved automatically during synchronization
    • 92. <remote>/<branch name>
    • 93. Your default remote is “origin”
  • 94. Initial clone Picture courtesy of progit.org. All rights kindly reserved
  • 95. How do I sync?
    • “master” is tracked automatically
    • 96. “fetch” command will download all the updates from the remote db
      • “merge” to merge the branches
      • 97. “rebase” (let's see this later)
    • “pull” is a shortcut for fetch + pull
      > git pull origin master * branch master -> FETCH_HEAD Already up-to-date.
  • 98. I do some work... Picture courtesy of progit.org. All rights kindly reserved
  • 99. Someone else pushes! Picture courtesy of progit.org. All rights kindly reserved
  • 100. Synchronize (with fetch) Picture courtesy of progit.org. All rights kindly reserved
  • 101. And now?
    • Fetch is just fetching all the data, nothing changes
    • 102. To update your master copy to the remote you may:
    • You may have also “pulled” before (fetch + merge)
  • 104. Rebasing (the “cool” thing!)
    • Takes all the changes committed on one branch and replay them on another one
    • 105. No differences in result
    • 106. Much cleaner history
    • 107. Branches are then easy to integrate to the master
  • 108. Rebasing (1)
    • Two branches, diverging, we need to merge
    Picture courtesy of progit.org. All rights kindly reserved
  • 109. Rebasing (2)
    • Traditional, using merge
    Picture courtesy of progit.org. All rights kindly reserved
  • 110. Rebasing (3)
    • Rock'n roll!
    Picture courtesy of progit.org. All rights kindly reserved
      > git checkout experiment > git rebase master First, rewinding head to replay your work on top of it... Applying: added staged command
  • 111. Push
    • The push command is used to send your changes to a remote repo
    • 112. Anyone who fetch will get the new branch
      > git push origin experiment Counting objects: 20, done. Compressing objects: 100% (14/14), done. Writing objcts: 100% (15/15), 1.7 KiB, done. Total 15 (delta 5), reused 0 (delta 0) To bbossola@gitent-scm.com... * [new branch] experiment -> experiment
  • 113. Getting a remote branch
    • To start contributing on a branch you have to check it out
    • 114. This branch is now tracked (see next)
      > git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. Switched to a new branch &quot;serverfix&quot;
  • 115. Tracking branches
    • Checking out a local branch from a remote branch automatically creates a tracking branch .
    • 116. Tracking branches are local branches that have a direct relationship to a remote branch
    • 117. Push/pull will send/fetch+merge contents from the remote automatically
  • 118. Remote branches
    • Reference to state of branches on a remote repository
    • 119. They're local, but cannot be moved
    • 120. They're moved automatically during synchronization
    • 121. <remote>/<branch name>
    • 122. Your default remote is “origin”
  • 123. Tools
  • 124. CLI tools
    • Command line works like a charm!
    • 125. You can still revert to your IDE/editor/tool to merge
      • ...but built-in merge is brilliant!
    • To visualize branches: gitk
      • (gitx on osx)
  • 126. IDE support
    • Eclipse: poor, sloppy
      • The guys of Egit wants to develop it “pure”, so it'll take years :)
    • Idea: good support
    • 127. NetBeans: experimental (buggy) support
    • 128. ...yeah, use the command line!
  • 129. Server side solutions
  • 132. Links
    • ProGit book
      • http://progit.org/book/
    • Community Git book
      • http://book.git-scm.com/
    • GitEnterprise
      • http://www.gitenterprise.com
  • 133. Q&A Ahhh.... a free artwork, finally!