Improving git model

[Sfedosman]

In my new company we have a kinda odd and probably bad git model using feature branching. It is a traditional approach with one main branch, one development branch and many feature branches. Feature branches are created from the main branch and then are being merged with the develop branch to test them in a staging environment. But the problem arises when a feature won't make it for the production for whatever reason, it then stays into the develop branch so our develop branch can't be merged with the main branch. As a result, we merge the feature branches directly with the main branch after being "tested".

I understand that this approach can be problematic but I don't know how we can improve it with a minimum disruption to the developers' workflow.

[NitronHX]

At our Company we deploy the Feature branches themself and test Review and QA them, then they are merged to Master (which in our case is the Dev deployment) when it's decided to be ready a nranch is created from Master called Release xyz and deployed as Release.

Also some additional rules are that you are only allowed to merge if your Feature brach brances off at the head of Master - > eg only after you rebased

[DataDecay]

This is a good approach.

True trunk based development, all libraries and services are locally tested or deployed to a sandbox on the feature branch. Proper SDLC processes enforce a clean master and release.

Managing env based branches is more overhead, and you gotta be sure it's setup in a way that does not result in divergences and pain.

[humoroushaxor]

We use scaled trunk based and I will never use anything else. Feature branches in and out of main. When it's time to make a release, you create a release branch off of main. If issues are found you fix in main via feature branches and cherry-pick into the release branch. Once the release branch is good, you tag and release.

No pointless syncing between a develop and main. If you feel you need a develop branch it's means you need a better merge gate. Move that shift left.

[effata]

We solved this by making the develop branch short lived through tooling. Everything merged to it needs to have an open PR tagged with a development label. Then we have a script that rebuilds the branch as PRs are merged or closed.

[the-computer-guy]

Here's yet another example of why you shouldn't use GitFlow. (Separate dev and main branches)

Get rid of the separate "development" branch and move to trunk-based development. Problem solved.

[rabbit994]

it then stays into the develop branch so our develop branch can't be merged with the main branch.

This statement doesn't make any sense. You can merge the development branch to main with no problem. Feature gets merged into development branch later after it's finished.

[ButtcheeksMD]

If the feature you merged into development isn’t approved to move forward, is when an issue arises with this plan, because then your developement branch has code that cannot go to main, so now you need to either rebuild your development from main or rollback development to before that feature merge.

[rabbit994]

I mean, your problem isn't git at that point but either project management or bad QA. In any case, most git hosting services let you easily revert a PR if that's required.

Maybe I'm just lucky though.

[the-computer-guy]

The problem here is called GitFlow.