git Merge and Rebase

Exploring git-merge and git-rebase, and trying to figure out which one is better in getting hotfixes from master into develop.

Transcript

1. git  Merge  &  Rebase   My  understanding  of  it  
2. Condi&on  for  Fast-­‐forward  Merge   •  HEAD  of  original  MUST  be  the  same  as  the  Merge-­‐Base   •  In  this  example,  HEAD  of  develop  is  the  same  as  master,   and  therefore  we  can  fast-­‐forward  merge  master  into   develop  
3. Result  of  Fast-­‐Forward  Merge   •  To  tell  git  to  only  perform  fast-­‐forward  merge,  we  use   the  –ff-only  flag  
4. Condi&on  for  a  Non-­‐Fast-­‐Forward  Merge   •  HEAD  of  develop  is  NOT  the  same  as  the  Merge-­‐Base   •  It  is  NOT  possible  to  fast-­‐forward  merge  master  into  develop   •  git –ff-only master  while  on  develop,  will  yield   fatal: Not possible to fast-forward, aborting.
5. Result  of  a  Non-­‐Fast-­‐Forward  Merge  
6. What  about  cherry-­‐picking?   •  Github  Pull  Requests  will  automaLcally  use  the  –no-ff  opLon   when  merging.   I.  GeNng  HoOix  into  master  
7. What  about  cherry-­‐picking?   •  The  content  of  K2  (blue),  and  K’2  (red),  are  the  same   •  Their  SHAs  are  different.   II.  Cherry-­‐picking  HoOix  into  develop  
8. What  about  cherry-­‐picking?   •  The  content  of  K2  (blue),  and  K’2  (red),  are  the  same   •  Their  SHAs  are  different.   II.  Cherry-­‐picking  HoOix  into  develop  (at  the  beginning)  
9. What  about  cherry-­‐picking?   •  master  has  to  be  merged  into  develop  at  some  Lme   •  The  content  of  K2  (blue),  and  K’2  (red),  appear  twice   •  Merge  does  not  recognize  K2,  and  K’2,  are  the  same  thing   •  This  is  NOT  acceptable.   II.  Cherry-­‐picking  HoOix  into  develop  (at  the  end)  
10. Fine,  We  only  Use  Merge,  Now  What?   •  This  is  a  very  common  scenario   1.  A  hoOix  is  released  from  master   2.  A  feature  is  pull-­‐requested  into  develop   •  To  get  the  hoOix  from  master  into  develop,  we  can  only  use  a   non-­‐fast-­‐forward  merge   I.  Fast-­‐Forward  Merge  is  NOT  always  Possible  
11. Fine,  We  only  Use  Merge,  Now  What?   •  One  hoOix  on  master   II.  Non-­‐Fast-­‐Forward  makes  a  Complicated  Graph    
12. Fine,  We  only  Use  Merge,  Now  What?   •  Merging  master  into  develop  to  get  hoOix  code   II.  Non-­‐Fast-­‐Forward  makes  a  Complicated  Graph  
13. Fine,  We  only  Use  Merge,  Now  What?   •  Second  hoOix  going  into  master   II.  Non-­‐Fast-­‐Forward  makes  a  Complicated  Graph  
14. Let’s  Talk  about  Rebase   •  2  hoOixes  on  master   •  1  feature  on  develop   •  Goal:  hoOixes  into  develop   I.  Same  scenarios  as  before  
15. Let’s  Talk  about  Rebase   •  All  hoOixes  are  now  in  develop   •  K4  and  K’4  have  the  same  content  but  different  SHA   •  Same  thing  for  M5  and  M’5 II.  Rebase  develop  onto  master  to  Get  HoOixes  
16. My  Opinion   Please  have  your  pitchforks  and   torches  ready  
17. Why  I  like  Rebase     •  develop – master = features •  Graph  more  straight-­‐line-­‐ish  than  that  of  non-­‐fast-­‐forward   merges   I.  Graph  is  Super  Simple  
18. Weakness  of  Rebase  (Yes,  I  know  there  are  drawbacks)   •  develop,  before  and  a[er,  not  even  remotely  close.   I.  It  Re-­‐Writes  History!  
19. Our  Solu&on   •  It  takes  discipline,  but  it  is  achievable.   •  Comparison  between  develop,  and  feature,  will  clearly  show  the   added  feature.   I.  Rebase  Your  Feature  Branch  onto  New  develop  
20. Who  cares  if  it  looks  cleaner?   You  could  LOSE  code  when  re-­‐wriLng   history!  
21. Please  Remember  this  is  Just  My   Thought   No  Hard  Feelings…  
22. Re-­‐WriLng  History  is  not  Bad,  if   We  are  careful…   Resolve  all  conflicts  carefully!     And…  
23. You  Could  Lose  Code  in  Merge  as   Well   I  Dare  Say…  
24. Remember  this  Non-­‐Fast-­‐Forward  Merge?   •  Let’s  look  at  K5  and  M5.   •  These  2  commits  started  from  M2 •  M2  does  not  contain  any  feature  code  (i.e.  K4  and  M3)   •  And  therefore  K5  and  M5  doesn’t  have  feature  code  either  
25. Code  Loss  Could  S&ll  Happen   •  IF  K5  touches  the  same  area  as  K4…   •  What  prevents  M5  from  over-­‐wriLng  K4  and  M3?   •  You  s&ll  have  to  resolve  conflict!   •  The  same  pre-­‐cau&on  is  necessary  in  both  merging,  and   rebasing  methods.  
26. Shamelessly  “Borrowing”  from  EllioU   •  This  is  what  I  am  afraid  of   •  Yes,  I  know  this  image  shows  develop.  But  the  reasoning   is  the  same:   Merge,  and  then  re-­‐merge,  from  the  same  branch,   causes  problems  
27. Elephant  in  the  Room   How  does  this  discussion  affect  cross-­‐ team  projects?  
28. What  is  a  Cross-­‐team  Project?   1.  IntegraLon  Project   •  Team  A  owns  the  original  project   •  Team  B  wants  to  add  a  feature  to  it   •  Team  B  makes  a  PR  to  Team  A’s  Home   project   •  Team  A  reviews,  and  comment   •  Team  B  makes  changes  accordingly   •  It’s  basically  a  feature  branch  from  another   team   •  No  problem  rebasing  that   •  Team  B  doesn’t  care  how  Team  A  syncs  its   develop  with  master  
29. What  is  a  Cross-­‐team  Project?   2.  Greenfield  Project   1.  Both  teams  start  from  scratch.   2.  Since  it’s  brand  new,  everything  can  be  agreed   upon  beforehand.   3.  If  both  teams  are  used  to  “merging  master  into   develop”,  good,  let’s  do  that.   4.  If  both  team  are  used  to  “rebasing  develop   onto  master”,  why  not?   5.  If  they  think  differently,  pick  one.     •  Not  that  hard  to  get  2  team  leads,  and  have   them  reach  one  conclusion   6.  The  developers  on  both  sides  have  to  rebase   their  personal  and  feature  branches  anyways,   it  really  doesn’t  maUer.  
30. A  Team’s  Role  in  any  Given  Time   1.  Working  on  Home  project(s)   2.  Making  a  Feature  against  another  Team’s  project   3.  Working  on  a  new  project  with  other  Team  
31. My  Observa&on   1.  In  2  out  of  3  situaLons,  it’s  beler  to  respect  the   Home  team’s  workflow.   •  The  Home  team  has  the  domain  knowledge  on  that   project   2.  In  the  3rd  situaLon,   •  2  out  of  3  cases,  the  teams  automaLcally  know  how   to  work  with  one  another   •  In  the  last  case,  let’s  have  the  team  leads  talk  
32. My  Point   Flexibility  of  having  either   approaches  does  not  hurt   collaboraLon  
33. My  Humble  Opinion…  
34. Neither  of  the  2  Ways  are   Decisively  Beler   May  I  use  what’s  been  working  in  my   team?