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

Re: [XP] Hubflow? More like Hubflown't

Expand Messages
  • George Dinwiddie
    Ryan, I don t have much to add to your excellent list, below. I did happen across Feature Branches vs Feature Toggles
    Message 1 of 7 , Feb 15, 2013
    • 0 Attachment
      Ryan,

      I don't have much to add to your excellent list, below. I did happen
      across "Feature Branches vs Feature Toggles"
      (http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx)
      recently and you might find some more tidbits in it.

      - George

      On 2/15/13 6:47 AM, Ryan King wrote:
      > 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!

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • Ryan King
      ... Thanks for the link! Something like Feature Toggles came up as well, and I think they re a good way to wiggle out of the cases where it s hard to break a
      Message 2 of 7 , Feb 21, 2013
      • 0 Attachment
        George Dinwiddie <lists@...> wrote:
        > I did happen across "Feature Branches vs Feature Toggles"
        > (http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx) 

        > recently and you might find some more tidbits in it.


        Thanks for the link!

        Something like Feature Toggles came up as well, and I think they're a good way to wiggle out of the cases where it's hard to break a task into tiny, reliable, unobjectionable changes.

        I guess a (the?) big appeal of Feature Branches is that they prove that the *disablement* of the feature works atomically: you can choose to release without that branch and know none of that branch's parts are depended-upon by any other feature. But it's exactly these interdependencies that are getting lost when branches run long: in a healthy codebase, the core classes should churn relatively often (because developers are heeding code smells, and also not pre-generalizing things before it's time).

        Thanks,
        —☈
      • thierry henrio
        Hello George On Fri, Feb 15, 2013 at 10:00 PM, George Dinwiddie ... Good pointer indeed, and a question Why is there a candidate branch ? Why not master ?
        Message 3 of 7 , Feb 28, 2013
        • 0 Attachment
          Hello George

          On Fri, Feb 15, 2013 at 10:00 PM, George Dinwiddie
          <lists@...>wrote:

          > **
          >
          >
          > Ryan,
          >
          > I don't have much to add to your excellent list, below. I did happen
          > across "Feature Branches vs Feature Toggles"
          > (http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx)
          > recently and you might find some more tidbits in it.
          >
          Good pointer indeed, and a question

          Why is there a "candidate branch" ?

          Why not master ?
          Because it's easier to undo or because of different policies ( candidate
          can fail ) ?

          A very simple workflow is indeed "short lived" : pick something small,
          branch from master, commit as often, merge to master with some squash if
          required, push

          What does matter finally is how we are comfortable with our history ?,
          Thierry


          [Non-text portions of this message have been removed]
        • George Dinwiddie
          Thierry, ... It s not my article, so I can t answer for the author. I suspect that s to freeze the code for release while others continue to develop
          Message 4 of 7 , Mar 1 8:22 AM
          • 0 Attachment
            Thierry,

            On 2/28/13 7:18 PM, thierry henrio wrote:
            > Hello George
            >
            > On Fri, Feb 15, 2013 at 10:00 PM, George Dinwiddie
            > <lists@...>wrote:
            >
            >> **
            >>
            >>
            >> Ryan,
            >>
            >> I don't have much to add to your excellent list, below. I did happen
            >> across "Feature Branches vs Feature Toggles"
            >> (http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx)
            >> recently and you might find some more tidbits in it.
            >>
            > Good pointer indeed, and a question
            >
            > Why is there a "candidate branch" ?

            It's not my article, so I can't answer for the author. I suspect that's
            to "freeze the code" for release while others continue to develop
            unimpeded. With git that's an easy thing to do.

            A decade ago I would tag the head in SVN for a release candidate. If a
            problem showed up with that build (very rare) then I would fix it and
            repeat with the current head. I didn't use branches.

            >
            > Why not master ?
            > Because it's easier to undo or because of different policies ( candidate
            > can fail ) ?
            >
            > A very simple workflow is indeed "short lived" : pick something small,
            > branch from master, commit as often, merge to master with some squash if
            > required, push
            >
            > What does matter finally is how we are comfortable with our history ?,
            > Thierry

            - George

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          Your message has been successfully submitted and would be delivered to recipients shortly.