Git patterns and anti-patterns for successful developers

Play Git patterns and anti-patterns for successful developers
Sign in to queue


In this session we show how to use Git in teams with pull requests and how to use branches to manage your releases. In this session we will compare GitHub flow with the 'Release Flow' practised at Microsoft.



Session Type:





Expo Hall Theater 2



Right click to download this episode

Download captions

The Discussion

  • User profile image

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

  • User profile image

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

  • User profile image
    Lee Tickett

    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.

  • User profile image
    Aaron Toth

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

  • User profile image

    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.

  • User profile image
    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.

Add Your 2 Cents