Should I ever have long-term feature branches in Git Flow?

Question

I am using Git Flow with a team. We all branch off of develop for features and merge back in after code review. It works well for us, however we now have one feature that will take a developer over a month to complete. We will have a few releases over this time.

A few questions to fuel this:

• How should we handle this?
• Should we handle it this way?
• Or should we chop the feature up into smaller merge requests?
• If we chop it up, and it is a public project, how do we ensure that pieces of this feature don't affect the ongoing releases?
• Is merging develop into this long-term feature branch really that bad? My peers are concerned that it is anti-pattern.
• If we don't merge develop consistently back into this long-term feature, couldn't there be bad consequences when the feature is finally complete?

Cormorant

It's an interesting question, albeit a subjective one. The usual recommendation - don't use long-term feature branches, break up all the features into smaller components - is nice in theory, but doesn't work that well in practice, unfortunately. – Marimaria

You could also merge master into your feature branch every week to ensure that your feature branch always works fine with latest master – Diocesan

Answer 1

This is pretty common in my workplace as well. We work on a weekly release schedule, so each Wednesday new features hit production. Because of this, there are almost always features half-baked, and not production ready.

So, in regards to long-term branches, here's what has worked best for us:

• Branch off for the feature as normal (feature-1)
• With the feature-1 branch cut, work begins as normal.
• If the feature is large enough, break into smaller sub-tasks. (For example, Create a service; Implement service into controller; etc.)
• Then branch off feature-1 for each incremental update to the feature (sub-task-1, sub-task-2, etc.), merging back into feature-1 when the sub-task is complete. (This allows feature-1 to only contain full-featured code)
• While development on feature-1 and the sub-tasks progress, it's important that as PRs are being merged into develop, that you rebase feature-1 branch. Not doing so will usually result in a mega rebase when preparing the feature PR.

As you notice, there isn't much diversion from your normal workflow, it's more of a matter of discipline to ensure rebasing is being done often and half-baked code doesn't make it to develop.

Hope this helps.

Verret

Are the features that are half-baked ever in your develop? Or do they stay in the feature-1 branch until fully baked? In other words, do half-baked features ever get to production, though dormant. – Cormorant

Answer 2

I cannot answer your questions from a strong stance, but I can point you to a blog post about gitflow.

Notice the image near the top. It notes a feature for future release (thus, a long-term feature).

This leads me to believe that this is appropriate behavior which is necessary when the situation requires it.

Mccorkle

Answer 3

At a previous company, at least 1/3 of our branches were “long running” of at least 2 weeks or more (a branch being developed on for a month was pretty common place). We used the gitflow pattern to do so also. Basically we would work on the branch, and periodically pull develop and rebase our branch on top of it. This is pretty similar to merging develop into a feature branch which I know is considered an anti-pattern.

The real key was maintenance of the branch and not letting it get too far behind. Stale branches are the most painful to try and update sometimes. Accounting for whether or not you have time to keep up with the branch amongst other priorities would need to be factored in.

Testing/environment set up is important too. Having a long running branch means its most likely an important feature/changes so it would probably be tested as such also. If your QA'ers (be it a team or yourself and other devs) can test the branch when it's close to ready in an isolated environment then that helps a ton.

Sepoy