Git patterns and anti-patterns for successful developers

The Discussion

• 

  Bonjour,J adore votre coopérative et je souhaite d etre particepant aavec vous MERCI ABDOKADER.

• 

  Very helpful and much easier to understand than the average git talk!

• 

  Interesting watch. We do something similar but it seems a little more intuitive than your solution;
  
  We have a dev branch which everyone feature branches off then raises pull/merge requests once code is ready to merge back into dev.
  
  However, when we are ready to publish/deploy we raise a pull/merge request into master. So master always tracks our production build(s)- no need to spin up MXXX branches and destroy them as you do.
  
  One topic you didn't cover, which I would be interested in; How do you handle your merges? We try to rebase before merging to avoid any conflicts but haven't mastered the rebase process yet. I think we may be over complicating things and should maybe just merge and handle the conflicts.

• 

  I liked the video and it was nice to see this strategy being advocated again.
  
  

• 

  This seems a bit convoluted and not all that intuitive.

   

  Personally, I prefer the way GitFlow works. It seems much more straight forward and intuitive.

• 

  Very nice demonstration. But creating a release branch just for the purpose of the release and pulling changes from master seems to be bit counter intuitive. The approach described in Gitflow makes more sense. It would have been great if the presenter could elaborate on the need for release flow and why not just stick with Gitflow.