It’s time to let the develop branch go if you are not the person who does all the development.
All of it.
That’s a situation one often sees in a corporate, enterprise if you wish, scrum-ish like environment. It’s not you who control the release in terms of what goes in, and that is the spot where the whole concept of the development branch in a form of a future version makes no sense at all.
Let’s imagine a typical scrum-based web-application you are making/supporting with your fellow team at [Name of the company]. Your tasks are organized in Jira, you use Github for Enterprise and you are following the GitFlow strategy (which is beautiful). And you merge in Develop.
The definition of the problem
- It’s not necessary that everything you do during the sprint will get to the release
- It’s not necessary that everything you do is ever meant to be released in this iteration
- You and your teammates will still want to get their code merged, even if their code is planned for the next iteration
And that’s what it causes
- Eventually you must manually pick the release and apply patches manually when the Release day happens, thus creating the version of code which was in fact never tested by developers who were introducing new features. It’s a whole new unseen universe.
- The worst thing: you may have to delete something, thus not only creating the unpredictable universe, but also making it possible that you will forget something along the way. This something will surface in production the day after. This outcome often tends to happen at night.
- The very existence of the Develop branch acts as a confuse point: it lets you to skip the thinking about target release of the feature you are working on. It lets you to skip talking to the business you are working for (yes, sometimes it’s uncertain what is a target release for a feature).
How you can fix it
Delete the develop branch. Let it go.
It’s just a concept of a future release which you shouldn’t be paying for.
Keep only release branches. Target your pull requests to release branches. Feel free to merge older release to the newer release when it’s comfortable for you and your team. Make it a rule: new version is deployed, merge the code to the next release branch. When it’s uncertain what target release is: ask the stakeholders. Revert the code of a feature as soon as its target release has changed (if it’s too soon for a feature to go): make sure the stakeholders understand the price of rebasing a feature.
Start thinking again. Keep release branches forever. Use tags to keep track of your releases. Keep minor changes in your release branches. Let the develop branch go (make sure that the master branch goes with it).
There is no concept of a default develop branch for you? You are free to not have it whatsoever.
You could probably start thinking about feature flags, but i would suggest to think twice, as it never comes out to be cheap. Each feature state is the same untested universe again.
Originally posted on Medium: https://medium.com/@nettsundere/its-time-to-let-the-develop-branch-go-f69243d546a9