<p>You're bringing up a big pain point - and there are 2 camps here, people who do GitFlow and people who prefer other approaches (with TBD being most popular).</p>

<p>Personally, TBD with release branches is something I would always prefer, but you can find lots of other people who would tell you GitFlow is better - so you'd have to decide for yourself.</p>

<p>In your case TBD would work as following - you keep committing to your master, however before release time you cut a release branch out of master. Once you do that, you don't have to code freeze master and your developers can keep working there.</p>

<p>Some materials for research:
On Gitflow - <a href="https://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow noreferrer">https://nvie.com/posts/a-successful-git-branching-model/</a></p>

<p>On TBD - <a href="https://trunkbaseddevelopment.com/" rel="nofollow noreferrer">https://trunkbaseddevelopment.com/</a> (especially check "Scaled Trunk-Based Development" section)</p>

<p>Critics of Gitflow (note that myself I'm biased towards TBD) - </p>

<ol>
<li><a href="https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/" rel="nofollow noreferrer">https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/</a></li>
<li><a href="https://medium.com/@mattia.battiston/why-i-love-trunk-based-development-641fcf0b94a0" rel="nofollow noreferrer">https://medium.com/@mattia.battiston/why-i-love-trunk-based-development-641fcf0b94a0</a></li>
</ol>

CC BY-SA 4.0
2020-04-16T20:21:18.367Z
Thanks! I think GitFlow would be a little too cumbersome for nightly deploys, especially with an eye toward CD. Cutting release branches in a TBD-based model might make sense for less frequent deploys, but it doesn't address well the question of UAT (QA) rejection—what happens if a change in a release branch is declined or deemed to need extensive revision?

I'm envisioning something in the middle, more like gitworkflow: https://github.com/rocketraman/gitworkflow

which would allow us to integrate branches on master only *if* they pass UAT, with a throwaway environment for QA.
Alex Ball
CC BY-SA 4.0
2020-04-16T21:07:56.920Z
> what happens if a change in a release branch is declined or deemed to need extensive revision --

Ideally, you don't change release branch at all apart from critical (i.e. security) fixes. So you do all your testing before cutting release branch.
taleodor
CC BY-SA 4.0
2020-04-16T21:52:04.243Z
Makes sense. This may be more of a people problem, but UAT delay for any particular issue would run the risk of either delaying the release branch cut, or introducing bad code into the release branch. While we work to improve automated testing coverage and reduce reliance on UAT, I'd lean toward a topic-branch-based paradigm, where topics are individually *promoted* to a UAT branch/environment and later to master, rather than scheduled release branch cuts, so that only accepted topics make it to master. We don't quite have enough test coverage to make me comfortable with full TBD, either :(
Alex Ball
CC BY-SA 4.0
2020-04-16T22:17:54.267Z
I think this explains my current idea best: https://medium.com/@sairamkrish/git-branching-strategy-for-true-continuous-delivery-eade4435b57e
Alex Ball
CC BY-SA 4.0
2020-04-14T01:10:52.163Z
2020-04-14T01:10:52.163Z
taleodor
<p>I'm a lead developer for a small B2B SaaS company, using Django and AWS. We currently run biweekly deploys after hours with a mostly-automated custom Fabric-powered tool.</p>

<p>We're currently exploring options for moving to fully-automated nightly deploys, but want to move to a different branching model to support this.</p>

<p>Right now, topics are branched from dev and merged to dev, a long-running branch which is merged wholesale with --no-ff into master during the biweekly prod deployment process. This necessitates a feature freeze on release days, to ensure that broken code isn't merged right before a release, and isn't really a great solution.</p>

<p>My current plan is to move to a more branch-oriented workflow, similar to Gitworkflow: <a href="https://github.com/rocketraman/gitworkflow" rel="nofollow noreferrer">https://github.com/rocketraman/gitworkflow</a>. This would allow us to merge feature/bug branches individually to dev, then only merge to master the branches (corresponding to Jira issues) that have passed manual QA.</p>

<p>Is this a good approach?</p>

<p>In my mind, there are a few potential open questions, like how to handle issues/branches which have failed QA, and should be removed from the dev branch/environment. I suppose that instead of reverting commits, we could then "refresh" the dev environment by overwriting it with master, and re-merging all branches currently undergoing QA...</p>

<git><deployment><continuous-delivery>
Branching model for nightly deploys
Alex Ball
# Branching model for nightly deploys

(Asked by: username_0 on 2020-04-13)

I'm a lead developer for a small B2B SaaS company, using Django and AWS. We currently run biweekly deploys after hours with a mostly-automated custom Fabric-powered tool.

We're currently exploring options for moving to fully-automated nightly deploys, but want to move to a different branching model to support this.

Right now, topics are branched from dev and merged to dev, a long-running branch which is merged wholesale with --no-ff into master during the biweekly prod deployment process. This necessitates a feature freeze on release days, to ensure that broken code isn't merged right before a release, and isn't really a great solution.

My current plan is to move to a more branch-oriented workflow, similar to Gitworkflow: <https://github.com/rocketraman/gitworkflow>. This would allow us to merge feature/bug branches individually to dev, then only merge to master the branches (corresponding to Jira issues) that have passed manual QA.

Is this a good approach?

In my mind, there are a few potential open questions, like how to handle issues/branches which have failed QA, and should be removed from the dev branch/environment. I suppose that instead of reverting commits, we could then "refresh" the dev environment by overwriting it with master, and re-merging all branches currently undergoing QA...

**Tags:** git, deployment, continuous-delivery


---

## 1 answers

### Answer by username_1 on 2020-04-14. Score: 2

You're bringing up a big pain point - and there are 2 camps here, people who do GitFlow and people who prefer other approaches (with TBD being most popular).

Personally, TBD with release branches is something I would always prefer, but you can find lots of other people who would tell you GitFlow is better - so you'd have to decide for yourself.

In your case TBD would work as following - you keep committing to your master, however before release time you cut a release branch out of master. Once you do that, you don't have to code freeze master and your developers can keep working there.

Some materials for research:
On Gitflow - <https://nvie.com/posts/a-successful-git-branching-model/>

On TBD - <https://trunkbaseddevelopment.com/> (especially check "Scaled Trunk-Based Development" section)

Critics of Gitflow (note that myself I'm biased towards TBD) -

1. <https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/>
2. <https://medium.com/@mattia.battiston/why-i-love-trunk-based-development-641fcf0b94a0>

> **Comments:**
> **username_0**: Thanks! I think GitFlow would be a little too cumbersome for nightly deploys, especially with an eye toward CD. Cutting release branches in a TBD-based model might make sense for less frequent deploys, but it doesn't address well the question of UAT (QA) rejection—what happens if a change in a release branch is declined or deemed to need extensive revision?  I'm envisioning something in the middle, more like gitworkflow: https://github.com/rocketraman/gitworkflow  which would allow us to integrate branches on master only *if* they pass UAT, with a throwaway environment for QA.  
> **username_1**: > what happens if a change in a release branch is declined or deemed to need extensive revision --  Ideally, you don't change release branch at all apart from critical (i.e. security) fixes. So you do all your testing before cutting release branch.  
> **username_0**: Makes sense. This may be more of a people problem, but UAT delay for any particular issue would run the risk of either delaying the release branch cut, or introducing bad code into the release branch. While we work to improve automated testing coverage and reduce reliance on UAT, I'd lean toward a topic-branch-based paradigm, where topics are individually *promoted* to a UAT branch/environment and later to master, rather than scheduled release branch cuts, so that only accepted topics make it to master. We don't quite have enough test coverage to make me comfortable with full TBD, either :(  
> **username_0**: I think this explains my current idea best: https://medium.com/@sairamkrish/git-branching-strategy-for-true-continuous-delivery-eade4435b57e  

---

