We use a variant of Gitflow without a develop branch and without release branches.
Gitflow has 2 major problems:
- develop branch that will always become a mess over time
- release branches are never completely accepted. It is much easier to accept features branches.
We try to merge feature/bugfix branches directly to master when they are approved.
We have testing/staging branches that can be thrown away and re-created from master and re-merge any feature/bugfix branches that have to be checked.
This has worked very well for the last 5 years or so and we have used it in dozens of projects every year.
The fact that testing/staging contains no commits (except merge commits) of its own is very useful. You can drop these branches regularly and remove any old feature branches that became stale for some reason.
Lastly, I have seen a lot of teams that want to apply complicated Git strategies from day one of a project where it would be much better to just work on one master branch because too much code changes at the same time. This will create complicated conflicts. The history at the start of the project is not interesting. Git history only becomes useful when the project is live and you want gradually add features or fixes.
Gitflow has 2 major problems: - develop branch that will always become a mess over time - release branches are never completely accepted. It is much easier to accept features branches.
We try to merge feature/bugfix branches directly to master when they are approved.
We have testing/staging branches that can be thrown away and re-created from master and re-merge any feature/bugfix branches that have to be checked.
This has worked very well for the last 5 years or so and we have used it in dozens of projects every year.
The fact that testing/staging contains no commits (except merge commits) of its own is very useful. You can drop these branches regularly and remove any old feature branches that became stale for some reason.
Lastly, I have seen a lot of teams that want to apply complicated Git strategies from day one of a project where it would be much better to just work on one master branch because too much code changes at the same time. This will create complicated conflicts. The history at the start of the project is not interesting. Git history only becomes useful when the project is live and you want gradually add features or fixes.