30 Minutes to Merge: Git Branching Strategy

What: You’ve asked and we’ve listened. Welcome to the new “30 Minutes to Merge Series” a monthly 30 minutes training session, enabled by GitHub’s Implementation Engineers, live streamed via Twitch, with a followup up written Q&A right here in the community.

In this first edition we’ll learn from Implementation Engineer @aaugustine about branching strategy, releases and best practices.

A strategy that extends these concepts and avoids contradictions will result in a version control workflow for your team that is consistent and easy to follow.

Implementing the right branching strategy helps support your parallel development efforts (no matter size of your team or project).

Where: Twitch, Q&A to follow the presentation in this event topic.



Two days until kickoff! In this first edition Senior Implementation GitHub Engineer Matthew Desmond (he/him) will introduce us to the series, and then we’ll learn from GitHub Implementation Engineer Alexandra Augustine (she-her) about branching strategy, releases and best practices.

This will be fun! See you in two days.



Super excited to start off today! After the presentation on Twitch, please come on back to this event post for a written Q&A with Matt and Alex, there will be a swag giveaway :sparkles:

See you soon!



We are excited to be joined by Senior Implementation Engineer Matthew Desmond and Implementation Engineer Alexandra Augustine.

We are standing by live to answer your questions about the presentation. To submit a question, click “Reply”.

All participants will be awarded the new AMA badge and are eligible for a random swag drop (form link posted at the end)!


I posted in the chat:

When I first tried to merge from feature branch to develop, it said two files changed. Is that just because I followed along with the first exercise and merged into main?

Twitch user “surftocat” helped me out with this response:

I checked out your repo and PRs! main was updated with the new URL in the README, but develop still has the old version of the README. mattwelke/thirty-minutes-to-merge#3 has develop as the base, so you’ll see the README as a changed file. If you change the base to main, you shouldn’t see that file anymore since that README was already updated!

So does this mean in the real world I should merge main into develop (develop as base) so that it’s up to date? This comes up in my work a lot, and sometimes I get conflicts doing this, or new PRs from develop into main end up repeating all the commits (I heard from a coworker it might have to do with the fact we use “squash and merge” when we merge from feature branches into develop)?


Hey @mattwelke , so a best practice when working in a main and develop branching strategy is to keep the develop branch up to date with any changes on the main branch. An easy way to do that is to enable Branch Protections on the main branch and it will enable you to update any branch merging into main with the latest version of the main branch.


Oh wow I wish we would have known about that years ago. Probably our own fault, we should read the docs more… Thanks for the tip.

Side note, great webinar. It was super quick and dense with info, which works well for me. I can follow along and get back to work quickly, and revisit the video recorded later if I need to. I’ll join more of these.


Yea, here is a link for more information about branch protections: About protected branches - GitHub Docs

To enable the “update branch” option, you need to run a status check against the branch. This could range from an action to any tests that you are utilizing in CI/CD integrations you might be using. I’ve also “hacked” a status check by using a GitHub Action that just makes sure the PR description text isn’t empty.


A quick question,Where Can i get the topics that have been done in 30 minutes to merge?

Any references would be helpful!
My apologies if it is a dumb question
i’m new to this community


I like this suggestion also. We have several developers collaborating on a feature in separate branches under the feature branch and “sharing” among them has not been obvious. I’ll try protecting the feature branch in this way.


You are witnessing the inaugural episode!


Hi @markram1729 This was our first session! Stay tuned for more.


Hey @kylepoland-dcss , I would refrain from putting branch protections on the individual feature branches themselves, but I think you might have been thinking main/develop and typed feature. If you place branch protections on the feature branches, it can slow down some of the development processes and also potentially slam your feature branches with automated testing that is typically used at the feature to develop or feature to main.

If you do place branch protections on the feature branches, come back and tell us what the experience was like, would love to hear if it was successful :heart: .


As Andrea and Alex mentioned, this is the first session :smile_cat:

For anyone interested in pitching other ideas for future sessions, you’re welcome to share them in What would you like to learn? Looking for recommendations 👀.

We’re listening :ear: :sparkles:


Unrelated…but related! Alex, I’m obsessed with your shirt…So, the first reply with @beardofedu’s favorite color will get one in the mail :sparkles:


Did anyone try playing the JavaScript Tetris from the demo yet? It’s pretty awesome.

With 7 minutes left, anyone up to play and post their highest score? :wink:


I think he was describing branch protection on features branches, but only for “long lived” feature branches that multiple people are collaborating on. I had this come up when I was mentoring a new dev on the team. We had to manually keep our branches up to date with the “main” (lol) feature branch. It worked, but it’d be neat to be able to turn on something to keep our individual feature branches up to date and then turn it off later.


I like green. Is it green?