Idea: git reflow promote <promotion branch>

[pboling]

I would like to have a simple command that would do the work of the following manual process to promote a PR from the branch the work was originally done on, to a more forward branch, like a prod hotfix, due to an emergent crisis.

The manual steps to migrate a given feature branch from development to quality, where quality lags behind development generally, are:

1. First restore the feature branch using the Github GUI

2. Checkout the branch that was the base branch of the feature branch as it may have changed since, and commits ahead of the feature branch may have also been merged to the promotion branch, thus burying the feature. Assuming the base branch was development:

   git checkout development
   git pull

3. The branch to promote to may also have been updated, lets say we are promoting to a branch called quality:

   git checkout quality
   git pull

4. Checkout the feature branch to your local, and rebase onto it to unbury the feature’s commits. Just locally, no need to change the remote, this is just a means to an end:

   git checkout issue/WR-1234-something # the original
   git rebase development

5. We don’t want to destroy the remote feature branch that is still based on development, so we now checkout a new promotion branch that we can push without clobbering the original, appending _promoted-to-quality to the branch name for clarity:

   git checkout -b issue/WR-1234-something_promoted-to-quality

6. Then rebase the promotion branch locally so it sits on top of quality instead of development (without moving any of the new commits in development, only the ones from the branch itself):

   git rebase --onto quality development

7. Push this new branch to remote origin:

   git push

8. It will fail and tell you that you have to set the upstream when you push, and give you a command to do that. Copy it, paste it and run it.
9. Create a PR from that branch to quality, label it appropriately (quality and hotfix).
10. Make sure it looks like the right change set, and if it is then merge. It has already been reviewed, so just do a sanity check yourself.

CC What do you think? @simonzhu24 @codenamev

[codenamev]

I'm not sure this is a workflow we want to support. It sounds like you've adopted this branching model?

Our workflow has been adopted primarily from Thoughtbot and GitHub (Zach Holman from GitHub gives a great talk on their process). Scott Chacon from GitHub also has a great article on GitHub's workflow as well. The basis of reflow revolves around the premise of continuous delivery. In other words, features are built, staged, and then deployed to production. For longer running "in progress" features that require many moving parts, we prefer to use "feature flags". This allows us to constantly deliver features in an Agile way.

We came across the git-flow gem when we first set out to automate our process, and we weren't happy with the complexity of that branching model. We created reflow so that we could simplify the model into three easy to understand branches: master -> features -> staging.

We have experimented with long running development branches for specific features. A perfect example of this being Rails upgrades. We've had to upgrade systems running on fairly old versions of Rails and chose to create separate base branches for each major version upgrade, and then branch off of that to group changes to keep reviews manageable. Once the major version upgrade was complete we then delivered to master. We found that keeping long-running branches like this was difficult to maintain and found that there were more and more merge conflicts as a result of updating the various branches. Now we have opted to make the deliverable feature set smaller by tackling minor version upgrades and delivering each as they are completed. There are plenty of other scenarios (outside of Rails upgrades) where breaking the feature set into smaller deliverable features (sometimes needing to use feature flags) yields similar advantages and is where we have moved.

I think introducing this feature would introduce a branching model that we don't want to support. Can you share some advantages that I may not be seeing?

[pboling]

Yes, we are using a modified version of git flow. I don't think, at this point, git reflow is very opinionated as to branching strategy. With the command line override for base branch any strategy can be supported.

Promoting a feature built against one branch to another branch seems like a widely applicable scenario to me.

We have always expected that our use case would differ from yours and forking is likely on our road map. We are hoping to delay the fork as long as possible, and hopefully, instead of forking the core of git-reflow, just create gems to extend it.

Continuous deployment is awesome, but poses some significant hurdles to a business such as ours. Those hurdles are insurmountable in the short term for us.

So I think perhaps I can make a git-reflow-promote gem that adds this additional command.

[codenamev]

I do see the value in having a command like this using your branching model. Since this is not something we use, we would most likely not maintain it very well if we were to bundle it in the git-reflow core.

I think this is a perfect opportunity to introduce a gem-based extension library. We love seeing the different ways companies large and small choose to automate their workflow, and I see a lot of value in git-reflow staying small and as a core that can provide the basics.

Feel free to reach out if you need assistance putting the gem together. We would be more than happy to promote the extension in the README. Once it's done let me know and I'll put something together 😄

[pboling]

👍 I will work on this over the next few weeks.