New git-reflow release: new “refresh” command and API stability

Today we released version 0.8.1 with some pretty fantastic improvements. We are inching closer to a stable API as we work towards making it easier for people to extend git-reflow to customize your git workflow to better fit the needs of your team.

New features!

With a new minor version comes a new feature! Introducing:

git reflow refresh

Keeping projects up to date when you haven’t worked on them in a while can be frustrating. Say a feature’s deadline has been moved and the branch has stayed open while your team has prioritized other features. Coming back to that old feature branch can be a pain to get updated. First you check out your production branch and make sure it’s updated. Then you check out the old feature branch and make sure it’s updated in case any other developers have worked on it since you last did. Finally, you merge up any changes from your production branch. This is just one scenario, but there are plenty of other cases where you just need your feature branch to be the latest and greatest as if you were to deliver it. Now with one easy command, you can make sure your branch is in sync with the rest of the team.

Always start a feature branch from master

This one has been long overdue, but from now on we will always start a new feature branch using git reflow start by first checking out your master branch. Need to use a different base branch? No problem:

git reflow start vs-007-awesome-new-feature --base develop

You can now use a non-terminal editor

We realize that not all developers have a preference for VIM, so we’ve added documentation for how to setup and use an editor of your choice, including non-terminal editors like Atom.

Set a required number of approvals needed during review

We’ve added a new git-config option (reflow.constants.minimumApprovals) to override the number of approvals (LGTMs) that a developer needs before they can deliver a feature. You can configure this by just re-running the setup command:

git reflow setup

And entering the number of approvals (LGTMs) you want to enforce for your reviews, when it asks.

Set the minimum number of approvals (leaving blank will require approval from all commenters): 2

Setting this value to zero will allow you to skip the enforcing of a review. This is handy if you’re working alone. We recommend if you do this to set it on a project-specific level by providing the local flag from within your project’s directory:

git reflow setup --local

(Potentially Breaking) Changes

We’ve made a couple changes to the code base and process that you should be aware of.

Dropped support for Ruby 2.0

Ruby core has dropped support for 2.0, so we no longer are testing against that version of Ruby. Git-reflow may work for 2.0, but we can’t guarantee it.

Git-reflow no longer asks to open URLs

Seth Ladd had requested an option to suppress the constant nagging to open URLs in a browser. After an internal discussion, we found no one on our team had used the feature, and as most terminals provide a way to click-to-open a URL, we have removed this feature from git-reflow.

Updates to the Github merge process when delivering

We have made a fairly significant change to the way we are delivering code on Github. We have opted to offload the squash-merge to Github via their API in order to take advantage of their pull request state labeling. Because of this, your pull requests will no longer appear `closed` but instead will show `merged` (a huge thanks to @simonzhu24 for this).

For now, if you prefer the prior method of manually squash-merging locally, just use the force flag (`-f`) when delivering.

For a full list of changes, please reference our CHANGELOG.

Happy coding!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.