What to do with GitHub Flow before initial deployment so main branch is "always deployable"?

Question

So GitHub Flow seems to advocate keeping the main branch as the only permanent branch and sprouting off and merging ephemeral feature branches. It also says main should "always be deployable". What do you do while you're still building towards your first deployment? Do it all in one feature branch and then merge that into main, or just not worry about it and have non-deployable code in main for a while?

Answer 1

Note: Branching strategies are just guidelines.

GitHub Flow works best with CI/CD, which usually means you will deploy soon after features are merged. In theory you may have to lock down the main branch temporarily between validating what you're about to deploy, and when you deploy it, so that nothing slips into main during that time that hasn't yet passed the fully integrated validation. If your release cycle is fast enough this is relatively low impact.

However, if you have a long release and/or validation cycle you may want to look at other workflows. Perhaps the most common alternative from which many other flows are based, is Git Flow, which allows for taking time to harden and validate release branches, as well as simultaneous development of new features while the release branch is baking, without requiring code freezes.

Another good alternative is gitworkflows. The basic idea here is you make a temporary copy of main, called next, which is used for partial integration testing until your feature branches are ready to merge into main, and then periodically you reset next back to main to clear out the old commits that didn't make the final cut.

At my organization we use all 3 of these workflows (and others), and the choice mostly depends on the length of the release cycle of each product.

If you have a long(ish) release cycle and wish to stay with GitHub Flow, you could do as you suggested and use an extended feature branch. Note if you do this it would technically be more accurate to call it a "release" branch, since multiple "features" would likely be present on it. At this point you wouldn't really be doing GH Flow anymore, but I'm pretty sure the Git Branching Strategy Police won't come knocking on your door.