[HN Gopher] Please stop recommending Gitflow
___________________________________________________________________
Please stop recommending Gitflow
Author : gortok
Score : 96 points
Date : 2020-03-04 17:06 UTC (5 hours ago)
(HTM) web link (georgestocker.com)
(TXT) w3m dump (georgestocker.com)
| cpascal wrote:
| > Have you ever _tried_ a complex branching model like gitflow
| with multiple teams, and hoped for everyone to be on the same
| page?
|
| My company does exactly this and I am happy to report there have
| been no issues. I think the key reason we don't have issues is we
| are strict about maintaining backwards compatibility between
| services and also try to maintain forwards compatibility where
| possible.
|
| > "What's in production" becomes an existential question, if
| you're not careful.
|
| We solved this by embedding the SHA's of a build's constituent
| repos in the build artifact.
| HelloNurse wrote:
| Some of the criticism in the article is unfair.
|
| Most obviously, the boundaries of source code repositories should
| be aligned with released modules: if "the system becomes a
| manifest of the different revisions of the different
| repositories" the repositories are too fragmented (or the
| releases too monolithic), if "teams are independent and
| microservices should be independently deployable" disparate
| components should not share a monorepo, and in both cases the
| difficulties are consequences of bad architectural choices, not
| of branching models.
| contingencies wrote:
| _We don 't use any branching._ Git is complicated enough to
| explain to non-software engineers without branching. We treat all
| commit versions equally for CI/CD. As most people are not
| software engineers, this seems a reasonable course of action if a
| project encompasses non software elements. We have non CI/CD
| testing anyway (nontrivial hardware projects require much more
| external process).
|
| _For releases we assign versions without tags_ , instead using
| replication of a subdirectory tree under a version number. This
| ensures all versions are available locally to all users without
| adding any access complexity.
|
| This is basically optimizing for simplicity for the users.
| zokier wrote:
| One would think by simply looking at the picture that gitflow is
| not well suited for processes that do not involve distinct
| releases. In other news, SaaS is not the only model in the world
| and CD is not always possible.
| Myrmornis wrote:
| 100% agreed. The workflow suggested in the viral blog post is far
| too complicated, even for experienced teams. But in practice what
| happens is that the teams who are most likely to base their git
| practices off some random blog post instead of off their own
| experience are the least experienced teams.
| rckoepke wrote:
| I really wish the article covered some alternatives styles.
| HelloNurse wrote:
| It's of course possible to have a meaningful discussion about
| different types of branches, releases, changes and about what
| changes should be merged, when, and where, but ultimately there
| is only one good branching strategy: thinking.
|
| Thinking about the purpose of branches, thinking about whether
| everybody is on the same page and what mistakes are possible,
| thinking about useful rules about changes and merging (possibly
| on a branch by branch basis), thinking about when to break and
| how to adapt the rules, and above all thinking about the
| objective of making correct and low-effort merges.
|
| Adopting practices because a blog post says so is the opposite
| of maturity. As Gitflow is presumably a good fit for the
| project it originated in, any "alternative styles" are suitable
| for someone else's particular needs and should be treated as
| examples and anecdotes illustrating general principles.
| merlincorey wrote:
| I default to recommending either Github Flow[0] or Gitlab
| Flow[1] these days.
|
| Both of these models simplify Gitflow by dispensing with the
| long-lived development branch and therefore the complication of
| needing separate hotfix vs release workflows.
|
| The difference between these models is that Github Flow expects
| you to deploy to environments within a pull request before
| merging to master, whilst Gitlab Flow expects you to merge to
| long-lived environment branches for deployment (presumably
| using Gitlab's CI features).
|
| [0] https://guides.github.com/introduction/flow/
|
| [1] https://docs.gitlab.com/ee/topics/gitlab_flow.html
| numbsafari wrote:
| I highly recommend Trunk Based Development:
|
| https://trunkbaseddevelopment.com
|
| "A source-control branching model, where developers collaborate
| on code in a single branch called 'trunk', resist any pressure
| to create other long-lived development branches by employing
| documented techniques. They therefore avoid merge hell, do not
| break the build, and live happily ever after."
|
| In my experience, new/small teams do well if they stick the
| "Scaled Trunk-Based Development" model until a legitimate
| reason to deviate is discovered (e.g. needing to back-port
| changes to an older release may imply making commits to non-
| trunk/master branches...).
| somacert wrote:
| I will admit I would not know the difference between gitflow and
| a hole in the ground. But that diagram looks an awful lot like
| the workflow you tend to pick up when using fossil.
| * The primary dev branch * branch and merge for feature
| development * long term branch for each release.
|
| The authors only real concern appeared to be no rebase, and
| rebase is already a big no-no in any sort of distributed
| development, just adopt that attitude for your personal
| development.
| dvdgsng wrote:
| > The authors only real concern appeared to be no rebase
|
| This is my take as well. That blog post has not much to say
| about anything, mostly weak points stemming from personal
| distaste of some things, but it boils down to 'i like rebase
| more'.
| elyobo wrote:
| I have two long lived branches, develop and master.
|
| * major features are done in feature branches, w/rebasing prior
| to merge
|
| * minor stuff directly in develop
|
| * master is auto deployed following successful CI, whenever we
| merge develop in to it
|
| * we merge frequently, but not automatically
|
| * we tag releases manually when we do merge
|
| It's a more minimal version of git flow. Small teams so not much
| problem.
|
| We could probably just drop the develop / master split and still
| be fine, but would force all changes to be in feature branches
| instead.
| crgwbr wrote:
| This is pretty much exactly what we do, except add in a third
| "qa" branch between dev and master, for the purpose of manual
| testing before things go to prod.
| babayega2 wrote:
| Indeed. i have been using Gitflow for the last 4 years on more
| than 14 repositories with teams spanning from 2 to 30 commiters
| and it worked. I honestly do not see what is the problem with
| having the code running on production on master, develop
| harboring the code deployed on review branch, and release/tags
| branches deployed on QA environment. Moreover each team can
| adapt the model to it's own workflow...
| chrisweekly wrote:
| Cool! This is almost exactly what I've been doing and
| recommending for many years.
| cactus2093 wrote:
| This still sounds like an anti-pattern to me, at least in a
| typical web app. I've seen a very similar workflow used in a
| previous org, and the main benefit was that it limits the
| number of times you have to cross your fingers and hope for the
| best (which is obviously masking other reliability problems).
| Merging each feature branch wasn't scary because it wasn't
| going to deploy yet, but that means it incentivizes somewhat of
| a "not my problem" culture. Then at some point someone builds
| up the courage to merge the develop branch to master and you
| hope for the best. Repeat every few days.
|
| There was also some wishful thinking about doing more qa
| testing than anyone actually did. The develop branch would
| immediately deploy to the staging environment, so someone might
| have tested new features there before they ship to production.
| But if there's no rigorous process around exactly what needs to
| be QA'd and whose responsibility it is, then let's be
| realistic, it's not gonna happen.
|
| The downsides are that release times were less predictable,
| deploys were bigger which means potentially more difficult to
| trace down bugs that do show up and roll back when needed, and
| things would get delayed for no reason. Oops, I thought I
| shipped that thing for marketing a few days ago but nobody
| deployed the develop branch since then.
|
| Developing small features right into develop sounds like a bit
| of an issue on its own too. Seems like you're not quite
| confident enough to deploy it right away, but it's also
| presumably circumventing the regular code review process so
| it's not going to get reviewed.
|
| The only reason I can see for why these downsides would be
| worth it, is if you have some hard constraint that you can't
| deploy very frequently (for instance releasing a downloadable
| desktop app or mobile app), and/or you have a formal, rigorous
| manual QA process when merging from develop to master.
| oweiler wrote:
| git flow never made sense for me. Because of the complexity some
| devs would always mess things up or ignore the branching
| altogether. Merging all the related branches into master when
| doing a release took multiple days and often introduced subtle
| bugs.
|
| Switched at some point to GitHub flow and never looked back.
| combatentropy wrote:
| > Merging all the related branches into master when doing a
| release ...
|
| --- doesn't sound like Gitflow. In Gitflow, the topic branches
| have been merged into the develop branch first, as they were
| finished. In contrast, merging into master is a merge from a
| single branch. You branch from develop into a release branch.
| Then you merge the release branch into master.
| rimliu wrote:
| That's not the problem with git-flow, that's the problem with
| discipline.
| ulisesrmzroche wrote:
| Gitflow is not robust enough to handle human error and is way
| too complex to onboard.
|
| It's a mediocre branching model incapable of handling a
| modern workflow, like continuous delivery and so on
|
| We gotta tendency to excuse bad software as long as it's old,
| especially on HN
| anon73044 wrote:
| I've have 400+ devs acoss several states working with 25+
| repos, all using a modified Gitflow. It took a month of
| negotiation to get buy in, so far, it's been working for
| the last 2 and a half years.
|
| And the beauty is, if a team wants to be more "agile"/more
| continuous, all we have to do is kill a few branches, and
| start building/releasing directly from master.
| cs02rm0 wrote:
| I think gitflow _might_ be suited to mature product work where
| development is ongoing.
|
| It keeps coming up in my consultancy work, usually on short term
| projects that either die or generally just get left to tick over
| where it's wildly unsuitable. Mostly because of the way it
| violates that principle of short lived branches.
| CurtBurbinger wrote:
| "Any branching model you choose is ultimately meant to make
| humans work together more easily to produce software"
|
| There are things in this article I agree with, and things that I
| don't, but the quoted point is something that I wish could be
| universally understood. Some developers commit to the dogma of
| one blog post or another and forget about the fact that the whole
| thing is for the _people_ who are writing the code. Branching
| strategy should help to optimize workflows and minimize friction,
| regardless of how badly bastardized your approach is vs. its
| source material.
| hinkley wrote:
| I can't seem to get people to agree on the point of unit tests
| either.
|
| Nowhere is this more apparent than when we argue about test
| coverage %'s. There's a whole bimodal distribution of people
| very wrong for very different reasons.
| zokier wrote:
| I feel unit tests are difficult to swallow to some people
| because they are not used to (or able to) develop code in
| distinct and definite units. And without units, unit tests
| are sort of meaningless.
| gumby wrote:
| I find about half the people don't see the point (mainly
| can't be bothered). I can cut that group by about a third by
| telling them "the tests keep other people from breaking your
| code"
|
| (Personally I think tests keep _me_ from breaking my and
| others ' code, but I don't tell them that)
| cryptonector wrote:
| +1e6.
|
| Rebase workflows are the best. We used the at Sun long before
| anyone called it rebasing, long before even any VCSes had the
| feature in any way. It's the only workflow that works in large
| codebases (monorepos, repo forests) with thousands of developers.
| Merges stop being interesting very quickly once you've got a) a
| large number of developers, and b) a high rate of commits on the
| same codebase -- it's just too much metadata.
|
| Linear history works like a charm and is super easy to understand
| (because it's linear).
|
| Nobody cares about the internal history of a feature branch that
| has delivered. One should only care about what mainline bugs were
| fixed and what features were added -- bugs that never made it to
| the mainline are simply not interesting at all to developers on
| the mainline (though admittedly they might be to someone studying
| developer performance, but then, feature branch history can be
| kept and archived, just not on the mainline).
| eindiran wrote:
| I've been swayed to the side of believing that rebase should
| rarely be used, so that's not much of a downside. See:
| https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.m...
| deckar01 wrote:
| Most of that blog post's workflow seems like pretty normal merge
| request development. Separating develop and master is where most
| of the complexity arises. The reported advantage is "the develop
| branch is cleared to receive features for the next big release".
| I have never ran into a problem with features needing to land in
| master before a release is cut, likely because I have never
| scheduled releases and I think most projects don't. Even if they
| did, the project has to be pretty massive to have a feature
| ready, but scheduled for a future release and also be blocking
| the development of another scheduled feature... If your project
| is that busy, it is seems like a reasonable workflow. Everyone
| else can probably just treat master as their develop branch and
| everything else in the article is pretty good advice.
|
| The only other oddity I see is treating hot patches different
| than feature branches. In my experience, hot patches are no
| different than feature branches in projects that use master as
| the branch to deploy from. In projects that perform manual QA, I
| use a branch for each deploy environment to stagger rollouts, the
| final branch being for the production environment. In that case
| it makes sense to start a merge request on the production branch
| before master.
| combatentropy wrote:
| Gitflow didn't just pop into the head of Vincent Driessen. It
| seems he curated an opinionated selection of the options from the
| book _Pro Git_ (https://git-scm.com/book/) and I wouldn't be
| surprised if many projects were already using something like it
| to various degrees.
|
| I went for many years with only a master branch and sometimes a
| develop branch, because I often worked alone. It took me years to
| venture into branching at all. Before Git I used Subversion. I
| don't think we branched once. But easy branching is one of Git's
| distinguishing features. For me, branching was like learning a
| programming language. At first it's mindbending and intimidating.
| But with reading, practice, re-reading, and more practice, it can
| eventually become second nature. The crazy diagram that George
| Stocker holds up makes perfect sense to me now.
|
| I was forced to adopt Gitflow when I joined a bigger team. But
| now that I have learned it, I kind of like to use it even when
| working alone. Topic branches remind me of functions, in that
| they are small and encapsulated. I can concentrate on a narrow
| range of code and feel safe. The eventual merge might have
| conflicts, but they are soluble. And the way that feature
| branches stem from develop while bug-fix branches stem from
| master, and how you have a release branch to freeze features
| without freezing work --- I don't know, it feels very safe and
| structured.
|
| However, yeah, like Stocker says, it may be too much ceremony,
| especially if you're just starting out. I like to tell people to
| ease into it. Stop when it hurts.
| bavell wrote:
| It seems to me that most of the authors objections stem from 100%
| strict adherence to git flow, which IMO is the wrong approach.
|
| I loved the concept of git flow when I first read that legendary
| blog post. I learned a lot and adapted it into my own development
| workflow. I've bounced back and forth over the years in how
| strictly I adhered to the One True Way (tm) based on how well it
| worked for me in actual projects.
|
| IME I think the best approach to git flow is to learn and
| understand it and then adapt it to your project's workflow, as
| opposed to strictly adhering to every tenet of git flow. I have
| multiple projects using different "amounts" of git flow - e.g. a
| large project with dev, qa, hotfix and release branches vs a
| small personal project with only master and dev.
| ryanackley wrote:
| This cycle seems to repeat endlessly in our industry:
|
| * Early adopter independently comes up with an idea that works
| well for his/her team.
|
| * Writes an innocent well-written article or book.
|
| * Idea somehow becomes dogmatic. Even for situations that don't
| make sense.
|
| * After some time, people rebel against dogma because they
| realize it doesn't make sense for every situation.
|
| * Original idea now considered anti-pattern even though it may
| still make sense for some people or situations.
| andrewstuart2 wrote:
| Our industry? I think the problem goes well beyond any
| industry; it's just a human thing. 1. See
| success 2. Want success 3. Copy behaviors
| 4. Behaviors were only part of success
| Dirlewanger wrote:
| Yup. It's a byproduct of software not being grounded in
| anything compared to, say, every other engineering discipline.
| They all have the laws of physics. Software has...a bunch of
| different mantras and paradigms, and for every one out there,
| there's one that is its direct opposite.
| hinkley wrote:
| I used a watered down version of gitflow on a project with heavy
| customer involvement.
|
| Instead of doing the whole thing, we had feature branches (which
| I still hate), master, and one more branch for the stuff we were
| showing to the customer. Who sometimes would decide they didn't
| like what they asked for and please don't push this to
| production.
|
| With the exception of hotfixes, master was always just a certain
| number of commits behind the working branch.
|
| Very aggressive use of dark launching of features could also
| solve this problem, but we've had our share of problems with that
| strategy too (Sprint-obsessed thinking makes it difficult to go
| back and clear out old conditionals once they've settled)
| iamleppert wrote:
| I agree 100%. I too tried Gitflow on many different projects,
| with different skill levels of teams and we ended up pulling the
| plug on it and going back to "master is always
| deployable/production". Developers work in feature branches that
| are small and atomic, with frequent merges into master with
| corresponding deployments. Breaking master is a critical blocker
| issue. There's no need for tags, complicated release schedules or
| processes following this model and it scales from a team of 1 to
| a team of 1000, I've seen it done.
|
| Gitflow doesn't work in a CI environment on a modern software
| application that has good testing culture and systems that are
| resilient to failure.
|
| Tools and processes work a lot better when they work for you, not
| the other way around. KISS.
| an-allen wrote:
| Source repositories are all about managing complexity. The more
| unmerged code you have from your releasable branch... the more
| complexity you have being held in the source repository.
|
| In the field I've seen git-flow lend itself to having trouble
| handling releasing some features and not others that have already
| been merged into a release or environment branch. This leads to
| cherry picking or more complex merging trees. With trunk based
| development, once a thing is merged to master it is shipped.. so
| it keeps the complexity being held in unmmerged branches to a
| minimum.
| platz wrote:
| As far as I can tell, the only difference between git flow and
| not git flow is whether you have a Develop branch or not
| gwbas1c wrote:
| There's nothing wrong with gitflow... The problem comes with how
| it's managed. The problem comes when a risk-averse manager wants
| to follow a 1990s release cycle, and release and feature branches
| live forever.
|
| Release branches should be created shortly before release, and
| shouldn't deviate too much from develop. Feature branches also
| shouldn't last very long.
|
| If a feature is going to be under very heavy development before
| shipping, a better strategy is to #ifdef the feature. This helps
| avoid accumulating merge conflicts that happen when there are
| long lived branches.
| ulisesrmzroche wrote:
| There's a lot wrong with gitflow. For one, the very existence
| of a release branch.
| crgwbr wrote:
| In real world software dev, I fail to see how a release
| branch is a flaw. It's completely reasonable to want to test
| something in a "gold-master" state before shipping it to
| prod. Regardless of how many tests you have, that's just a
| good idea.
| dhimes wrote:
| Yeah it's what we call staging. I have a project now that
| doesn't have a staging environment that's well integrated
| and it's very nerve-racking. I use hg but it's the same
| idea.
| tootie wrote:
| I don't understand the argument here at all. Git flow seems
| pretty orthogonal to concept of branching lifespan. We did the
| "merge early, merge often" approach with SVN 15 years ago and it
| was fine. We do git flow now and it's fine. It meshes perfectly
| with agile development where you work on the smallest feature set
| that adds incremental value. That means your branch only ever
| lives long enough to do one tiny thing and it gets merged as soon
| as it's working and no sooner. I've been following this approach
| for years with dozens of teams and it's very successful. And I've
| never run a rebase on purpose in my entire life.
| danw1979 wrote:
| Exactly this. Whatever you call your branching methodology, if
| they last too long that's when the fun stops.
|
| This article is full of bluster about how bad gitflow is, but
| very little actual reasoning why.
|
| I don't like the ceremony all that much, but its working really
| well at my current large corporate gig across thousands of
| repos and engineers.
| snapetom wrote:
| When I first researched git, this blog post came up. It's been
| around forever.
|
| My first thought when reading it, though, was, "huh, we seem to
| be doing that with SVN already." Indeed, gitflow just seems to be
| a popular SVN flow ported to git.
|
| Looking at the diagrams, there seems to be a lot of branching and
| merging, but in practice, it's far less than merge early, merge
| often. In using SVN, though, you can see why. SVN thrived in a
| day with more large, monolithic codebases. Further, branching in
| SVN was _heavy._. It made a copy of the entire codebase. It wasn
| 't fun because it took so long. Gitflow emerged from an SVN
| world.
|
| Nowadays with microservices, modular codebases, and CI/CD, a
| merge early, merge often approach with git makes more sense.
| There isn't nearly the overhead or pains of branching and merging
| with git as there is with SVN.
| Ixio wrote:
| Are people really calling this specific model of git branching
| THE Gitflow model ? For me this was a gitflow amongst others, a
| gitflow being a git workflow.
|
| In the original article "A successful Git branching model" I
| don't see a single mention telling people they should call this
| specific model Gitflow.
|
| For me the word gitflow has the useful meaning of a git branching
| model, am I in the minority ? Using it as a noun for a specific
| model seems like a waste of the word.
|
| In regards to the article, sure this gitflow is one of the most
| shared images on the subject. However I recommend that every team
| use whatever gitflow makes the most sense for them and their
| project. I was not aware that our industry had a problem with
| teams cargo culting that specific git workflow.
| amenod wrote:
| +1. We use as many branches as it makes sense on a particular
| project. Simple ones might have just master (and temporary
| feature/bugfix branches). Only when we need to have a LTS
| version do we introduce another branch for it.
|
| I always thought this is _also_ Gitflow, but reading this
| article, I 'm not so sure anymore.
| daxelrod wrote:
| Interesting. I have only ever heard "gitflow" used to refer to
| the specific model described in
| https://nvie.com/posts/a-successful-git-branching-model/ . The
| author also wrote a tool, "git-flow", to assist with this model
| https://github.com/nvie/gitflow .
|
| I have heard the terms "git branching model" or "git workflow"
| used for the concept that you call "gitflow".
| danw1979 wrote:
| nvie/gitflow is a long dead project. There's an active fork
| at https://github.com/petervanderdoes/gitflow-avh
| daenz wrote:
| Speaking for myself, git flow _is_ intuitive. It is something you
| also have to practice discipline to adhere to. That is not simply
| "additional cognitive load", it is just like any other process
| worth following.
|
| Their criticism about "tripling the number of merge conflicts"
| because of the number of branches doesn't make any sense. As long
| as developers are doing development work and committing,
| regardless of what branch they're committing to, there is
| potential for conflict. It might not be a "merge" conflict in the
| sense of two separate branches, but it will manifest as a merge
| conflict in pushing the local to the remote. The potential for
| conflicts stay the same. What git flow gets right here is it
| isolates logical workflows from each other, so people working can
| work for as long as necessary without conflict.
|
| >Gitflow abandons rebasing
|
| Rebasing is a nightmare for distributed work, and in my opinion,
| only makes sense in limited circumstances where your code is not
| already pushed and pulled in multiple locations.
|
| >Continuous delivery is a practice where the team release
| directly into production with each "check-in" (in reality, a
| merge to master), in an automated fashion. Look at the mess that
| is gitflow and explain to me how you're going to be able to
| continuously deliver _that_?
|
| Every modern CI/CD framework can run automated jobs after a merge
| into master, so I'm not sure what the criticism here is?
|
| >Have you ever _tried_ a complex branching model like gitflow
| with multiple teams, and hoped for everyone to be on the same
| page? Can't happen.
|
| That is less a criticism of git flow and more a criticism of any
| software organization that tries to have repeatable deployments
| with many services. It's a difficult problem in general, and not
| one that git flow is attempting to solve in the first place. You
| will have that problem regardless of if you use git flow or not.
|
| I could go on but there's a lot here. It sounds like the author
| is very frustrated and annoyed with git flow, and perhaps is used
| to cowboying code (the desire for frequent rebasing give me a
| hint to this) without regard for the impact on other developers.
| I've worked with people like this, and they often provide no
| alternative solutions, just frustration and resistance to
| following an imperfect process. It's a rant without much
| substance.
| zokier wrote:
| > Every modern CI/CD framework can run automated jobs after a
| merge into master, so I'm not sure what the criticism here is?
|
| The criticism (and the one thing I can sort of agree on) is
| that with git flow you are not merging to "master" on a
| _continuous_ basis. Select quotes from the nvie post describing
| gitflow:
|
| > When the source code in the develop branch reaches a stable
| point and is ready to be released, all of the changes should be
| merged back into master somehow and then tagged with a release
| number
|
| > The essence of a feature branch is that it exists as long as
| the feature is in development, but will eventually be merged
| back into develop (to definitely add the new feature to the
| upcoming release)
|
| > By doing all of this work [release prep] on a release branch,
| the develop branch is cleared to receive features for the next
| big release.
___________________________________________________________________
(page generated 2020-03-04 23:00 UTC)