Alternatives to git-flow for managing frequent releases

Question

I'm wondering what git branching / release strategies folks are using and would recommend for a project with the following requirements:

1. Frequent release (weekly release trains)
2. Ability hot-fix any time
3. Fairly complex/large project with frequent product changes

We've tried using the Git-flow process (http://nvie.com/posts/a-successful-git-branching-model/) but had two main issues with it:

1. The code we test against at any point during the release branch isn't exactly the same as what will be released (since the release branch needs to get merged with master at the end)
2. Refactoring changes are hard to deal with and will often result in merge conflicts when the release branch merges with master.

Are there any other git workflows that would be suitable for this situation or how are others overcoming these issues with Git-flow?

Answer 1

The code we test against at any point during the release branch isn't exactly the same as what will be released (since the release branch needs to get merged with master at the end)

This doesn't make sense. The merge between release branch and master branch should essentially be fast-forward only - your master branch should be dictated by your releases, not the other way around.

Refactoring changes are hard to deal with and will often result in merge conflicts when the release branch merges with master.

See above for your release branches dictating master branch. In addition, you can try rebasing your feature branches as you develop as long as you do not rebase any commits from before the branch split off point.

Before merging your branch into develop, you should rebase the develop branch on top of the feature branch, so that when you merge the feature branch into develop in you get a fast-forwardable merge with no merge conflicts. You should be doing this periodically during development (perhaps once every day to a week depending on the volume of commits in your repository).

If you are refactoring after features have been complete and you are simply refactoring the develop branch then, yes, you should expect merges to be hard.

However, having merge issues when you are merging a release branch into master, or develop into a release branch, is indicative of not following the linked flow correctly.

Answer 2

As far as alternatives,

GitHub Flow

GitHub Flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly.

• Anything in the master/main branch is deployable
• To work on a new feature, create a descriptively named branch off of master
• When you need feedback or assistance, or you think the branch is ready for merging, create a pull request
• After someone else has signed off on the feature, you can merge it into master
• Once it is merged and pushed to master, you can and should deploy