Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Git from SVN

1,405 views

Published on

Basic Git usage for developers who've already been used to SVN

Published in: Technology
  • Be the first to comment

Git from SVN

  1. 1. Git from SVN Justin Yoo
  2. 2. Overview • Git over SVN • Git Basics with SourceTree • Git Best Practices with SourceTree
  3. 3. Git over SVN Git SVN
  4. 4. Git over SVN Git SVN Commit Push Commit
  5. 5. Git over SVN Git • Commit to my local repository • Push commits to remote repository SVN • Commit to remote repository
  6. 6. Git over SVN • Why local repository? – Fast
  7. 7. Git over SVN • Why local repository? – Fast – Can create branches as many as I want • Branches only I want can be pushed to remote
  8. 8. Git over SVN • Why local repository? – Fast – Can create branches as many as I want • Branches only I want can be pushed to remote – Don’t have to worry about commits from others
  9. 9. Git over SVN • Why local repository? – Fast – Can create branches as many as I want • Branches only I want can be pushed to remote – Don’t have to worry about commits from others – Can commit even if remote is not connectable
  10. 10. Git Basics with SourceTree • Clone – Copy remote repository to your local
  11. 11. Git Basics with SourceTree • • Branches – Where you’re currently working
  12. 12. Git Basics with SourceTree • • Remotes – Where your commits are pushed
  13. 13. Git Basics with SourceTree • • Working Copy – Where your changes are seen
  14. 14. Git Basics with SourceTree • Unstaged files – Not yet ready for commit • Modified – README.md • Added – file-a.txt
  15. 15. Git Basics with SourceTree • Staged files – Ready for commit
  16. 16. Git Basics with SourceTree • Local master is 2 commits ahead from remote’s origin/master • Ready for push!
  17. 17. Git Basics with SourceTree
  18. 18. Git Basics with SourceTree • Local master and remote’s origin/master are in sync now
  19. 19. Git Basics with SourceTree • Keep changing and ready for another push
  20. 20. Git Basics with SourceTree • What???!!! • Push fails!!! • Because: – Other developers have already pushed their commits – Therefore your remote snapshot is not up-to- date
  21. 21. Git Basics with SourceTree • • Time to pull or fetch for sync
  22. 22. Git Basics with SourceTree Pull • Downloads all changes from remote • Changes are merged to local repository – fetch + merge • Recommended for most cases Fetch • Downloads all changes from remote • Changes are NOT merged to local repository • Recommended when: – pull fails – don’t want auto merge
  23. 23. Git Basics with SourceTree • Push again and…
  24. 24. Git Basics with SourceTree • Push success! • Local repository and remote one are now in sync
  25. 25. Git Best Practices with SourceTree • Always sync first before merge and push – Other developers have already pushed their changes
  26. 26. Git Best Practices with SourceTree • Commit to your local as often and small as possible – DO NOT commit a big chunk of changes – Commit small changes at one time • Other developers can easily trace it
  27. 27. Git Best Practices with SourceTree • Use git-flow approach – SourceTree natively supports it – http://nvie.com/posts/a- successful-git-branching- model/
  28. 28. Git Best Practices with SourceTree • Git-Flow? – Best practice for git branching model – Always work on your local branch with prefix of: • hotfix- • feature- • Etc…
  29. 29. Git Best Practices with SourceTree • Git-Flow? – Then merge those branches to dev and push – Once everything is fine, dev can be merged to master – Production release is performed from master
  30. 30. Git Best Practices with SourceTree • Use fork – Cloning the original remote repo to another remote repo – Work on your own forked repo – Send pull request to original repo
  31. 31. Git Best Practices with SourceTree • Why fork? – Sending pull request is a great starting point of code review – Can identify if the changes can be merged without concern – Depending on code maintainer’s willingness • Don’t have to use fork, unless the main code maintainer is willing to use
  32. 32. Questions?

×