Getting started with branching workflows, Git Flow and GitHub Flow

Hello everybody I'm Nick and in this video I am going to talk about the two most popular git branching workflows and those are Git Flow and GitHub flow. They have both been around for quite a long time and I have personally used them in a production capacity so in this video I will explain the flow for each workflow and then give you my opinion on them.

Don't forget to comment, like and subscribe :)

Social Media:

#branching #workflow #git

[JojiShawn]

Good video. One thing that could improve this video is having the lifecycle of the branches represented by drawing the lines of the branches shorter. Doing so helps one understand that in most cases branch is created only when you need it, then delete it when it is complete.

[joelporona]

Fantastic and super educational way for explaining the differences, cons and pros! I like using GitFlow when there's no maturity or understanding from the organization on how to work with repositories and enterprise applications, but I do see the point for GitLab Flow also for some other cases.

man, you're help me and my team a lot with your videos

[wieslawsamushonga]

Thanks for the short and concise explanation. Keep coding. Stay Beastly!!

[BooklyCrashCourse]

Very well explained! Nice job and thanks for the video

[abernardo]

We use the github flow strategy for 20 years now, in CVS. I'm switching to git just because it's more modern and has some advantages in speed and moving folders. Anyway I find it so funny that with some time and experience many including Atalassian have come to the conclusion that less is more and avandoned Git Flow! Thanks for the clear explaination! Great video!

[shakthifuture]

Thank you for the excellent explanation.

[mr_phamtastic]

Thanks for this video! Interesting to hear about github flow!

[sagidelriego]

Hi Nick Good Video, Now I can anderstand Git Flow Thanks so much 🙌

[eccololo]

Thank you very much. This video is really helpful 🙂.

[IanWilkinson-SgtWilko]

Would be good to see a comparison to the Release flow that Microsoft use with azure.

They have a blog describing the issues with GitHub flow and why they use release flow.

[diego_samano]

The big challenge with branching workflows is your deployment/release process and of course the development lifecycle. Any approach lacks when for some reason (business rules, deprecation of any library, framework or technology, etc.) a feature needs to be rolled out or delay.

[Bennevisie]

I see a lot of videos being made about Git flow and Github flow, but not enough quality content on Trunk based development in conjunction with feature flags. I would love to see you do a video on this topic.

[RohitMoni]

Thanks for the video, hadn't heard of github flow before but can definitely agree it makes a lot of sense for smaller / more isolated codebases with quicker release cycles (like microservices).

On viability for different types of projects, I have a question for you: I've found that git flow (and github flow too) both work very well for a lot of products but both make the assumption that your product has a single active release stream. Some products might actually have multiple release streams going at the same time, potentially for different platforms, or operating systems, or simply because users use your product as the base for their work and don't want it changing too much underneath them. How would you modify your git branching to accommodate that?

[georgehelyar]

Where I work, we use trunk based development (continuous integration), not feature branches. People create short-lived branches (branches only exist locally for a few hours, and only exist remotely during the pull request), make some changes, and commit them to the main branch through a pull request. The main branch is always in a state where it can be deployed, because new features are hidden behind things like feature flags or endpoints that just aren't being called yet, and every commit into the main branch runs the automated test suite for that repository - if the tests don't pass, the pipeline does not output anything that can be deployed. When it comes time to actually release, we tag with a version number and it gets deployed to staging and then to production (we aren't quite at the stage of full continuous deployment yet)

[Philinnor]

Could you do a video on Kafka or other similar tech in the context of decoupling microservices from a monolith database?

[vgavrilyuk]

I would not be so sure of safety of GitHubFlow, e. g. simply rollback might be not enough. Sometimes a buggy feature can make multiple changes in application data that would be incorrect and would need to be manually adjusted.
Hense we use GitFlow + feature toggles. We get nice controlled releases of say 5 features and if 1 of them misbehaves we simply turn it off and let release be on prod - full spead ahead, no rollbacks!

[yurin]

I was just talking about this with a colleague right now. Universe scares me.

[tobiaskolb]

We also evaluated GitFlow for our process but GitFlow does not handle multiple versions in the wild out of the box. One active version might work with App development but not with some desktop applications where customers do not use the latest version, because they just not bought it and are mostly fine with the previous version. But they also require bug fixes so multiple versions have to be in focus in the flow. So we adapted GitFlow to our needs, which involves picking fixes to other releases and of course develop(ment) branch.

[ryan-heath]

What I don’t like of gitflow are the multiple merge commits. This can lead to different code in the branches if the merges are not done consistently.

For instance the merge of the hotfix into main can been done differently as the merge to develop. Now your main and develop are different while from the history tree it would seems as if they would be the same.