Git presentation

245
-1

Published on

An introduction to the git SCM tool. Geared towards SVN users too.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
245
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 70-80% smaller than CVS & SVN
  • SHA1 was used by design due to the distributed nature of git. ie: “Your revision X != my revision X”. Because SHA1 is used, commits can now easily be cryptographically secured & signed by tagging them.
  • All history is stored in a central location To get a simple log for a project with a lot of commits can take a while
  • Obviously, this is a great benefit for developing a large project like the kernel
  • Since branching is so easy, creating & merging branches to fix a single bug or add a single new feature becomes very common.
  • Git presentation

    1. 1. Git“The stupid content tracker”
    2. 2. What is Git?A popular distributed version control system designed to handle very large projects with speed and efficiency.http://git-scm.com/
    3. 3. Why is it stupid?It’s stupidly fast*It’s stupidly easy to branch & merge$ time git checkout -b newbranch Switched to a new branch newbranch real 0m0.292s• Repositories are stupidly small (size of FreeBSD repo) * Cygwin is a bit slower CVS 1.7 GB SVN 3.9 GB GIT 511 MB
    4. 4. Git History2002 ◦ Linus uses BitKeeper to track the Linux kernelApril, 2005 ◦ BitMover drops free license for BitKeeper ◦ Linus starts writing his own SCM: GitJune 2005 ◦ Git is officially used to track the kernel2007 ◦ Git 1.5.0 released ◦ Major usability improvement
    5. 5. What makes Git better? It’s distributed! Does not store deltas ◦ Uses SHA1 to uniquely identify a commit ◦ Linus called it “a content- addressable filesystem, used to track directory trees.” Efficiency ◦ Compresses repository very well ◦ Local operations are fast ◦ Online operations over git:// protocol are also fast Easy branching & merging ◦ Each commit can have multiple parents. Cleaner ◦ Everything is stored in a single top-level .git directory
    6. 6. Centralized vs.Decentralized
    7. 7. Centralized SCM Source: http://is.gd/dBd6R•Operations require central server •Single point of failure •Can be a bottleneck
    8. 8. Decentralized SCM Source: http://is.gd/dBd6R•Anyone can be a server•Everyone has a full local repository
    9. 9. Decentralized Example Source: http://is.gd/dBd6RClone from a remote upstream repository
    10. 10. Decentralized Example Source: http://is.gd/dBd6RCreate topic branches based on thepristine copy
    11. 11. Decentralized Example Source: http://is.gd/dBd6RPush both branches back to upstream
    12. 12. Decentralized Example Source: http://is.gd/dBd6RPush changes to another web server
    13. 13. Decentralized Example Source: http://is.gd/dBd6RPush & Pull changes from another co-worker, or back to the web server
    14. 14. Benefits of DecentralizationCommit locally ◦ Keep experimental code local ◦ Push solid working code to main repo ◦ Use local topic branches ◦ Some idea turns out badly? $ git branch –d my_bad_ideaNo single point of failureTrivial backupsFast operations*
    15. 15. Look familiar?$ git status $ svn status$ git diff $ svn diff | less$ git log $ svn log | less$ git blame $ svn blame* $ git add FILE $ svn add FILE$ git rm FILE $ svn rm FILE$ git mv FILE $ svn mv FILE* $ git revert FILE $ svn revert FILE
    16. 16. Ok…So what’s different?
    17. 17. The Index (Staging area)Never have to fully commit to every commit ◦ Decide exactly what you want to commit ◦ Group changes logically to match up with your commit message, different topic branches, etc… ◦ Stash non-staged code to test before your commit  $ git add working_file.c $ git stash --keep-index (test… commit) git stash pop
    18. 18. The Index (Staging area)Good for merging ◦ Non-conflicting hunks are auto-staged ◦ Doesn’t clutter the diff with successfully merged code  Use `git diff –cached` to see what you’re going to commit ◦ Only conflicting files left for you to resolve/addDon’t like the index? ◦ $ git commit -a ◦ Automatically stages deleted/modified files ◦ Still must use git add to add new ones (just like SVN)
    19. 19. Some different commands$ git commit -a $ svn commit$ git clone url $ svn checkout url$ git pull $ svn update$ git remote$ git tag -a name $ svn copy http://repo.com/svn/tr unk http://repo.com/svn/ta gs/name
    20. 20. More different commands$ git merge branch $ svn merge -r 20:HEAD http://example.com/sv n/branches/branch$ git rebase onbranch$ git stash$ git submodule
    21. 21. Merge example$ git checkout branch_tomerge # Fix a bug$ git commit –a –m ‘fixed a bug’$ git checkout master # what changed between branches?$ git diff master branch_tomerge$ git merge branch_tomerge # delete the old branch$ git branch –d branch_tomerge
    22. 22. RebasingWhat is rebasing? ◦ Finds all committed changes since you branched ◦ Resets your branch so it’s identical to the HEAD of the branch you’re rebasing onto ◦ Re-applies your changes on topWhy do it? ◦ Clean up your history ◦ Don’t have to leave old topic branches lying aroundWhat to watch out for? ◦ Don’t rework your history if you’ve already merged and pushed to a remote repo that others use
    23. 23. Rebase example # We want to rebase bugfix onto master $ git checkout bugfix …make changes, and commit here… # update from remote $ git checkout master $ git pull origin master # Rebase changes on top of the updated master $ git checkout bugfix $ git rebase master # Now we can do a ‘fast-forward’ merge $ git checkout master $ git merge bugfix
    24. 24. Stashing filesWhy? ◦ You’re working on something ◦ You’ve got some debug code you don’t want to commit yet ◦ Need to work on something elseHow? ◦ $ git stash ◦ Do something else… ◦ $ git stash pop
    25. 25. Help, Git is scary! (137 Commands) Source: http://is.gd/dBd6R
    26. 26. Most used… (24 Commands) Source: http://is.gd/dBd6R
    27. 27. Some GUI tools… (+5 Commands) Source: http://is.gd/dBd6R
    28. 28. The “plumbing” (most never used) Source: http://is.gd/dBd6R
    29. 29. Ok, so maybe not so scary…Revision numbers are now SHA1 hashes ◦ Seems scary, but really isn’t…  Copy/Paste  Specify partial hash (868bae)  Use references (HEAD^, HEAD^^, mybranch@{yesterday})  Use tags  $ man git-rev-parse Explains all the ways you can refer to thingsCommand help ◦ $ git help foo $ git help ◦ $ man git-foo man pages ◦ $ git foo --help ◦ $ git foo -h brief help
    30. 30. Subversion Integration“the best part about GIT is that no one has to know you’re using it”A basic git-svn workflow:$ git svn clone REPO_URL# ... hack hack hack ...$ git commit -a# ... hack hack hack ...$ git commit -a$ git svn rebase$ git svn dcommit
    31. 31. Subversion Integration“the best part about GIT is that no one has to know you’re using it”An even better git-svn workflow:$ git svn clone REPO_URL$ git checkout -b new_branch# ... hack hack hack ...$ git commit -a$ git svn rebase$ git svn dcommit$ git checkout master$ git branch -d new_branch$ git svn rebase
    32. 32. Other resourcesCrash course for SVN users ◦ http://git.or.cz/course/svn.htmlCheat Sheet ◦ http://zrusin.blogspot.com/2007/09/git-cheat- sheet.htmlProGit eBook (Free!) ◦ http://progit.org/Screencasts ◦ http://gitcasts.com/Extremely detailed, yet very helpful presentation ◦ http://excess.org/article/2008/07/ogre-git-tutorial/
    33. 33. Quick Demo
    34. 34. Questions?

    ×