CODEWITHSUNDEEP
gitgithubpull-requestgit-flow
scc
scc

Reputation: 10696

Workflow for handling pull requests in a gitflow workflow (with infrequent releases)?

Our previous workflow was similar to gitflow, everything is branched off master, master always reflects production. When a release is being prepared, the feature branches are merged into master, possible conflicts between different features fixed, create a tag for the release, push to master and that's it.

So now we'd like to integrate pull requests into this workflow, but let the developer of the branch remain responsible for fixing conflicts. The idea was then to still branch off master, and then do a pull request to a new branch, called releaseX, where all the new code that is going into the next release is.

The problem is that when there are conflicts in releaseX between the new feature and the other features, how does the developer fix them? Doing the merge in github itself is not acceptable, merging releaseX into the feature branch is not either (it would pull in unrelated features and it would make it harder for a feature not to go into production after all).

What we ended up with was creating a branch just for the merge, something like resolution/releaseX_my_beautiful_feature.

(For now, following more of a githubflow like model (instead of gitflow), with continuous deployment and no real concept of releases, is not the best solution for us.)

What workflow do you guys adopt when using both pull-requests and releases?

Upvotes: 3

Views: 4226

Answers (1)

scc
scc

Reputation: 10696

As @ckrusek said Atlasssian has a nice document on the different kinds of workflows. Regarding a gitflow + pull requests workflow what they recommend is:

  • features branch off develop
  • features do a pull-request to develop
  • releases branch off develop (branch naming convention: release-* or release/*). Release branch serves only to prepare the release, any functionality that is not already in develop is postponed until the next release cycle.
  • merge release branch into master and develop
  • maintenance/hot-fixes branches branch off master
  • maintenance/hot-fixes branches merge into master and develop

Of course, there's still no way to not mix unrelated features in develop into our feature branch.

Basically a pull requests workflow implies more frequent releases and to handle these we need to have feature flags in order to turn off not-quite-so-tested features in production if needed. What this model gets us is a workflow that does incorporate the concept of releases and a way to manage them.

Upvotes: 3

Related Questions