• Like
  • Save
Git - (a) Gentle InTroduction
Upcoming SlideShare
Loading in...5
×
 

Git - (a) Gentle InTroduction

on

  • 2,992 views

Git speech at Jug Torino november 2010 meeting

Git speech at Jug Torino november 2010 meeting

Statistics

Views

Total Views
2,992
Views on SlideShare
2,922
Embed Views
70

Actions

Likes
15
Downloads
0
Comments
1

4 Embeds 70

http://lanyrd.com 61
http://www.linkedin.com 4
https://www.linkedin.com 4
http://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Git - (a) Gentle InTroduction Git - (a) Gentle InTroduction Presentation Transcript

    • Git! (a) Gentle InTroduction Bruno Bossola
    • Git!
      • About version control
      • Concepts
      • Working with repos and files
      • Working with remotes
      • Branching
      • Remote branches
      • Tools
      • Q&A
        • Disclaimer: this is limited by my own experience:)
    • About version control Picture courtesy of globalnerdy.com All rights kindly reserved
    • Version control: centralized Picture courtesy of progit.org. All rights kindly reserved
      • CVS
      • SVN
    • Version control: distributed
      • Git
      • Mercurial
      • Bazaar
      Picture courtesy of progit.org. All rights kindly reserved
    • Concepts
    • Concepts
      • Snapshots, not deltas
      • Nearly every operation is local
      • Integrity is a priority
      • The “three states
    • Snapshot, not deltas
      • Deltas are maintained
        • CVS, SVN, Bazaar
      Picture courtesy of progit.org. All rights kindly reserved
    • Snapshot, not deltas
      • Full file is mantained
        • Git , BitKeeper
      Picture courtesy of progit.org. All rights kindly reserved
    • Most operations are local
      • Your local database contains a full copy of the remote(s)
      • Browsing, changes, search all happening locally
      • You can do almost everything without network
      • ...and all the db is in a nice, clean , separate .git folder :)
    • Integrity is a priority
      • Everything in Git is check-summed
        • SHA-1 hash
        • 40-character string such as:
      • It's impossible to make a change withoug Git knowing it!
      • Git generally only adds data
      95b87297210672b16bb70ded20626c9c551ccd58
    • The Three States
      • Modified
      • Committed
      • Staged
      Picture courtesy of progit.org. All rights kindly reserved
    • Git Setup (1)
      • Install git
      • apt-get install git-core
      • yum install git-core
      • http://code.google.com/p/git-osx-installer
      • http://code.google.com/p/msysgit
    • Git Setup (2)
      • Set your identity
      • 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
    • Working with repos and files Picture courtesy of questionhub.com. All rights kindly reserved
    • Create a repository
      • Move into an empty folder...
        • Creates an empty repository
        • .git folder contains the database
        > git init
    • Clone a repository
      • Move into an empty folder...
        • Different protocols are available
          • git (native)
          • http(s)
          • ssh
      • It's called “clone” because you get a full copy of the repository!
        > git clone <url>
    • File status Picture courtesy of progit.org. All rights kindly reserved
    • Initial status
      • Right after a clone:
        > git status # On branch master nothing to commit (working directory clean)
    • 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)
    • 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 #
    • 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
    • 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 #
    • 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 #
    • WTF?
      • We have two version of the same file
      • If you commit now the first one will go in
      • 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
    • Committing
      • A commit will put files in the staging into the repo
      • 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
    • 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;)
    • 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 #
    • 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...)
    • Discarding changes
      • File recovered!
      • 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)
    • 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
    • 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 [...]
    • Looking into one commit
      • ...this is reeallly useful!
        > git show --pretty=&quot;format:&quot; --name-only d13c1a17cc0599d3ed44cfe98ed3a194df048b15 annotation.txt readme.txt
    • Working with remotes Picture courtesy of useit.com. All rights kindly reserved
    • Working with remotes
      • You can have multiple remote repos
        • usually one, “origin”
        • sometimes one main r/w, other r/o,
        • rarely multiple
      • Collaborating means pushing and pulling data from the remote repos
    • Branching Picture courtesy of campus.houghton.edu. All rights kindly reserved
    • How Git stores data
      • Git has an internal object database
      • It contains
        • blob (files)
        • commit
        • tree
        • …and other stuff :)
    • After a commit... Picture courtesy of progit.org. All rights kindly reserved
    • After three commits... Picture courtesy of progit.org. All rights kindly reserved
    • A branch is a pointer
      • A branch is simply a movable pointer
      Picture courtesy of progit.org. All rights kindly reserved
    • Creating a branch
      • Create a branch:
      Picture courtesy of progit.org. All rights kindly reserved
        > git branch testing
    • Head
        • Git knows what branch you’re currently on with a special pointer called HEAD
      Picture courtesy of progit.org. All rights kindly reserved
    • 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'
    • 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'
    • Switch to master Picture courtesy of progit.org. All rights kindly reserved
        • Git moves back HEAD to point to masterpointer
        > git checkout master
    • 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!'
    • 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(-)
    • The Stash
      • Temporary storage area to store changes
      • you don't want to commit “half-done” and you want to change branch
      • Very useful for “dirty” works :)
        • Usage: git stash push/pop/clean
    • Remote branches Picture courtesy of maps.google.com. All rights kindly reserved
    • Remote branches
      • Reference to state of branches on a remote repository
      • They're local, but cannot be moved
      • They're moved automatically during synchronization
      • <remote>/<branch name>
      • Your default remote is “origin”
    • Initial clone Picture courtesy of progit.org. All rights kindly reserved
    • How do I sync?
      • “master” is tracked automatically
      • “fetch” command will download all the updates from the remote db
        • “merge” to merge the branches
        • “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.
    • I do some work... Picture courtesy of progit.org. All rights kindly reserved
    • Someone else pushes! Picture courtesy of progit.org. All rights kindly reserved
    • Synchronize (with fetch) Picture courtesy of progit.org. All rights kindly reserved
    • And now?
      • Fetch is just fetching all the data, nothing changes
      • To update your master copy to the remote you may:
        • Merge
        • Rebase
      • You may have also “pulled” before (fetch + merge)
    • Rebasing (the “cool” thing!)
      • Takes all the changes committed on one branch and replay them on another one
      • No differences in result
      • Much cleaner history
      • Branches are then easy to integrate to the master
    • Rebasing (1)
      • Two branches, diverging, we need to merge
      Picture courtesy of progit.org. All rights kindly reserved
    • Rebasing (2)
      • Traditional, using merge
      Picture courtesy of progit.org. All rights kindly reserved
    • 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
    • Push
      • The push command is used to send your changes to a remote repo
      • 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
    • Getting a remote branch
      • To start contributing on a branch you have to check it out
      • 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;
    • Tracking branches
      • Checking out a local branch from a remote branch automatically creates a tracking branch .
      • Tracking branches are local branches that have a direct relationship to a remote branch
      • Push/pull will send/fetch+merge contents from the remote automatically
    • Remote branches
      • Reference to state of branches on a remote repository
      • They're local, but cannot be moved
      • They're moved automatically during synchronization
      • <remote>/<branch name>
      • Your default remote is “origin”
    • Tools
    • CLI tools
      • Command line works like a charm!
      • You can still revert to your IDE/editor/tool to merge
        • ...but built-in merge is brilliant!
      • To visualize branches: gitk
        • (gitx on osx)
    • IDE support
      • Eclipse: poor, sloppy
        • The guys of Egit wants to develop it “pure”, so it'll take years :)
      • Idea: good support
      • NetBeans: experimental (buggy) support
      • ...yeah, use the command line!
    • Server side solutions
      • GitHub
      • BitBucket
      • GitEnterprise (shameless plug!)
    • Links
      • ProGit book
        • http://progit.org/book/
      • Community Git book
        • http://book.git-scm.com/
      • GitEnterprise
        • http://www.gitenterprise.com
    • Q&A Ahhh.... a free artwork, finally!