Loading ...
Sorry, an error occurred while loading the content.

158534Hubflow? More like Hubflown't

Expand Messages
  • Ryan King
    Feb 15, 2013
    • 0 Attachment
      Has anyone dealt with this "hubflow" idea? http://datasift.github.com/gitflow/

      It sounds neat, but so far, it seems like an alternative to Continuous Integration. In fact,
      the doctrine of the original 'man gitworkflows' seems to run 100% contrary to it:
      http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_merging_upwards


      I am seeing the "feature branches" living between 2+ days to 2+ months,
      without so much as "one-way" integration (merging from 'master' to the
      feature branch on a regular basis).

      How would you verbalize the pro's/con's of full C.I., one-way C.I.,
      and no C.I., to someone who is bought into the importance of
      feature-branches?

      So far I've tried explaining how:

      Not pulling in 'master' regularly means you're piling up risk for when you
      eventually do merge, and you're going to have a larger search space when
      you *do* have subtle conflicts ("pay me now or pay me more later").
      Plus, in the mean-time you will not be benefitting from the great new
      things the master branch is getting (counter-argument was, ~"if the code
      has gone all these years without those changes, I don't think my branch
      needs them in a hurry").

      Not pushing to 'master' regularly means the same, but in reverse.

      The cost of C.I. is that you have to be more deliberate about the
      sub-tasks: which is a refactoring, which is a visible change, and how to
      do this without regression or getting caught in BDUF making the
      theoretical pieces of a theorized whole. You might even have to engineer
      a solution so both old and new features can live in tandem (e.g., the
      new one is hidden unless you unlock it with a special keystroke). Plus,
      you cannot pretend you're working alone, and have to understand others'
      work as it comes in.

      What am I leaving out?

      Now, I need to figure out the half-steps/stop-gaps that can be discussed
      if the team isn't ready for full buy-in of C.I.:

      - No pull requests get merged unless they already merged 'master' (puts the original authors in charge of the integration)

      - Encourage very short-lived feature branches (though the Hubflow process punishes this, somewhat)


      - Ensure that the planning process predicts which branches will be long-lived, and sets them up for, "I told you so"s. =)


      - ...?

      Thanks so much, and please forgive my ~7 years of absence from the community and the resulting rustiness.
      - rking
      P.S.: Hi, Dossy!
    • Show all 7 messages in this topic