Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GIT and SVN

Avatar for chernjie chernjie
August 19, 2012

GIT and SVN

Working with both

Avatar for chernjie

chernjie

August 19, 2012
Tweet

Other Decks in Programming

Transcript

  1. About  me   @chernjie   •  So<ware  engineer  @  mig33

      •  Web  development   •  loves  version  control   •  merge  master  for  releases  -­‐  heavy  GIT  usage   •  WriEen  lots  of  helper  tools  for  GIT  
  2. About  mig33   Social  networking  plaForm  targeGng  emerging   markets,

     primary  on  low-­‐end  mobile  devices   Founded  2005,  yet  sGll  (somewhat)  in  startup  mode   •  small  (but  growing)  engineering  team  (~20)   •  rapid  iteraGons  (weekly  to  biweekly  releases)   •  nothing  perfect,  nothing  frozen,  constantly   improve  and  move  on   •  we  work  in  shorts  and  T-­‐shirts!  
  3. About  mig33   •  Issue  tracker:   – JIRA   – TRAC

      •  We  are  mostly  SVN-­‐centric   •  Slowly  but  surely  transiGoning  to  GIT  
  4. About  Source  Control   •  Home  for  code   • 

    Centralised  or  Distributed   •  Project  archive   •  CollaboraGon  tool   •  IntegraGon  point   – For  development   – For  business  processes  
  5. Subversion   •  Oct  2000   •  Replace  CVS  

    •  Centralized   •  Subversion  exists  to  be  universally  recognized  and  adopted  as  an  open-­‐ source,  centralized  version  control  system  characterized  by  its  reliability  as   a  safe  haven  for  valuable  data;  the  simplicity  of  its  model  and  usage;  and   its  ability  to  support  the  needs  of  a  wide  variety  of  users  and  projects,   from  individuals  to  large-­‐scale  enterprise  operaGons.  
  6. •  Key  benefits   •  Typical  workflow   •  Most

     used  commands   •  Merging  and  branching  in  GIT   •  Code  InvesGgaGon  
  7. GIT   •  Apr  2005   •  Build  and  maintained

     by  Linus  Torvald   •  Distributed   •  GIT,  in  English  refers  to  an  Idiot   •  Global  InformaGon  Tracker  
  8. Key  benefits   Pros   •  SVN  copy,  copies  history

      •  AuthenGcity  of  individual  commits  -­‐  Access  control   •  Easy  to  understand  –  developer  friendly   •  IntegraGon  with  most  system,  IDE  
  9. Problem  with  SVN   •  Branching  is  expensive   – Slow

     (over  network)   •  Branch  switch     •  Branch  merges  are  painful  
  10. Key  benefits   •  Full  history  of  all  (SVN)  changes

      •  Merge  algorithms   •  Easy  switching  between  branches   •  Cheap  local  branching   •  Extremely  smaller  in  size   •  No  annoying  .svn  hidden  folders  in  every   subfolder    
  11. Problem  with  GIT   •  Does  not  like  large  binary

     files   •  Commit  history  can  be  overwriEen   (double  edge  sword)   •  Learning  curve   •  Strange  concept  of  file  rename  add/delete   •  UnintuiGve  commands  
  12. Other  benefits   •  Much  smaller  in  size   • 

    Great  command  line  interface   •  No  annoying  .svn  hidden  folders  in  every   subfolder  
  13. Working  with  GIT  and  SVN   Benefits   •  Enjoy

     GIT  distributed  features   – Extremely  fast   – Cheap  local  branching   – git  extended  log  command  and  features   – git  merge  is  a  breeze  (more  later)   – SVN  access  control   – SVN  sGll  as  a  central  repo  
  14. Working  with  GIT  and  SVN   Benefits   •  Developer

     can  choose  to  work  in  either  GIT  or   SVN  environments   •  SVN  dependent  system  can  conGnue   operaGons  
  15. Working  with  GIT  and  SVN   The  Catch!   • 

    Merge  history  are  not  preserved   – GIT  merges  treated  differently  on  different   checkouts   – different  parent  ==  different  hash   •  Spiral  effect,  lots  of  useful  GIT  features   becomes  redundant   – log  -­‐-­‐merges,  branch  -­‐-­‐contains,    
  16. Merging  in  GIT  and  SVN   Analyzing  the  situaGon  

    •  Merge  history  is  only  preserved  in  the  repo   where  it’s  executed   •  Merge  history  is  important  to  take  advantage   of  GIT’s  features  
  17. Merging  in  GIT  and  SVN   •  Centralized  SVN  

    •  GIT  merge-­‐master  repository   SVN   GIT   merge   repo   GIT   user   GIT   user   GIT   user   SVN   user   Merge   commits   Direct   commits  
  18. Merging  in  GIT  and  SVN   •  GIT  merge-­‐repo  needs

     to  be  preserved   •  Other  GIT  user  repos  are  disposable  
  19. Merging  strategies   •  Conflicts  are  bound  to  happen  

    •  Merge  over  cherry  picking   •  Never  use   – X  theirs   – X  ours   •  Useful   – X  ignore-­‐all-­‐space  
  20. Checkout  an  SVN  repository   •  $  mkdir  web  

    •  $  cd  web   •  $  git  svn  init  –stdlayout  hEps:// svn.domain.com/svn/repo/   •  $  git  svn  fetch  –r  XXXX:HEAD   •  branches  and  tags  can  be  added  at  later  Gme  via   $  git  config  -­‐-­‐add  svn-­‐remote.svn.branches   web/branches/*:refs/remotes/*  
  21. Checkout  an  SVN  repository   •  ^C  (…  stop  fetching

     and  go  home)   •  (…  some  Gme  later)   •  $  git  svn  fetch  (to  conGnue)  
  22. Git  status   •  Most  used  command   •  The

     status  shows  you:   -­‐  which  branch  you’re  on   -­‐  what  files  are  edited/deleted   -­‐  any  unmerged  files  
  23. Git  diff   •  Great  for  quick,  pre-­‐commit  review  

    •  $  git  diff  [otherbranch]  file.php   •  $  git  diff  -­‐-­‐stat/-­‐-­‐shortstat   •  $  git  diff  -­‐-­‐no-­‐index  file1.php  file2.php   (to  use  it  like  normal  diff  tools)   •  Does  not  show  changes  within  the  line  
  24. Git  commit   •  This  only  commits  the  changes  locally

        •  $  git  add  file.php   •  $  git  commit  -­‐m  “JIRA-­‐547:  commit  changed   files”  
  25. Git  svn  dcommit   •  This’ll  commit  to  our  central

     SVN  repository   •  Usually  we  run  this  right  a<er  `git  commit`     •  $  git  svn  dcommit  [-­‐-­‐dry-­‐run]  
  26. Git  svn  rebase   •  Rebase  is  not  `svn  update`,

     but  similar   •  Difference  can  only  be  noGced  if  you  run  this   command  between  `git  commit`  and  `git  svn   dcommit`   •  Prior  to  running  this  command,  no  unstaged   files  are  allowed.  So  remember  to  commit  or   stash  your  changes   •  $  git  svn  rebase  -­‐-­‐fetch-­‐all  
  27. Git  stash   •  Stash  away  the  changes  in  a

     dirty  working   directory     •  $  git  stash  save  {message}   •  $  git  stash  list   •  $  git  stash  pop/show/drop…    
  28. Git  log   •  $  git  log     (will

     show  you  a  list  of  history  for  the  current  branch)   •  $  git  log  -­‐-­‐graph     (will  show  you  nice  history  with  it’s  branching  trees)   •  $  git  log  –p  file.php     (shows  the  full  diff  history  of  a  parGcular  file)  
  29. Git  blame   •  Much  like  SVN’s  blame,  it  shows

     you  the  last   person  ediGng  a  parGcular  line  in  a  file   •  Not  as  useful  as  `git  log  -­‐p`  
  30. Git  branch   •  $  git  branch   (show  a

     list  of  local  branches)   •  $  git  branch  {branchname}   •  $  git  svn  branch  {branchname}   (creates  a  new  svn  branch  from  current  branch)   •  $  git  svn  branch  -­‐t  {tag}  
  31. Git  checkout   •  $  git  checkout  {branchname}   (switch

     to  a  different  branch)   •  $  git  checkout  {remote/branch}  -­‐b   {newbranch}   (checkout  an  exisGng  remote  branch)   •  $  git  checkout  {branchname}  file.php   (checkout  a  file  from  another  branch  and  add  it  to  staging)  
  32. Git  merge   •  is  easy   •  $  git

     merge  {otherbranch}   -­‐m  “merge  {otherbranch}  into  {thisbranch}”   •  Don’t  forget  to  commit  to  svn   $  git  svn  dcommit  
  33. Resolving  merge  conflicts   •  $  git  status   • 

    (resolve  conflicted  files,  this  is  where  `git  log  -­‐p`  can  be   very  useful)   •  $  git  add  file.php   •  $  git  commit   -­‐m  “merge  {otherbranch}  into  {thisbranch}”  
  34. Git  squash   •  $  for  n  in  a  b

     c;  do      echo  $n  >>  file.txt;      git  commit  file.txt  -­‐m  “commit  $n”;   done;   •  $  git  rebase  -­‐i  head~3