25 ms·

Please stop recommending Gitflow

• _hao 7y ago
  At work we were using TFS when I joined. I managed to win the battle and migrated everything we have to Git, but for some reason they wanted us to follow Gitflow (other parts of the business were on Git and were using it). A couple of horrible releases, regressions and lost functionality (merge errors) later I managed to push everyone into using Microsoft's Release Flow[1]. We haven't had a single regression since then and everything in the process is more or less smooth. The funny thing is I've used Gitflow successfully before in another job, but nowadays I'm mostly scratching my head how it ever worked correctly. It's so overly complicated. It would never be my process of choice. [1] https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/release-flow https://docs.microsoft.com/en-us/azure/devops/learn/devops-a...
  • twhitmore 7y ago
    I've seen Git Flow fail in even relatively small software houses. I've seen sensible trunk-based development with feature & release branches (equiv to what MS call 'Release Flow') work well from small to huge (400+ devs) environments.
• mariust 7y ago
  can I double vote this? :))
• Kaotique 7y ago
  We use a variant of Gitflow without a develop branch and without release branches. Gitflow has 2 major problems: - develop branch that will always become a mess over time - release branches are never completely accepted. It is much easier to accept features branches. We try to merge feature/bugfix branches directly to master when they are approved. We have testing/staging branches that can be thrown away and re-created from master and re-merge any feature/bugfix branches that have to be checked. This has worked very well for the last 5 years or so and we have used it in dozens of projects every year. The fact that testing/staging contains no commits (except merge commits) of its own is very useful. You can drop these branches regularly and remove any old feature branches that became stale for some reason. Lastly, I have seen a lot of teams that want to apply complicated Git strategies from day one of a project where it would be much better to just work on one master branch because too much code changes at the same time. This will create complicated conflicts. The history at the start of the project is not interesting. Git history only becomes useful when the project is live and you want gradually add features or fixes.
