I’m on a team that is (trying) to use GitFlow. Pretty standard feature -> develop -> master approach. Here’s the problem: we’ve got users that demand features on the quick. We build it out, it’s complete, it gets merged into develop and then…sits. Either some consuming system isn’t ready or we’ve got something too tightly coupled. Then along comes another feature that gets finished and we actually do want to that one to prod. So guess what? We “hot fix feature” it right into master.

I’ve given it some thought and done some reading, and aside from the very obvious answer of “Do It The Right Way”–don’t build features that aren’t actually ready, don’t design that are so tightly coupled that a change in one is dependent on a change in another, etc.–how do you guys handle this situation? Way I see it there are a few :

  1. Don’t merge any feature into develop until it is actually ready to go into prod (barring bugfixes and such).
  2. Merge any code complete feature into develop and cherry-pick commits if you have to do a release before everything is ready for prod.
  3. Simultaneously maintain develop with all code complete feature branches and a distinct release branch that only has those things that are completely ready to go into prod.

The problem with 1 is that you then have to keep track of feature branches that are done, they sit around getting stale, and you either have to constantly backmerge and handle conflicts into them or just deal with possible huge merge conflicts when they’re finally considered “ready.”

The problem with 2 just boils down to the cons of cherry-picking/rebasing commits. The biggest one being the unintentional inclusion/exclusion of something that shouldn’t be there.

Which seems like it leaves 3 as the best of the bad options. Thoughts?



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here