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

Re: Hubflow? More like Hubflown't

Expand Messages
  • JeffGrigg
    ... OK; the blog author has discovered feature branches. I do find it interesting that there is no mention of merging mainline changes into long-lived feature
    Message 1 of 7 , Feb 15, 2013
    • 0 Attachment
      > --- Ryan King <ryanjosephking@...> wrote:
      >> 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?

      --- Adrian Howard <adrianh@...> wrote:
      > One observation is that it often seems to be tied to the
      > team's preferred way of working. If you like working by
      > yourself / remotely then having feature branches can seem
      > a nice way to work since you don't have to deal with the
      > rest of the team most of the time.

      OK; the blog author has discovered feature branches. I do find it interesting that there is no mention of merging mainline changes into long-lived feature branches. In my experience, the longer you wait before merging, the riskier and more costly the merge process.

      Branching, particularly long-lived branching (with little merging) tends to punish refactoring.

      http://nvie.com/posts/a-successful-git-branching-model/
    • 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 2 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 3 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 4 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 5 of 7 , Mar 1, 2013
            • 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.