• 411111111111111 7y ago
  I disagree with the article. there are pitfalls you can fall into using gitflow, but they're not inherent to that strategy. pointing out the obvious: a master branch is technically redundant for gitflow. you just need to create a tag. it however makes it easier to visualize and think about the flow in regard to hotfixes. next obvious point: you're just not releasing quick enough if merge conflicts become an issue with gitflow. personally, i think release branches are just quick snapshots you can use to safely run all tests against while other developers keep pushing features on develop. this gives you a short timeframe to merge bugfixes into the release branch, but it really shouldn't exist for > 2 days (one day to identify issues and fix them, another to verify that they're gone). nor do i see any issue with continues integration, honestly... gitflow just formalizes the way code goes into production. if anything, it makes it easier! now you can automatically spin up new environments for release/* branches to automatically trigger a system test suite, appending the result to the release. i dont get his issue of multiple repositories either... each microservice surely has a different version, no? so for what conceivable reason would gitflow create any issue here? if you're a three man team, gitflow is probably unnecessary though. its meant for bigger projects with lots of developers pushing at the same time.
• photoangell 7y ago
  Please stop using "Please stop..." in the title of blog posts. It has a passive aggressive, techbro culture, holier than thou ring to it. Which I find grating. That aside, there's not much in this article anyway. Despite trashing it in the title, he goes on to say it might work in large organisations or those with a long release cycle, but otherwise can't recommend an alternative. Ok then.
  • StevePerkins 7y ago
    You would prefer: "Gitflow considered harmful", "Why I don't use Gitflow", or any of the other dozen clickbait variants, then? At the end of the day, people enjoy writing contrarian posts, and people enjoy reading them. They have to be named something. People who use title templates are no more annoying than people who code things they dislike as masculine.
  • collyw 7y ago
    Rename it to "Gitflow considered harmful".
  • IanSanders 7y ago
    It's as much of an article as one advocating a tool (or workflow) without exploring its weaknesses. In a way, both complement one another.
• u801e 7y ago
  Gitflow is really meant for software that multiple released versions. It allows for applying bug and security fixes to older released versions. For a project that has a single released version, it really doesn't provide any benefit.
• ptah 7y ago
  > Ok, so my team shouldn’t use gitflow. What should we use? I can’t answer that. this article is worse than useless. it's just a rant about inconveniences without any solutions
  • gortok 7y ago
    Thank you for that feedback! I purposefully didn't provide any solutions in that blog post because the entire point of the blog post is for a team to figure out what works for them, in their context, culture, and constraints. There are lots of different workflows: > Feature branches > Merge to Master > GitHub Flow > GitLab Flow > GitFlow I've also seen weird mutations where each developer reuses a branch and just does new pull requests from that an nukes the remote each time. it's problematic, but some teams swear by it (they also don't do any pairing or code reviews by pulling down branches). This isn't the first time I've heard this bit of feedback, so I think i may put together a blog post on the different styles and their uses (and limitations). But again, it's up to you and your team to figure out what works in your culture, context, and with your constraints.
• ses1984 7y ago
  Git flow is complicated. So is software. If you work at a place that still ships software instead of just running services, you need something more than continuous delivery and a trunk based workflow. If you provide services, you need to care about at most 3 versions of your software at the same time: the version running in production, the version before it, and the version after. If you ship software you might have to care about every version you ever released to in the last 2 years plus that one super old version your second customer is still using because they refuse to upgrade and shit you need to fix a critical vulnerability that was just published in it. Trunk based dev doesn't cut it in that world.
• mcv 7y ago
  Most of this article is nonsense. It's true, gitflow is not a silver bullet for every single situation, and if you've got a more complex situation than a single team working on a single project, you're probably going to need something that takes the complexity of your situation into account. It's also true that gitflow might be a bit too detailed and complex for simpler situations, but you can easily drop parts of it. It's not a universal solution to everything, but it's a decent basis to start from, particularly if you have no idea how else to organise your git workflow. Because everybody using their own approach without any coordination is definitely going to be worse. > "Gitflow abandons rebasing" It doesn't entirely do that, but it does abandon rebasing in situations where it should be abandoned. Rebasing is dangerous. Rebasing changes your history, and as any time-traveler knows, messing with history is risky. If you change history that you already shared, you can end up duplicating it and making a mess. Rebasing is only ever fine for local changes, and you can still use it there in gitflow. But if you merge a feature that took some time to develop, into the develop branch, rebasing is a terrible idea, and it should really be done with a merge. > "Gitflow violates the “Short-lived” branches rule" Is that a rule? Some features really do take time to develop. Any workflow has to account for longer lived branches. Also, if code has to be reviewed before it can be merged, that also extends the lifetime of branches. Fortunately big merge conflicts are easily prevented by regularly pulling the latest develop into the feature branch. And any situation where you have multiple people potentially changing the same file, is going to lead to merge conflicts no matter what git workflow you use. > "Gitflow makes Continuous Delivery Improbable" Nonsense. Once code has been merged into develop, it's ready to deploy. Well, I suppose this one is correct if you consider dropping even the tiniest part of gitflow as completely abandoning gitflow; all continuous delivery teams I've seen, don't use explicit release branches; they just deploy develop (or merge to master and then auto-deploy that). The only argument the article uses here is "look at all those lines and dots! this can never work!" Well, it can and does. I've worked in teams that use short release cycles, up to daily, and use a workflow that's pretty close to gitflow. It's a decent default to start from, but if you're working in a more complex environment, with multiple teams working on the same code base, parts of which need to be releasable independently from the rest, then yes, gitflow might not fit your need. So adapt. See gitflow as a starting point, not as a silver bullet. There are no silver bullets.
  • 7y ago
• stared 7y ago
  IMHO GitFlow often works, as is a decent baseline. When people don't use GitFlow (i.e. people starting their adventure with git, with no supervision), very often they report to one of the above: - one master, and SVN-style - personal branches, and marges in all directions - even more mess Sure, they may be projects in which a different commit/branch/merge workflow is better. (In many projects I did some adaptations for GitFlow, depending on the project scope, scale and skill of programmers.) However, the original author, after a long criquite recommends nothings (to my disappointment). So, what's the point? Going back to this "anyting marges with anything" branch Wild West, as a baseline?
• luord 7y ago
  While I wouldn't give as much weight to microservices—because 99% of teams shouldn't be using them—he makes quite a few good points.
• federalemployee 7y ago
  Funny, I always interpreted the gray branches in that diagram to mean short lived branches. I just have dev and master with all my projects. Everything else is short lived. And short lived branches are rebased and squashed. Also, all devs work with forks to keep upstream pristine. And there are those dogmatic about trunk development. I think if you follow the rule of thumb of don’t let dev and master get too out of sync you don’t need to do trunk.
• oweiler 7y ago
  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.
  • rimliu 7y ago
    That's not the problem with git-flow, that's the problem with discipline.
    • ulisesrmzroche 7y ago
      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 7y ago
        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.
        • ulisesrmzroche 7y ago
          I work in a bigger place with a lot more repos in a company that’s used gitflow since it came out. What does have that to do with anything? Why do you use agile in quotation marks? Is there something wrong with your keyboard? What’s the deal?
        • deleted 7y ago
          [deleted]
  • 7y ago
• rckoepke 7y ago
  I really wish the article covered some alternatives styles.
  • numbsafari 7y ago
    I highly recommend Trunk Based Development: https://trunkbaseddevelopment.com 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...).
  • HelloNurse 7y ago
    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 7y ago
    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/ https://guides.github.com/introduction/flow/ [1] https://docs.gitlab.com/ee/topics/gitlab_flow.html https://docs.gitlab.com/ee/topics/gitlab_flow.html
• sergiotapia 7y ago
  For the very longest time I thought I was doing gitflow (I skimmed the article back in the day). I wasn't. What we do is master is always green, prod ready. Good To Go. Auto shipped to prod by our CI/CD. Develop _should_ always be good to go. Green. Auto shipped to staging by our CI/CD. Then we have feature/ch1238-foobar-baz branches for every feature. Go crazy in there, deliver a completed feature. Is there a need for more process than this?
• CurtBurbinger 7y ago
  "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 7y ago
    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 7y ago
      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 7y ago
      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)
      • gwright 7y ago
        Always helpful to think about your future self as that other person.
  • draw_down 7y ago
    But that’s the rub, isn’t it? For me, it’s frustrating to see people make in-depth, well-considered points about why something is problematic, and have that be met with “well you just need to pick the right tool for the job guys!” It’s such an anodyne and vacuous point to make, precisely because the whole dialog is around whether and when a tool is the right one. Given a job, people will disagree about what the correct tool is. Given a tool people will disagree about what jobs it’s good for. There is no way around this, and there are times when a decision must be made.
• hinkley 7y ago
  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)
• HelloNurse 7y ago
  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.
• gwbas1c 7y ago
  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 7y ago
    There’s a lot wrong with gitflow. For one, the very existence of a release branch.
    • crgwbr 7y ago
      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 7y ago
        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.
        • ulisesrmzroche 7y ago
          Staging corresponds to master, tags are branches.
          • dhimes 7y ago
            We have a branch called “live”. That’s on our production server. Staging is testing to make sure our dev is worthy of moving to live.
• daenz 7y ago
  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 7y ago
    > 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.
• cpascal 7y ago
  > 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.
• zokier 7y ago
  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.
• elyobo 7y ago
  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.
  • chrisweekly 7y ago
    Cool! This is almost exactly what I've been doing and recommending for many years.
  • crgwbr 7y ago
    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.
    • dwd 7y ago
      This is where GitFlow makes sense - when you have a QA and/or enduser acceptance process before code is committed to a master/release branch. Also for DevOps you sometimes need to be able to branch off Master to apply a critical patch which then gets merged back into Dev later. You don't want to ever need to do that, but if subverting the normal process makes sense because you have all signoff parties gathered at the table - you do what needs to be done.
  • babayega2 7y ago
    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...
  • 7y ago
• cs02rm0 7y ago
  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.
• bavell 7y ago
  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.
  • dvdgsng 7y ago
    > 100% strict adherence to git flow, which IMO is the wrong approach. I agree, as with most things, there certainly is room for flexibility here. One problem I've seen repeatedly occur when migrating to git flow is a misconceptions about 'bugfix/' branches, which are intended to be used when stabilizing a 'release/' branch. However devs use that prefix for every bug they find which is not related to a story/feature. And to be honest, they are right to do so. The naming is just bad here, since the term 'bugfix' is so generically used, it's not very intuitive to use it only for release branches. So I've come to the point where I would agree to use 'bugfix/' for regular bugfixing if the team/company is comfortable with it, even though it is opposed to original gitflow.
• iamleppert 7y ago
  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.
  • theK 7y ago
    I think your last paragraph is pure gold and encapsulates the point of all these discussions. Use something by applying it with common sense, in the right amount and customization and it will have a chance to work. Use something as if it is a religion and it will introduce weird side effects.
  • vosper 7y ago
    > 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. How do you roll back in a process like this? I was imagining that a release would consist of tagging master, so a rollback would be going back to the previous tag. Or perhaps you just keep track of the previously deployed commit hash and roll back to that?
  • jmvoodoo 7y ago
    I have used gitflow successfully for some time (starting when it was first announced and there wasn't anyone complaining about it). I've always done "develop is always deployable to production" and the only thing we used master for was rolling back (extremely rare), and the only thing we used release branches for was demos or documentation before a release went out. We had CI built against develop but also every feature branch and every PR. We also leveraged static analysis the same way, and at one company even ran automated pen tests on develop and PRs. I don't know if I fundamentally misunderstood gitflow but this was my take on it from the beginning and I've never had issues with it that made me want to jump ship. We didn't use hotfix or support branches, and we never really used tags for anything either. Not using them didn't cause any noticeable overhead. The nice thing about git-flow in my opinion is that you can implement it without all of the CI stuff, then add that later over time. This is a godsend when you take over a legacy product with little to no test coverage and no CI pipelines. I've also never run into a ton of merge conflicts, but the largest team I've had is 70 people so maybe it breaks down at some point that I haven't experienced yet.
• an-allen 7y ago
  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 7y ago
  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
• Ixio 7y ago
  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 7y ago
    +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 7y ago
    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/ 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 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 7y ago
      nvie/gitflow is a long dead project. There's an active fork at https://github.com/petervanderdoes/gitflow-avh https://github.com/petervanderdoes/gitflow-avh
      • Ixio 7y ago
        Thanks for the link, at the very least Jeff Kreeftmeijer in 2010 already used the name git-flow for that specific model. I somehow missed all of that. Plus nvie.com updated its 10-year old post with a notice yesterday and also uses the name git-flow there. I guess I'd better use the term git workflow in the future.
• eindiran 7y ago
  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.md https://www.fossil-scm.org/fossil/doc/trunk/www/rebaseharm.m...
• contingencies 7y ago
  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.
• Myrmornis 7y ago
  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.
• somacert 7y ago
  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 7y ago
    > 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'.
  • cryptonector 7y ago
    > rebase is already a big no-no in any sort of distributed development You are ill-informed on this subject, and I have a proof-by-existence. Sun Microsystems, Inc., used a rebase workflow from the mid-90s all the way until the end, at least for the codebases that made up Solaris (OS/Net and other consolidations), and it did so while using a VCS that did not support rebase out of the box (Teamware, over NFS). It was essentially a git rebase workflow years before Larry McVoy created BitKeeper, and even more years before Git was created, and even more years before the rebase vs. merge workflow controversies. When I was at Sun we had ~2,000 developers on mainline Solaris. The rebase workflow worked fantastically well. Large projects had their own repositories that were rebased periodically, and team members would base their clones on the project's clone (known as a "gate"). Large projects' gates would get archived for archeological interest. All history upstream was linear. No. Merge. Commits. (We called them "merge turds", and they were a big no-no.) Solaris development was undeniably distributed development.
• cryptonector 7y ago
  +1e6. Rebase workflows are the best. We used them 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).
  • StavrosK 7y ago
    My only beef with rebasing is that it seems to fail much more often, whereas merges will usually do the right thing. I realize this is git-specific, but rebases have still given me much more trouble than merges.
    • cryptonector 7y ago
      I've yet ever to see a rebase workflow fail, and I've been using a rebase workflow since at least 2002. I do sometimes have to rebase across thousands of commits because I let a branch rot, and that can be hard to rebase, but it can be equally difficult to merge. Instead I use a bisecting rebase approach where I try to rebase straight to the new upstream, and if there's conflicts, abort the rebase and try rebasing to halfway to the new upstream, continuing the process until the rebase was across just one commit, thus I can resolve conflicts directly with the upstream commit that caused them, then restart the process until done.
      • StavrosK 7y ago
        Hmm, that doesn't match my experience. If I remember correctly, I've mostly seen long-running branches where the conflicting code was moved/taken care of still having rebase conflicts because git is running the commits one by one, and is conflicting with the old commits (before they were fixed), requiring me to fix them yet again. Merging doesn't have that problem, it usually just merges fine unless there are conficts in the latest commit (not all previous ones).
• deckar01 7y ago
  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 7y ago
  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/ 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.
  • shagie 7y ago
    From my days working at a perforce shop... Advanced SCM Branching Strategies was something that I was familiar with. https://www.vance.com/steve/perforce/Branching_Strategies.html https://www.vance.com/steve/perforce/Branching_Strategies.ht... (from '98). The essence of it is establishing different roles for different branches. mainline, development, maintenance, accumulation and packaging. With those roles in mind, when I was introduced to git flow it made sense - mainline is develop branch; development and maintenance roles are done in feature branches. Accumulation isn't one that is seen too often but should be kept in mind, and the release branch is the packaging role. These ideas have probably been realized time and time again. The conclusion of the paper: > Planning and analysis are critical to the success of any SCM system. A branching strategy motivated by a risk-based analysis of the organization's development needs will provide a strong foundation. Incorporating the concepts of branch roles, codeline policy and codeline ownership will assist in performing the required analysis. Application of the principles of branchpoint, merge policy and branch life span will ensure that the parameters governing codeline policy are properly and completely addressed. > Once the branching strategy has been formulated, the organization can implement the customizations required to make the SCM tool suit its environment. Until SCM systems have reached sufficient maturity to address the larger issues of policy, adopting the practices put forth in this and other papers will help an organization achieve success in their software development endeavors.
• ryanackley 7y ago
  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.
  • rkangel 7y ago
    My takeaway from this is that more articles should include a 'this works in x situation, probably also works in y, but is not suitable for a, b, c' discussion. Applying the right techniques in the right places is an important part of engineering - some authors talk about it more than others and it's very useful.
  • dirtydroog 7y ago
    medium.com articles define the software development practices of most companies. It's a bit of a joke.
  • andrewstuart2 7y ago
    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 7y ago
    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.
    • chadcmulligan 7y ago
      Even things that have science are largely ignored - one I always shake my head at - oracles for ethereum. Proved many years ago - there can't be an oracle. Ethereum developers - we'll build oracles so the transactions are guaranteed. No doubt there will be arguments for how oracles for ethereum are different, and so on
• tootie 7y ago
  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 7y ago
    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.
    • cryptonector 7y ago
      I have some long-lived branches lying around for work I only occasionally have time and energy to do. E.g., I've an "ALWAYS DEFERRED" feature patch for PostgreSQL I need to eventually finish. Every time I come back to it I've fallen thousands of commits behind, and neither a merge nor a rebase can save me, but a rebase bisection script I have does save me by identifying the one commit upstream, in order, that causes conflicts that I have to resolve manually, then resumes the rebase bisection. Specifically, the algorithm is something like this (not tested; I've a script I should publish): bisect_rebase() { local ultimate_target=$1 local target=$2 shift 2 b=$(git merge-base HEAD $target) while [[ $b != $(git rev-parse $target) ]]; do n2u=$(git log --oneline $b..$ultimate_target | wc -l) n=$(git log --oneline $b..$target | wc -l) # Try rebasing directly onto the target git rebase --onto $target $b && return 0 # If we have conflicts and rebased across just # one commit, stop here ((n2u == 1)) && return 1 if ((n == 1)); then echo "Fix conflicts and exit 0 to continue or 1 to stop" if $SHELL -i; then git rebase --continue return 0 else git rebase --abort return $? fi fi git rebase --abort bisect_rebase $ultimate_target $(git log -n $((n/2)) --pretty=%h $b..$target) done }
• snapetom 7y ago
  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.
• honkycat 7y ago
  In my opinion the problem with GitFlow and a lot of other git workflows is you end up holding a bunch of state inside of your git branches which is hard to decipher, complicated to manage, creates work for people ( with merge conflicts, and managing feature branches that need to be merged ), and is capable of losing progress. My solution: USE FEATURE FLAGS. Keep the list of features and refactors you want deployed in a format that is easy to audit and reason about. I like the Microsoft branching strategy: https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops https://docs.microsoft.com/en-us/azure/devops/repos/git/git-... Basically: * Create feature branches. * Merge into master when the feature is done. For long lived branches: Don't keep them around. Merge them into master and put them behind a feature flag. * Deploy to environments using release branches. * USE FEATURE FLAGS. Do not hold state in your github repo/branch merge status. Do not control features and refactors inside of your git branches, only merging the code you want to be deployed. Instead, put them behind feature flags and activate them using code. There is a good book on the topic of feature flags titled "Effective Feature Management" that is a good overview. Feature flags do not have to only protect features. You can put refactors behind feature flags as well, or really anything.
  • hrpnk 7y ago
    Thanks for the feature branch book recommendation. Overall, feature branches work well as an approach for relatively modern systems. I once worked on a distributed, multi-process system from the 90s that powered more than 40 factories across the world monitoring and steering production of goods. Every factory could decide whether to upgrade and to which version. Each upgrade was a separate project, which had to go through a public offering and deploy at times when the factory was not operating. The inability of central IT to exercise influence on the factories to upgrade (due to the rollout costs) and reduce the number of parallel versions, caused a multitude of support branches to be maintained for this system. We maintained at least 6 active branches in parallel, backporting bugfixes across branches and being able to release hotfixes at any point in time for these versions. Although another VCS was used for managing source code and build artifacts, for development, we have successfully managed to use git with multiple, long-lived support branches and merge fixes across these, like in gitflow.
  • 7y ago
• alexhutcheson 7y ago
  It's honestly crazy how much time we as a community of software developers spend thinking about Git. We spend time training new engineers how to use it, we spend time researching how to un-wedge ourselves when we run into problems, we spend time standardizing preferred workflows and giving feedback when someone doesn't follow them, and we seem to spend time debating the proper branching workflows within each team or company once every couple years. When all those costs are added up, I felt more productive using svn. I can't be the only one. Ultimately I think the problem is that Git solves too many problems - it provides a very general data structure that can be used in a lot of different ways, but the tooling itself is mostly agnostic to how you want to use that data structure. Teams can define preferred workflows on top of that, but the tooling itself doesn't enforce the workflow, or provide any specific affordances that help you properly comply with the workflow. Instead, every developer is supposed to keep the workflow in their head, and make judgement decisions every time they interact with it. The cost of this is huge. We're sorely in need of opinionated tooling that sits above Git's data structures and makes real-world workflows simple to follow correctly, and difficult to mess up.
  • jaredklewis 7y ago
    As with programming languages or anything else, this would come with lots of trade-offs. Whether it is programs like Photoshop and Excel or programming languages like C and JS, general purpose tools have a lot of appeal: learn the once, use it for anything. Of course there is the opposite as well: niche tools that solve a specific problem in an opinionated way, like photo filter apps, Elm, R, etc...They have a lot of appeal too because they are better suited to the task at hand, but have limited use outside their specific domain. But the most popular and widespread tools are always from the former group. R is great, but there are always going to be more python repos on github than R repos. If git was opinionated, it would serve a smaller niche better, but other niches worse, so it wouldn't be the industry standard it is today. For better or worse, I've observed that powerful with footguns is always more popular than more limited options .
  • cryptonector 7y ago
    Eh? Branches and tags are just symbolic names for commits, and commits define the entire content of the filesystem for a codebase at that commit. That's almost all you need to know. Get that down path and you're on your way to being a Git power user. If you can't handle that, then maybe you can't handle programming either. The last thing we need is more opinionated version control tooling. We've tried it (e.g., Mercurial), and it has failed in the market. But if you want opinionated version control tooling, well, there it is for you to use.
• AzzieElbab 7y ago
  Gitflow was just a silly blog. I can't even begin to understand how it became dogma
  • shagie 7y ago
    One of the challenges of git a decade ago was that people created branches everywhere and it became difficult to reason about what branches were doing and what work should be done in them. Git flow, at that time was the most reasonable model for git branching. By reasonable I mean "able to be reasoned about". If I see a feature branch, I know what should be in it. I know what should be in a release branch. I know what the state production is in. It isn't the best branching model - but when faced with the contemporary other branching models, git flow let was an attempt to put some order to that. It also works fairly well. It isn't so much that its dogma, but rather that it is consistent and understood across different teams. The problems that it solves in communication are more important in many places than the ones that it causes in other parts of the workflow. Coming up with a new workflow isn't hard - just that one now needs to solve a different set of problems and most people don't want to have to solve those problems... and so git flow is an acceptable default.
• erik_landerholm 7y ago
  We implemented Gitflow almost exactly how it was described in the original blog post a while ago. It was simple and we built continuous deployment around it and it posed 0 challenges in that department. It was much harder to change culture and build a process and systems to actually do the continuous deployment than Gitflow ever caused. I disagree with about everything in this article.
• simonw 7y ago
  The approach that has worked best for me is pretty simple. Master should always be in a deployable state. Any commit that lands on master must include unit tests that demonstrate that it works (or at least doesn't break anything). Incomplete features that will take more than a week or so to develop should be merged to master early protected by feature flags. This avoids long running branches. I like squash commits: build a feature iteratively in a branch + pull requests, squash to master once it has the tests and documentation bundled together with the implementation. This gives you linear history. People who prefer to review smaller commits can do so in the pull request - it's only the finished item that gets squashed into a larger commit.
  • zabil 7y ago
    > Master should always be in a deployable state. +1 to this and squashing commits. I'd even go far as saying trunk based deployment model over trunk based development. This can be done via Pull requests or short lived branches. I prefer having all the context, discussions and testing added to the pull request. Even setting up environment per pull request. It's much easier to track and get feedback.
  • shock 7y ago
    > [...] unit tests that demonstrate that it works I'm going on a bit of a tangent here, but unit tests don't demonstrate that it works – acceptance tests demonstrate that it works. Unit tests help reduce the time to narrow down problems and in some cases help with refactoring (if refactoring is limited to the inside of methods).
  • arialdomartini 7y ago
    I personally don't squash commits and loose information. I see the value in having a compressed view of the log history, but in that case I use git log --simplify-by-decoration
  • anandsuresh 7y ago
    I agree with this approach. It worked beautifully for me at my last job. Keeping master ready to deploy is the way to go, along with squashed commits for a linear history. A side-effect of this approach is that it makes it super easy to bisect your way should a regression occur; something that I've found is impossible with GitFlow.
• earthboundkid 7y ago
  I recommended avoiding Gitflow back in 2018: > There are more complicated systems for branching like Git flow that have a separate “develop” branch and distinguish between “features” and “hot fixes”. These systems are fine if they fit your use case, but if a project releases code quickly, the level of complexity involved in Git Flow is unnecessary. > Ideally, branches should be short lived. One strategy to allow merging a branch before a large feature is fully completed is to create a feature flag that lets the production system have the new code in it but in an inactive state. https://blog.carlmjohnson.net/post/2018/git-gud/ https://blog.carlmjohnson.net/post/2018/git-gud/
• readme 7y ago
  The author claims that "rebasing does away with the merge commit." It's true that if you rebase you won't need a merge commit, but rebasing is compatible with the idea of having a point of reference between where branches come together, and you can accomplish that by introducing a merge commit with "git merge --no-ff" so the rebased branch doesn't fast forward on top of the target branch.
• jconley 7y ago
  In my opinion this is one of those "pick the right tool for the job" problems. If you have a constraint that forces you to have multiple versions in development and maintenance simultaneously then Gitflow works well. This is especially true for things with long QA cycles. If you have a SaaS business and pushed code can go straight to production after automated tests, then don't bother with the management overhead of the versions. In personal experience... We use Gitflow for our software that ships on our IoT device where we do monthly releases and multiple weeks of QA/reliability testing. Of course, this is coupled with a slow rolling canary release process -- nobody wants customers to be forced return a device due to a bug that can't be fixed over the air. We also use it on our mobile app and it works well. Again, this is a situation where we have to have multiple versions in development simultaneously. One in "release mode" doing critical bug fixes only as it goes through QA and internal in-home acceptance testing and one for "v-next". Some 20 years ago we used to do roughly this same process for releasing software on CD's. But, no git back then so no "Gitflow"... We don't use it for various services and internal tools that can get by without such rigor around versioning. Just simple branch -> PR -> automated test -> merge to master from PR -> automated test -> deploy. Use the tool/process with the least overhead that manages what you need managed.
  • alasdair_ 7y ago
    >If you have a constraint that forces you to have multiple versions in development and maintenance simultaneously then Gitflow works well. Because of the way App Store approval works, and the fact that it can take weeks from initial submission to full rollout, and that many users never upgrade their versions, strongly implies that using something like gitflow would work well for teams delivering appstore binaries.
• freetime2 7y ago
  My team uses git flow as the basis for our branching strategy. We’ve streamlined things a bit over the years as we’ve found we didn’t need all the flexibility/complexity in that model, but we’re still using a develop branch, feature branches, release branches, tagging our releases, etc. It works fine for us, and we spend very little effort on branching or merging. I wouldn’t hesitate to recommend git flow as a starting point to any team. Just make sure you don’t follow it dogmatically... if there are tweaks that you can identify to better serve your team, go ahead and make them.
• heelix 7y ago
  We use several branching strategies - all depends on the size of the codebase and the number of teams involved. Some work just fine with a trunk based workflow, some need that extra bit of layers. What I don't get is the infatuation with GitOps, where someone insists on replacing a process with a source code repository and webhooks. Starting to see excessive scripting/bots to talk with GIT bots...and it is so kludgy.
• jrumbut 7y ago
  I recall converging toward something a lot like git-flow because, especially when there were hot fixes, you might get conflicts rebasing the feature branch and conflicts again merging the feature branches, doing the work twice at least. Additionally, it was so important everyone used the same procedure to accomplish merges or whatnot or else there would be all kinds of problems. Sometime ago I noticed I hadn't seen this in a while. Is this anyone else's experience? Have people just gotten better at git or was there a major improvement in how git handles this scenario? If it was about improvements, has anyone written those changes up? It would be fascinating to know how it was done.
• 89vision 7y ago
  Anecdotally, it's worked well for my current project as any other branching model I've worked with. It allows release validation to happen while developers continue to work on features. The author seems to bash the workflow without offering up any solution or alternative.
• autarch 7y ago
  The author says: > While I hesitate to say “Worrying about merge conflicts” is a valid reason not to pursue a branching strategy like gitflow I do not hesitate! This is _very good_ reason to avoid gitflow. Merge conflicts by definition require human intervention. And human intervention means an opportunity for human error. Resolving merge conflicts properly ranges from trivial to nearly impossible, depending on the specific changes you're trying to merge. Often none of the authors involved in the conflict are in a good position to understand why it happened. One person makes a small bug fix change to a few lines of code. But that fix required hours of research and a solid understanding of the problem. Meanwhile, someone else is doing a refactoring of that same code in another branch, unaware of the bug. Neither of these two people may be in a good position resolve the conflict. The bug fixer doesn't understand the refactoring, so they don't know how to apply the bug fix in the new code. The refactorer doesn't understand the subtleties of the bug fix and the code being fixed is just gone in the refactor. It's going to require the two of them working together to fix this, and it may took several more hours and they still may not get it right. And that's the best case! Realistically, one person will muddle through the merge and hope that things still work properly. Of course, merge conflicts are a fact of life in _any_ version control scheme without exclusive locks (remember RCS?), but minimizing them is a very valid goal.
  • mikeruhl 7y ago
    perhaps people do gitflow incorrectly? I've been using it for several years and, on teams of about 10-15 people, have rarely had merge conflicts. Feature branches should be short-lived and therefore avoid conflicts. Hotfixes pose a risk to conflicts, but that's their nature. Say you have bug in production code and you fix it via a hotfix and some other developer stepped on that code on the develop branch, you should have a human reviewing the bug fix's merge with the new feature in development. I really didn't understand this post. To me, it seemed like someone writing a critical perspective of a process they don't fully understand. I know it's not because of a lack of documentation, git flow has been blogged about ad nauseam. I have friends who use different branching strategies who complain constantly about the same pain points the author brought up. The only thing I agreed with the author with is to find a strategy that works.
  • 7y ago
• Buttons840 7y ago
  > If you pursue gitflow, you’re gonna have to give up rebasing. Remember, rebasing does away with the merge commit — the point where you can see two branches coming together. I disagree with this. You can rebase your branch and then do a "no fast forward" merge. You'll end up with something like: * Merge commit |\ | * My branch commit 3 | * My branch commit 2 | * My branch commit 1 |/ * Base Notice I have not "done away with the merge commit". When you rebase your branch on top of "Base", and then try to merge, git will by default do a fast-forward merge, but you can prevent it from doing so. It is as though you created your branch, did your work, and then merged it back in so quickly that no other branches were created in the meantime, and if we ignore what I personally did on only my own computer, then I am still following Gitflow.
  • giancarlostoro 7y ago
    I dont even get why people rebase for a merge. I never did this and I get the entire history not a distorted version of it. On top of which I can go back between commits and even revert a very specific commit. Reality is everyone prefers to organize code differently I prefer to have all the commit history. It is more meaningful to see all the files involved in a single stage of a commit than potentially multiple changes in one PR all blended together.
    • alasdair_ 7y ago
      I hate rebases because they create multiple hashes for the same logical commit. It confuses the crap out of me sometimes. Also, they tend to involve more manual processing, and thus human error, then merges.
      • u801e 7y ago
        > I hate rebases because they create multiple hashes for the same logical commit Some of those commits may have changed (either the commit message or the diff itself). There's a git command called range-diff[1] that was added recently that allows you to diff between rebases. > Also, they tend to involve more manual processing, and thus human error, then merges. Before actually pushing up the rebased branch, you run a diff against the upstream tracking branch to see if any inadvertent changes were introduced. For example: git diff @{u}.. And use the range-diff command to see the difference between the upstream tracking branch and your locally rebased branch. [1] https://git-scm.com/docs/git-range-diff https://git-scm.com/docs/git-range-diff
• pgporada 7y ago
  We use a rebase heavy workflow and I love it.
• ramzyo 7y ago
  The most salient points for me were actually made in the last paragraph. IMO would have improved the article to put this at the top rather than at the bottom. > The crucial point I’m making is to is ask questions of your team: What problems will this branching model help us solve? What problems will it create? What sorts of development will this model encourage? Do we want to encourage that behavior? Any branching model you choose is ultimately meant to make humans work together more easily to produce software, and so the branching model needs to take into account the needs of the particular humans using it, not something someone wrote on the internet and claimed was ‘successful’.
• kunglao 7y ago
  Something that really surprised me is how anyone has issues with git work flows. Git is one of my favourite software and I think it solves version control and collaboration issues beautifully. I can unhesistently say only one of the teams used git recall really well and we didn't agree on a work flow or no one was dogmatic about it. Each seemed to just know what they were doing. I think just create your own branch always for your work is a good idea. Use merges to take or give contributions (reduce using complex things like rebases). If branching on sub branches, try not to squash merge. You can't avoid conflicts all the time but just sticking to branching and merging reduces this problem quite a lot. Team size has been about 12 engineers not sure how it'll impact team of much larger projects. But I have also contributed to open source projects using this same techniques without an issue.
• phodge 7y ago
  I've never liked git flow due to: A) the way it abuses the commit DAG: you never merge master directly back to develop, and so your tags don't become ancestors of the commits on develop until some timer later when an unrelated hotfix is branched from master. E.g., you can't rely on "git branch --contains v1.0.1" to tell you which branches do/don't contain the 1.0.1 hotfix because the hotfix branch was merged to develop, but not the merge commit that was tagged as 1.0.1. B) its blatant disregard for one of the most basic software development principles: when you want to deploy a new version of your software, you test a specific a revision of your code and that's the revision that you deploy. With Git Flow, you go to great lengths to ensure your release branch is isolated from other work for testing, but then you merge to master and deploy the merge commit instead of the commit you just tested.
• m3kw9 7y ago
  Without looking at how Gitflow works it seems like it’s some Adhoc branch system a lot of company uses in one form or another.
• 6510 7y ago
  In my ignorance I once pondered a model where [rather than teams] everyone gets their own object named after them. Something like JohnDoe.sortTable(foo) (Besides from being a stupid idea on so many levels) it seems fun to reason about: John doesn't sort the table properly. When John gets hit by the bus you have a really good idea what you've lost. You also get to identify the productive and unproductive.
• artellectual 7y ago
  On the contrary my team and I have been having great luck with git-flow. When I onboard a new team member I watch them struggle with git-flow and for me that's a great thing to see because I see them learning an efficient way to work. Once they 'get it' everything flows smoothly, and everyone has the same way of working which makes it very easy to see and help debug when things happen. Communication is also consistent across all team members partly because of the git-flow branching model. We as a team understand why / when to use feature branch, when to use hotfix, when to cut a release etc... That's what I expect from a team. Git flow has been great for our team and workflow. To each their own. I guess I will continue recommending git-flow.
  • crehn 7y ago
    > I watch them struggle with git-flow and for me that's a great thing to see because I see them learning an efficient way to work Maybe they're struggling because it's not efficient, or intuitive?
    • artellectual 7y ago
      No they struggle because they don’t know the workflow which is what gitflow teaches them. Once they learn it things work very well and they go on to teach other people.
• tomerv 7y ago
  The article claims that "gitflow abandons rebasing", but this is simply not true! In my team we use gitflow with rebasing. In fact, the original gitflow implementation comes with rebasing support built-in (as a flag for the "git flow feature finish" command). We just modified the script to enable it by default. Another thing we changed is dropping the "master" branch, since it didn't provide anything useful. Now, you could claim that this means we're not really using gitflow, due to all these modifications. But the fact is, I still give this article as mandatory reading for new developers in our team, and it's still a great introduction for working with feature branches. I'll continue to recommend gitflow.
  • Silhouette 7y ago
    Another thing we changed is dropping the "master" branch, since it didn't provide anything useful. This is the one thing about Git Flow that I never quite understood. Feature branches, great. Main develop line, sure. Release branches, OK. But what is the advantage of maintaining a master branch that gets some nominal end point for releases merged in and tagged? In reality, one of the main advantages of a Git Flow style of workflow is that it doesn't assume you can just conveniently forget history, maintain a single current version of your product, and deploy changes on a whim. Instead, you can maintain a normal process for new development, but also keep control of old releases and of release processes that might involve significant extra steps. But all of the latter benefits come from using release branches, not the odd way of merging from those branches to master, which isn't at all used in the conventional way in Git Flow. Indeed, the master branch implies a linearity of releases that probably doesn't make much sense for a lot of projects. You might need to push out something like a security fix for several older versions, which is easily represented by making a new tagged public release from each of the earlier release branches, but then what even should be merged to master according to Git Flow?
• justlexi93 7y ago
  Gitflow might work for some projects/teams but it shouldn't be treated as a reasonable default.
• bArray 7y ago
  I think Gitflow is the larger picture, but I think most teams can afford to merge parts together. I run a small team and we typically will just use "feature" and the master branch. If it compiles and passes the basic tests, it's master worthy. If it passes more heavy testing then it's tag worthy. Features can sometimes be bug fixes depending on the size. Typically we try to merge branches in less than two weeks to prevent some kind of merge hell. The assumption that master is somehow perfect is wrong and it shouldn't be treated as such. In my opinion tags are really for commenting that there's something interesting about a commit (i.e. "we ran this for 2 weeks at full load and no issues observed"). Again, tags also don't say there are no issues, it just says there was something note worthy.
• aaanotherhnfolk 7y ago
  My company uses gitflow and releases daily from a monorepo with a team of 40 devs. Some of us rebase. Everyone is happy. I think that disproves just about every point in the blog post. I have no idea what non-obvious thing, if any, we're doing to make this work. Then again I don't think gitflow is complicated either.
  • IanSanders 7y ago
    I think the main point here is that it doesn't work for everyone, and is not a silver bullet. (Which is evident from comments)
• Olipro 7y ago
  I implemented a variety of GitFlow, but with an emphasis on automation. Normally you branch off of develop; hotfixes will be a branch off of master. Feature branches are combined with develop before being built and tested. If it passes, it becomes mergeable in GitLab. all builds of develop that pass are taggable; you go into the CI interface and specify a tag. Once deployed, master is updated by the CI to point to that tag. The most valuable part of this is the CI pipeline and having a solid body of tests to ensure that changes which don't necessarily conflict in Git will most likely be caught during test, prior to it being allowed for merge.
• trixie_ 7y ago
  I'm in the camp that rebasing is unnecessary and useless for large projects. I work in a code base with 50 other devs, no one is reading the commit log line by line, there are 100 commits per day. We use JIRA and have to prefix our commits with TICKET-<ID>. If I want to see the commits for a ticket, I filter the git log on that. If I want to see the combined diff for the commits, I open up the PR in JIRA. Squashing public commits I'm also against. People say it 'cleans' the history. I would say it erases it. Who, when, why - all gone. For what? to save a few commit lines? Like I said, our commits are tagged with the ticket number already, if you want a summary of what the changes were and all the commits that were part of it, you open the ticket, or filter the git log on the ticket. No need to move commits around in the history, they show in the same order when you apply a filter.
  • Vinnl 7y ago
    > no one is reading the commit log line by line, there are 100 commits per day. I hardly ever refer to the commit log. However, I do often run `git blame` to figure out what changes were done to the code base together with a specific modification to a specific line of code. That works so much better if people have actually spent some effort to make sure related work is in a single commit. (Note that this doesn't mean "squash every PR together" - it means rebasing before submitting a PR to make sure the commits also work as documentation. The result of that rebase might very well be several commits.)
  • mixmastamyk 7y ago
    Sometimes the cure is worse than the disease.
  • plorkyeran 7y ago
    You've just described the problem that rebasing fixes. Because your git history is a mess you have to look up PRs in Jira rather than having your git history be something useful by itself.
    • mcv 7y ago
      How does rebasing fix any of that? Rebasing changes your history, and can just as easily make a mess of your history as it can make it prettier. I use it sparingly, but I don't mind people avoiding it altogether. Rebasing fixes nothing.
• Ace17 7y ago
  > While I hesitate to say “Worrying about merge conflicts” is a valid reason not to pursue a branching strategy like gitflow Being worried about merge conflicts might be a sign that your continuous integration might not be continuous enough.
• Ace17 7y ago
  GOTO 2017 • Feature Branches and Toggles in a Post-GitHub World: https://www.youtube.com/watch?v=lqRQYEHAtpk https://www.youtube.com/watch?v=lqRQYEHAtpk TL;DW: integrate continuously, don't use branches, use feature toggles.
• brigandish 7y ago
  > Take a look at this image and tell me it’s immediately intuitive I'm using Git, there's nothing intuitive to be found here. On a possibly related note, I watched a talk by D. Richard Hipp (I don't remember which one - edit: probably "Richard Hipp - Git: Just Say No"[1]) where he compared it with Git (a lot) and explained how Fossil keeps everything, there's no throwing away of history, no need for rebasing (at least as a workflow). It sounded nice - refreshing, even. I'm going to start using it for some projects and see how I get on, because frankly, I'm tired of Git and this need to strategise saving copies of my work, because that's basically what it does. Sometimes I even pine for the days I used to version zip files… [1] https://www.youtube.com/watch?v=ghtpJnrdgbo https://www.youtube.com/watch?v=ghtpJnrdgbo
• globular-toast 7y ago
  At my current job when I started people were doing git flow. It was horrendously complicated. I got rid of it and now everyone is happier. The idea is really simple. You have one eternal branch, "master", which is your integration branch. This is set to be the upstream of all other branches during development. That means it's really easy to keep rebasing on master every day. When your branch is ready it's merged into master (I do fast-forward only, but that doesn't matter). When you want to release, just tag a commit on master. If you want to maintain releases, make release branches for these and cherry pick fixes from master. Reset the maintenance branches to whatever release you are maintaining. It's easy.
• sitzkrieg 7y ago
  funny thing about git flow is that working with nvie (who coined/created it) at gitprime, they did NOT like it in practice. we just used feature branches go figure
• rawoke083600 7y ago
  I use: 1. Master should be always deployable: 2. All features are a separate branch BUT, when merged into master they should also have a config for ON/OFF. This has the benefit of quickly switching between old and new behaviour(feature) as well as forcing a "module-based-architecture" for the code.
  • borplk 7y ago
    One problem with #2 is many types of changes are impossible to toggle on/off (I mean "change to codebase" not "product feature").
    • rawoke083600 7y ago
      True, #2 is not always feasible, but lol the dev can damn well try :P