snippetgitModerate
How to get rid of develop branch for simplified Git flow
Viewed 0 times
ridsimplifiedflowdevelopgetforgithowbranch
Problem
In a continuously developed web project (not a product) we currently have the following branching strategy, roughly based on git flow:
Master is read only, updated via pull requests from develop or hotfix branches. Each update results in a release candidate being built and deployed to the staging system. Release candidates are deployed to production after manual approval.
Feature branches are created based off develop, or from the last commit that has been merged into master. A pull request from a feature branch to develop is built, deployed to a free test system where integration tests and acceptance tests (automatic & manual) are executed. When successfully tested and reviewed, the PR gets merged, so that it will become part of the next release (i.e. merge from develop to master).
My goal
I would like to simplify this and get rid of the develop branch. The develop branch has mostly historical reasons and since it is always a successfully tested version, I think it is unnecessary to keep it separated from master. Removing it will also simplify the release process because there is no additional merge anymore.
I have the following constraints:
Where I am not sure about the transition:
- develop branch: latest working version
- master branch: version to be released / released version
- feature branches: features in development
- hotfix branches: urgent bugfixes in released version
Master is read only, updated via pull requests from develop or hotfix branches. Each update results in a release candidate being built and deployed to the staging system. Release candidates are deployed to production after manual approval.
Feature branches are created based off develop, or from the last commit that has been merged into master. A pull request from a feature branch to develop is built, deployed to a free test system where integration tests and acceptance tests (automatic & manual) are executed. When successfully tested and reviewed, the PR gets merged, so that it will become part of the next release (i.e. merge from develop to master).
My goal
I would like to simplify this and get rid of the develop branch. The develop branch has mostly historical reasons and since it is always a successfully tested version, I think it is unnecessary to keep it separated from master. Removing it will also simplify the release process because there is no additional merge anymore.
I have the following constraints:
- releases are scheduled and should not be fully automated
- while feature branches are typically short lived, some stay unmerged for several weeks (e.g. a redesign) but need to be tested as well (currently as open pull requests to develop)
- sometimes a single feature should be released outside the regular release, effectively turning it into a hotfix. With the current strategy I can rebase a feature branch and merge it directly into master
- it also happens that we need to hold back features after acceptance tests with external systems on staging failed
Where I am not sure about the transition:
- currently I am buildi
Solution
Let's say you take out the master branch (you can rename develop to master to confuse your team if you like later) and simply use tags for releases either on develop or hotfix branches. You took out a branch, but the difference is just a change in syntax. Change for change sake.
Now let's say you actually take out develop with keeping the locked master branch. What will happen is that integration of code will slow, it will live longer separated in feature branches, especially close to release dates. This will Increase the difficulty of merging each time and slow the process down.
Within the constraints you have laid down I don't see any positive effects of making such change. It would require relaxing the constraints, especially the first one.
Now let's say you actually take out develop with keeping the locked master branch. What will happen is that integration of code will slow, it will live longer separated in feature branches, especially close to release dates. This will Increase the difficulty of merging each time and slow the process down.
Within the constraints you have laid down I don't see any positive effects of making such change. It would require relaxing the constraints, especially the first one.
Context
StackExchange DevOps Q#219, answer score: 11
Revisions (0)
No revisions yet.