Finding a good development and review strategy

Isn't the "main branch" usually called the trunk? A "branch" is inherently something off to the side of whatever is the "main" thing in the context in question.

I've struggled to understand whether what you are describing is a 3-line setup with a trunk, an acceptance branch, and a development branch, or whether you are describing a 2-line setup with a trunk and a development branch.

That said, you seem to have identified the problems with each of the two approaches you describe. Effectively, you cast it as a choice between features always being reviewed individually and drip-fed to acceptance, and features always being reviewed and fed to acceptance as a block.

There isn't really much latitude between these approaches except to pick your poison.

I think a third way is to think intelligently about whether features interact or not, and either consolidate these as a unit of work handled by one person (so that the drip-feed approach still works), or decide which features developed separately occasionally might interact and have to be treated as a block (so that you deviate from drip-feeding sometimes).

It's worth saying though that when you have a multi-person team doing tests and assurance and code reviews and all the overheads of team communication and dealing with acceptance feedback from colleagues or clients, a day or even a week for a full unit of change doesn't add up to much actual substance of change.

I'd be more concerned about interactions between features that are committed months apart - for example, where one developer proceeds from an outdated understanding of workings that another developer has since changed - rather than interactions between contemporary features. Because the separation of time makes it less likely anyone will identify that the interaction exists, or will be looking at the areas where an adverse interaction would reveal.

Anyway, if something does slip through the cracks of your current process, then when you just sweep the ceremony aside and buckle down to either fix it, or to reverse the application to the last stable configuration, then it often doesn't take much time or effort.

It must be remembered that the purpose of various assurance activities is not to achieve perfection, but to ensure that the consequences and likelihood of design mistakes are limited to acceptable levels. A tetanus shot for a nail through the shoe, or a plaster for a paper cut, rather than cleaning up the fallout of a dirty bomb.

That orientation should be borne in mind.

It should also be remembered that ceremonies and checks consume valuable time and attention, and typically compete for cognitive resources against more essential activities like correct coding and intelligent risk-analysis of changes. Changes in processes, once embedded, also upset rhythms and habituation, and can lead to a spike in errors as more subtle thoughts are displaced by the attention needed to cope with the upheavals.

When considering a change to your existing process, you should think about whether you've identified a serious problem with a straightforward solution, or whether you're fussing at the margins and should relax into a system that is already reasonably well-able to cope.

GitFlow is a widely used solultion to these type of branching problems and often the answer to them is "just use gitflow". However.

Process 1 : Here you have a flaw in that you are merging your feature branch into two parents, one of which is a child of the other. This will cause merge conflicts when you attempt to merge dev into main as you point out.

Process 2 : This looks better until you realise you are using main as your acceptance branch. What happens when the customer doesn't like it?

My suggestion is an abbreviated gitflow

• devs work on feature branches, test locally and merge (with review) into dev

• dev branch is auto deployed to dev env on build

• Each week/sprint you ensure any bugs on dev are fixed, you create a ReleaseX branch from dev and deploy it to your acceptance test env for testing with the clients

• Bugs from acceptance testing are fixed on the release branch and dev branch separately with feature branches and reviews. Or, you might choose to abandon a release branch and just make a new one from the latest dev

• When the release branch is approved it is merged into main and deployed to Live.

Pros:

• Each feature merge has its own review
• dev branch contains all features for internal testing
• acceptance env is stable, doesn't have the latest dev commits
• main always contains fully tested and accepted code.

Cons:

• The release branches are a bit floaty, you create and discard them
• when you fix a bug in a release branch you also have to remember to fix the same bug in dev. This isn't automated.
• when you have changes in a release branch they may cause merge conflicts which you will need to resolve by merging either the release or the main branch back up to dev.

Process 2 sounds better. I don't think review is needed for merging dev to main. At some point you should decide "dev is now stable" and then PR is just formality.

If anything bad happens on the acceptance environment, then this means that the testing process on the dev environment needs refinement. Not only "it passed unit tests", but also integration tests and finally some manual testing.

The divergence of two environments in the process 1 is a deal breaker for me. This is extremely important. I've worked with such setup, and I constantly had to do twice as much work to maintain both environments. The horror.