11 ms·

The Problem with Git Flow

147 points by silasdb 6y ago

pronoiac 6y ago
> run all tests on all the commits That gave me pause; I'm used to relatively small commits, for easier review and verification, so that seemed too much. Reading the link, I think they mean, run tests on every branch on every push.
- gindely 6y ago
  if you push a fail it might be nice to have it autobisect tho.
- romanr 6y ago
  In Gitlab you can add “ci skip” to commit message to skip CI run
bredren 6y ago
I am a fairly committed practitioner of git flow on multiple projects. The problem of not easily linking feature branch names to issues is real, though I have been solving this using: `[issue id]/feature-or-issue-title-abbreviated` And while you don’t get nice hyperlinking from the branch references on GitHub—-and it’s possible for the issue title to be out of sync with the feature branch name at times, it isn’t too bad and I don’t often need to go back and look at a feature branch. Perhaps projects with bigger teams this is more important and the linking / strong issue attribution to the branches is more meaningful. I’m less clear on the removal `develop`. It makes more sense to me to use master as this serious “released” state. And for develop to be a bit more loose. More importantly, I typically will run `develop` on a staging instance. So it’s pretty important to me. I still do testing on ‘develop’ and feature branches before they are merged. I also don’t feel like the start / finish release process is all that onerous. From a commercial standpoint, I’m not a huge fan of tossing GitLab into the concept name. It’s a little brand-y on something that just doesn’t need it.
- jlgaddis 6y ago
  > From a commercial standpoint, I’m not a huge fan of tossing GitLab into the concept name. It’s a little brand-y on something that just doesn’t need it. I imagine it's meant to be a response to "GitHub Flow" [0]. --- [0]: https://guides.github.com/introduction/flow/ https://guides.github.com/introduction/flow/
wcarss 6y ago
Trunk flow has a lot going for it. Here's a link in case others don't know of/haven't heard about it -- it starts off with a tl;dr summary: https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/ One of the key elements of trunk flow that I value about it is that "the software you released" is not a living stream. Because of that, it should not be tracked by a long-lived branch with commits that flow in in over time except in rare fix situations. With trunk flow and similar styles, you can always merge to master, and you can always deploy master. You do so by cutting a new branch, and in my opinion, you then build a static artifact. Next time you deploy, you cut another branch, build your artifact, and put it somewhere. Need to do a hotfix, but there's other work since last release that you just can't ship? Cherry-pick onto the currently-deployed release branch, not onto some long-lived production branch. There's no weird merge-backs, no strange no-op commits in a long-lived history. trunk-flow is also very simple. For these and other reasons, it's great. And, some key points about building static deployment artifacts: if you build an artifact to deploy at merge-time to master, you can avoid having your production servers download and execute code for you. You can test your exact artifact before you ever send it to production. You can reproduce your builds. Left-pad-like library unavailability issues can't hit between staging and production. Deployments to production are very fast. You can keep a few artifacts around and roll back quickly and reliably to working states (barring database stuff!). You can deploy two versions to different userbases at the same time. It's very useful. :)
- dionian 6y ago
  never seen the site, expected to find something i disagree with, but found that it matches the way I've always worked. Merging early and often and using CI is the way to go and avoid being in the merge process as much as possible. Going to share this with people to explain my workflow, great resource
- jes5199 6y ago
  yeah, this is the one I use. I think of it as the “default” now - it’s been a while since I worked on a team that used anything else, I guess that means it’s popular with small startups
- tempodox 6y ago
jdlshore 6y ago
Martin Fowler wrote a superb discussion of branching strategies. It's here: https://martinfowler.com/articles/branching-patterns.html https://martinfowler.com/articles/branching-patterns.html
ablanco 6y ago
I don't think this is a problem with git-flow, it's more a problem of using git-flow when you don't need it. I use git-flow on projects that need to be installed by various different clients and there's no way to force all of them to migrate to the latest version, so you have to maintain support for older releases. When the software needs to be installed in a single place and you can do it with CI/CD theres no need for the git-flow complexity.
sane_Doyle 6y ago
I rarely share my story with people, not only because it put me at the lowest point ever but because it made me a person of ridicule among family and friends. I put all I had into Binary Options ($100,000) after hearing great testimonies about this new investment strategy. I was made to believe my investment would triple, it started good and I got returns (not up to what I had invested). Gathered more and involved a couple family members, but I didn't know I was setting myself up for the kill, in less than no time all we had put ($300,000) was gone. It almost seem I had set them up, they came at me strong and hard. After searching and looking for how to make those scums pay back, I got introduced to (Troyhermes8@gmail.com) He helped recover about 90% of my lost funds within a month.
sebazzz 6y ago
We currently use a simplified version of gitflow. Essentially we picked only the master, develop, and release branches from it. Of course we do have experimental branches but all nowhere as complicated as gitflow.
viraptor 6y ago
I've got strong feelings about git-flow, but I think the main thing all these "generic flow" solutions are missing is: what are your project requirements? Some projects need release branches, some projects use continuous deployment, some projects need manual QA, etc. There is no solution that will work for everyone, so unless your flow description starts with assumptions and matching requirements, it's wrong. (for some people reading about it)
- tempodox 6y ago
  This one is an ad for a payed service, so one can't expect a broad take on the subject. The usual “caveat emptor” applies.
  - viraptor 6y ago
    I slightly disagree. It doesn't cost anything to prefix: "There are many ways to approach it, which will differ depending on your needs. Here's a solution which we believe will work for most, so we want to name it and make it simple for you to apply." It doesn't take anything away from the rest of the content.
sn1de 6y ago
I honestly thought they were finally renouncing GitLab flow as a massively misguided idea. They are both flawed. You shouldn't be using branches in your version control system to denote stages in your development process or deployment targets. It totally breaks down when you move to CICD, which should be your goal. Trunk based is the way to go. These git flow things persist because that is what the search engines puke up when people google for git branching.
- aidenn0 6y ago
  CD doesn't work for many types of software; it's not uncommon for customers to want only bugfixes (or even security bugfixes only), and that means branches.
- boleary-gl 6y ago
  GitLab Developer Evangelist here GitLab flow is much closer to trunk based development than git flow is. While no one "flow" works for everyone, I think that we are clearly in agreement that the simpler you can make your workflow, the better. The problem is some companies and organizations can't get all the way to trunk-based development based on their own regulatory needs or the type of software they are producing. That's why we think GitLab flow is a great way to balance both - in fact in the other linked blog post [1] we mention that GitLab flow should allow for CD from either branches or tags. From the main branch would then basically be the same as trunk based development, yes? [1] https://about.gitlab.com/blog/2016/07/27/the-11-rules-of-gitlab-flow/ https://about.gitlab.com/blog/2016/07/27/the-11-rules-of-git...
WWLink 6y ago
Between monoliths, this discussion, and other complaining about git I see around here, I wonder just how many of you are using subversion lol.
- sidlls 6y ago
  git's got some great features for very basic development workflows and the fact that it's distributed is undeniably a significant advantage. What amuses me, though, is all the ceremony and patterns in the use of git that restrict its use in ways that are sort of pale reflections of subversion, P4 and similar version control systems.
  - WWLink 6y ago
    I like the distributed nature of git, the ability to make local commits, jump airgaps with bare repos, submodules, shallow clones, all kinds of silly things I suppose. I won't lie, I don't have a ton of experience with subversion, but whenever I've used it, it felt incredibly limiting.
servilio 6y ago
There is a need for simplified workflows, but this sounds and looks like an exercise in brand marketing more than a good analysis on how to offer a better Git workflows. > Git flow forces developers to use the develop branch rather than the master. Because most tools default to using the master, there’s a significant amount of branch switching involved. I'd like to see this fleshed out, since whatever branch naming convention or roles you use, you will be switching the same amount. > Another frustrating aspect is hotfix and release branches, which are overkill for most organizations and completely unnecessary in companies practicing continuous delivery. Yes and no. If you don't separate master from develop, hotfix branches just work like feature branches. But if you need them separated, then... > Bug fixes/hot fix patches are cherry-picked from master Avoid doing this, use daggy fixes[1], and it will make it breeze to check that a fix was actually merged and where[2]. And if you do cherry pick, at least use "-x". [1] https://wiki.monotone.ca/DaggyFixes https://wiki.monotone.ca/DaggyFixes [2] git branch --contains <commit>
ramenmeal 6y ago
I'm not a fan of merging master -> production for deployments. This means that what you tested in master may not be the same artifact that is deployed to prod. You're relying on people to correctly handle merge issues in git. This can become an issue if you have some complex hotfixes that have to happen. edit: I'd rather trunk based w/ tagging commits for releases.
- donmcronald 6y ago
  Yeah. I wonder if that merge to production rebuilds artifacts. That seems nasty.
dastx 6y ago
I don't quite understand why people don't keep it simple. Use short lived branches, and merge to master. Need to do a release? Master is your release. Tag the release when it's ready. Need to make a hot fix onto the current deployed version? Create a release branch from the tag, and then create a new tag and merge back to master. This combined with semver gets you far. I've yet to find any downsides with this approach.
- AlphaSite 6y ago
  Try doing that with a long lived product, where people don’t upgrade. You need to be able to backport fixes for that customer who pays your bills, but is 6 versions behind.
  - cfstras 6y ago
    This is an entirely different problem - your customer doesn’t install releases, but they do install fixes? What is the reason for that?
    - kingosticks 6y ago
      Our customers don't want to spend vast amounts of time qualifying an entire new release when they can accept an isolated fix instead and do more focused testing. They might need the fix for some critical part of their product. If I was them I'd do the same - if the rest ain't broke, why risk fixing it?
      - cfstras 6y ago
        If the qualifying process is long and expensive, doing a one-off fix does seem more logical. This is assuming you can be sure the fix really is isolated. I do feel like a lot of companies over-exaggerate the need for multiple supported releases.
    - Cthulhu_ 6y ago
      Risk mitigation and investment; my employer's software does critical mobile network infrastructure, if they have an outage it affects millions of people. So, if our customers upgrade the software, they want to do their due diligence in their particular use case (it's a flexible system). That said though, software should be built to allow for fast and painless upgrades. Backwards compatibility and many use cases should be tested automatically and constantly. But, it's a big investment to have software like that, and you need to resist a lot of younger, eager developers that want to e.g. introduce a new language or make sweeping changes.
renewiltord 6y ago
Gonna be honest with y'all. You don't need a git workflow. Seriously, YAGNI. Deploy every `master`, no other restrictions. Git workflows are over-engineering.
- AlphaSite 6y ago
  That works if you have a deploy step. There’s a world beyond SAAS. A very lucrative one.
  - renewiltord 6y ago
    Oh that's entirely fair. I was 100% thinking SaaS because of the website we're on, but if you do have to maintain multiple versions for whatever reason, you're going to need a complex flow with multiple trunks.
    - kingosticks 6y ago
      I don't see how SaaS is immune to this. You could easily find yourself with a big customer that effectively wants their own deployment and doesn't want updates (new bugs / big changes) but still demands occasional fixes/features that you often want to also merge into the main deployment.
      - renewiltord 6y ago
        It's not immune since few things in life have a measure zero or measure one probability. It is unlikely, though, imho.
      - steve_taylor 6y ago
        The key is to avoid having customers so big you can’t afford to lose them.
dragonwriter 6y ago
What a clickbaity title; there's no substantial discussion of Git Flow at all; the paragraph they actually spend discussing two minor issues sounds like it was written by someone who has never done serious work in Git Flow. Should be titled “The sales pitch for GitLab Flow”.
danw1979 6y ago
> Git flow forces developers to use the develop branch rather than the master. No it doesn’t. > Another frustrating aspect is hotfix and release branches I beg to differ. I know what would be frustrating though: > GitLab Flow is a way to make the relationship between the code and the issue tracker more transparent. Each change to the codebase starts with an issue in the issue tracking system. ... tying my repo to one particular git hosting platform.
hellofunk 6y ago
Trunk-based development FTW!
tupac_speedrap 6y ago
How is git flow complicated? I feel like some developers are doing shonky stuff with git branching and then blaming it on the branching strategy. If you used a system with less use of branches you'd just end up with dodgy code in master instead.
0x00101010 6y ago
man gitworkflows
alkonaut 6y ago
I immediately spot one huge issue with this > The production branch is essentially a monolith – a single long-running production release It assumes that only one version is deployed at a time, so you can't really service version1.0 after you shipped version2.0. Having multiple independent maintenance branches for production is critical for any branch pattern that should apply to both web software (normally single deployed version) and e.g. Desktop (normally multiple deployed versions). Th
somewhereoutth 6y ago
I think this sort of thing might become much more tractable if it were possible to visualize a git repo as it actually is - i.e. a directed graph of commits (occasionally with two parents - a merge commit), with moving labels (branch names) and fixed labels (tag names). Like when you buy a small shrub from the garden centre and it has a label attached to it somewhere. Pushes and pulls can then be visualized as two such shrubs reconciling themselves.
- nicky0 6y ago
  Interesting analogy, but as a gardener, I've never encountered the concept of a shrub reconciling itself so I have no idea what this visualization reveals!
  - somewhereoutth 6y ago
    Imagine a shrub made of shrub A and shrub B. Parts of the shrub (from the root) are from both, parts are from A only, and parts are from B only. Imagine also the 2 sets of labels from A and B. It would become clear how the push/pull is updating its target shrub, and indeed if and what bits of the 2 shrubs (or their labels) conflict.
polymeris 6y ago
On the topic of Git Flow and simpler & faster alternatives, last month I published a short blog post about my experience learning those alternatives exist at CircleCI[1]. The most important learning for me was that things like Git Flow aren't free: they slow you down and make developers feel more detached and less responsible for the code that's running in prod. [1] https://circleci.com/blog/you-are-what-you-git-how-your-vcs-branching-model-affects-your-delivery-cadence/ https://circleci.com/blog/you-are-what-you-git-how-your-vcs-...
rob74 6y ago
Interesting tidbit: according to the "SEO-friendly" URL, the title should actually be "what-is-gitlab-flow" - I wonder if that was also the original title of the article, before it was changed into something more "clickbaity"?
thisisastopsign 6y ago
Sometimes I feel there should be a survey for Git methods and people vote on it. Repeat annually. Eventually we'll settle the debate
steve_taylor 6y ago
This is idiotic. Different situations call for different workflows. Working in a corporate environment with planned, infrequent releases? Use Git Flow. Doing continuous delivery instead? Use the feature branch workflow. This smells like GitLab trying to increase its ownership of the ecosystem.
king_magic 6y ago
I've literally never had a problem with Git Flow, nor have any developers I've worked with. It's fine.
malinens 6y ago
the problem is that gitlab works very bad with other git flows and they are ignoring issues about them so they force their own flow sadly... I still enjoy working with gitlab but this annoys me very much
somewhereoutth 6y ago
I feel a whole lot of problems would just go away if merge was abandoned. Thus every 'merge' would require a rebase (and subsequent deletion of the merged in branch), and branches stay as branches. For example it then becomes obvious and inevitable that hotfixes must be on an independent maintenance branch (cherry picked in/out of the master if appropriate). There is no longer the proliferation of merged in feature branches - only features currently worked on (and yet to be rebased) would have a branch. There is no concept of release vs master vs dev as it is not possible to merge one into the other. Push/pull is fast forward or force rebase. Easy enough to write a wrapper around git to do this - I am tempted.
jjuel 6y ago
Am I missing something or is this pretty much Gitflow with develop being named master and master named production? Maybe I don't fully understand Gitflow or we are using it like Gitlab Flow already with different names.
sane_Doyle 6y ago
when I thought about the way things have been recently, i owe my thanks to God for letting me find this amazing personality, i mailed Mrs Deja Ellie roughly 2 months now, I was actually very uncertain about investing, very scared because i was also low on cash. I gave it my all, my first investment of $2,000 two weeks ago brought me $ 29,230 last week, and what intrigues me the most is the way him handles he partners, i recommend him too to my friend jeff, after trading with her, his testimonies have let me come here to attest for her. We are happy to meet a professional in you. I am proud to recommend her to any person who has a passion for trading, meet a good mentor and get good fortunes. Contact this veteran trader Dejaellie@gmail. Com
einpoklum 6y ago
My problem with this suggestion is, that I tend to do history rewrites on the development branch, if I realize I've fucked something up; but I don't do that on master. So on master, broken things get fixed with a new commit; on development - sometimes, sometimes they get fixed retroactively. That means that you can safely "git pull" the master branch, always, into the future, but if you try to pull the development branch, you may well fail.

147 points by silasdb 6y ago

> run all tests on all the commits That gave me pause; I'm used to relatively small commits, for easier review and verification, so that seemed too much. Reading the link, I think they mean, run tests on every branch on every push.

gindely 6y ago
if you push a fail it might be nice to have it autobisect tho.
romanr 6y ago
In Gitlab you can add “ci skip” to commit message to skip CI run

bredren 6y ago

I am a fairly committed practitioner of git flow on multiple projects. The problem of not easily linking feature branch names to issues is real, though I have been solving this using: `[issue id]/feature-or-issue-title-abbreviated` And while you don’t get nice hyperlinking from the branch references on GitHub—-and it’s possible for the issue title to be out of sync with the feature branch name at times, it isn’t too bad and I don’t often need to go back and look at a feature branch. Perhaps projects with bigger teams this is more important and the linking / strong issue attribution to the branches is more meaningful. I’m less clear on the removal `develop`. It makes more sense to me to use master as this serious “released” state. And for develop to be a bit more loose. More importantly, I typically will run `develop` on a staging instance. So it’s pretty important to me. I still do testing on ‘develop’ and feature branches before they are merged. I also don’t feel like the start / finish release process is all that onerous. From a commercial standpoint, I’m not a huge fan of tossing GitLab into the concept name. It’s a little brand-y on something that just doesn’t need it.

jlgaddis 6y ago
> From a commercial standpoint, I’m not a huge fan of tossing GitLab into the concept name. It’s a little brand-y on something that just doesn’t need it. I imagine it's meant to be a response to "GitHub Flow" [0]. --- [0]: https://guides.github.com/introduction/flow/ https://guides.github.com/introduction/flow/

wcarss 6y ago

Trunk flow has a lot going for it. Here's a link in case others don't know of/haven't heard about it -- it starts off with a tl;dr summary: https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/ One of the key elements of trunk flow that I value about it is that "the software you released" is not a living stream. Because of that, it should not be tracked by a long-lived branch with commits that flow in in over time except in rare fix situations. With trunk flow and similar styles, you can always merge to master, and you can always deploy master. You do so by cutting a new branch, and in my opinion, you then build a static artifact. Next time you deploy, you cut another branch, build your artifact, and put it somewhere. Need to do a hotfix, but there's other work since last release that you just can't ship? Cherry-pick onto the currently-deployed release branch, not onto some long-lived production branch. There's no weird merge-backs, no strange no-op commits in a long-lived history. trunk-flow is also very simple. For these and other reasons, it's great. And, some key points about building static deployment artifacts: if you build an artifact to deploy at merge-time to master, you can avoid having your production servers download and execute code for you. You can test your exact artifact before you ever send it to production. You can reproduce your builds. Left-pad-like library unavailability issues can't hit between staging and production. Deployments to production are very fast. You can keep a few artifacts around and roll back quickly and reliably to working states (barring database stuff!). You can deploy two versions to different userbases at the same time. It's very useful. :)

dionian 6y ago
never seen the site, expected to find something i disagree with, but found that it matches the way I've always worked. Merging early and often and using CI is the way to go and avoid being in the merge process as much as possible. Going to share this with people to explain my workflow, great resource
jes5199 6y ago
yeah, this is the one I use. I think of it as the “default” now - it’s been a while since I worked on a team that used anything else, I guess that means it’s popular with small startups
tempodox 6y ago

jdlshore 6y ago

Martin Fowler wrote a superb discussion of branching strategies. It's here: https://martinfowler.com/articles/branching-patterns.html https://martinfowler.com/articles/branching-patterns.html

ablanco 6y ago

I don't think this is a problem with git-flow, it's more a problem of using git-flow when you don't need it. I use git-flow on projects that need to be installed by various different clients and there's no way to force all of them to migrate to the latest version, so you have to maintain support for older releases. When the software needs to be installed in a single place and you can do it with CI/CD theres no need for the git-flow complexity.

sane_Doyle 6y ago

I rarely share my story with people, not only because it put me at the lowest point ever but because it made me a person of ridicule among family and friends. I put all I had into Binary Options ($100,000) after hearing great testimonies about this new investment strategy. I was made to believe my investment would triple, it started good and I got returns (not up to what I had invested). Gathered more and involved a couple family members, but I didn't know I was setting myself up for the kill, in less than no time all we had put ($300,000) was gone. It almost seem I had set them up, they came at me strong and hard. After searching and looking for how to make those scums pay back, I got introduced to (Troyhermes8@gmail.com) He helped recover about 90% of my lost funds within a month.

sebazzz 6y ago

We currently use a simplified version of gitflow. Essentially we picked only the master, develop, and release branches from it. Of course we do have experimental branches but all nowhere as complicated as gitflow.

viraptor 6y ago

I've got strong feelings about git-flow, but I think the main thing all these "generic flow" solutions are missing is: what are your project requirements? Some projects need release branches, some projects use continuous deployment, some projects need manual QA, etc. There is no solution that will work for everyone, so unless your flow description starts with assumptions and matching requirements, it's wrong. (for some people reading about it)

tempodox 6y ago
This one is an ad for a payed service, so one can't expect a broad take on the subject. The usual “caveat emptor” applies.
- viraptor 6y ago
  I slightly disagree. It doesn't cost anything to prefix: "There are many ways to approach it, which will differ depending on your needs. Here's a solution which we believe will work for most, so we want to name it and make it simple for you to apply." It doesn't take anything away from the rest of the content.

sn1de 6y ago

I honestly thought they were finally renouncing GitLab flow as a massively misguided idea. They are both flawed. You shouldn't be using branches in your version control system to denote stages in your development process or deployment targets. It totally breaks down when you move to CICD, which should be your goal. Trunk based is the way to go. These git flow things persist because that is what the search engines puke up when people google for git branching.

aidenn0 6y ago
CD doesn't work for many types of software; it's not uncommon for customers to want only bugfixes (or even security bugfixes only), and that means branches.
boleary-gl 6y ago
GitLab Developer Evangelist here GitLab flow is much closer to trunk based development than git flow is. While no one "flow" works for everyone, I think that we are clearly in agreement that the simpler you can make your workflow, the better. The problem is some companies and organizations can't get all the way to trunk-based development based on their own regulatory needs or the type of software they are producing. That's why we think GitLab flow is a great way to balance both - in fact in the other linked blog post [1] we mention that GitLab flow should allow for CD from either branches or tags. From the main branch would then basically be the same as trunk based development, yes? [1] https://about.gitlab.com/blog/2016/07/27/the-11-rules-of-gitlab-flow/ https://about.gitlab.com/blog/2016/07/27/the-11-rules-of-git...

WWLink 6y ago

Between monoliths, this discussion, and other complaining about git I see around here, I wonder just how many of you are using subversion lol.

sidlls 6y ago
git's got some great features for very basic development workflows and the fact that it's distributed is undeniably a significant advantage. What amuses me, though, is all the ceremony and patterns in the use of git that restrict its use in ways that are sort of pale reflections of subversion, P4 and similar version control systems.
- WWLink 6y ago
  I like the distributed nature of git, the ability to make local commits, jump airgaps with bare repos, submodules, shallow clones, all kinds of silly things I suppose. I won't lie, I don't have a ton of experience with subversion, but whenever I've used it, it felt incredibly limiting.

servilio 6y ago

There is a need for simplified workflows, but this sounds and looks like an exercise in brand marketing more than a good analysis on how to offer a better Git workflows. > Git flow forces developers to use the develop branch rather than the master. Because most tools default to using the master, there’s a significant amount of branch switching involved. I'd like to see this fleshed out, since whatever branch naming convention or roles you use, you will be switching the same amount. > Another frustrating aspect is hotfix and release branches, which are overkill for most organizations and completely unnecessary in companies practicing continuous delivery. Yes and no. If you don't separate master from develop, hotfix branches just work like feature branches. But if you need them separated, then... > Bug fixes/hot fix patches are cherry-picked from master Avoid doing this, use daggy fixes[1], and it will make it breeze to check that a fix was actually merged and where[2]. And if you do cherry pick, at least use "-x". [1] https://wiki.monotone.ca/DaggyFixes https://wiki.monotone.ca/DaggyFixes [2] git branch --contains <commit>

ramenmeal 6y ago

I'm not a fan of merging master -> production for deployments. This means that what you tested in master may not be the same artifact that is deployed to prod. You're relying on people to correctly handle merge issues in git. This can become an issue if you have some complex hotfixes that have to happen. edit: I'd rather trunk based w/ tagging commits for releases.

donmcronald 6y ago
Yeah. I wonder if that merge to production rebuilds artifacts. That seems nasty.

dastx 6y ago

I don't quite understand why people don't keep it simple. Use short lived branches, and merge to master. Need to do a release? Master is your release. Tag the release when it's ready. Need to make a hot fix onto the current deployed version? Create a release branch from the tag, and then create a new tag and merge back to master. This combined with semver gets you far. I've yet to find any downsides with this approach.

AlphaSite 6y ago
Try doing that with a long lived product, where people don’t upgrade. You need to be able to backport fixes for that customer who pays your bills, but is 6 versions behind.
- cfstras 6y ago
  This is an entirely different problem - your customer doesn’t install releases, but they do install fixes? What is the reason for that?
  - kingosticks 6y ago
    Our customers don't want to spend vast amounts of time qualifying an entire new release when they can accept an isolated fix instead and do more focused testing. They might need the fix for some critical part of their product. If I was them I'd do the same - if the rest ain't broke, why risk fixing it?
    - cfstras 6y ago
      If the qualifying process is long and expensive, doing a one-off fix does seem more logical. This is assuming you can be sure the fix really is isolated. I do feel like a lot of companies over-exaggerate the need for multiple supported releases.
  - Cthulhu_ 6y ago
    Risk mitigation and investment; my employer's software does critical mobile network infrastructure, if they have an outage it affects millions of people. So, if our customers upgrade the software, they want to do their due diligence in their particular use case (it's a flexible system). That said though, software should be built to allow for fast and painless upgrades. Backwards compatibility and many use cases should be tested automatically and constantly. But, it's a big investment to have software like that, and you need to resist a lot of younger, eager developers that want to e.g. introduce a new language or make sweeping changes.

renewiltord 6y ago

Gonna be honest with y'all. You don't need a git workflow. Seriously, YAGNI. Deploy every `master`, no other restrictions. Git workflows are over-engineering.

AlphaSite 6y ago
That works if you have a deploy step. There’s a world beyond SAAS. A very lucrative one.
- renewiltord 6y ago
  Oh that's entirely fair. I was 100% thinking SaaS because of the website we're on, but if you do have to maintain multiple versions for whatever reason, you're going to need a complex flow with multiple trunks.
  - kingosticks 6y ago
    I don't see how SaaS is immune to this. You could easily find yourself with a big customer that effectively wants their own deployment and doesn't want updates (new bugs / big changes) but still demands occasional fixes/features that you often want to also merge into the main deployment.
    - renewiltord 6y ago
      It's not immune since few things in life have a measure zero or measure one probability. It is unlikely, though, imho.
    - steve_taylor 6y ago
      The key is to avoid having customers so big you can’t afford to lose them.

dragonwriter 6y ago

What a clickbaity title; there's no substantial discussion of Git Flow at all; the paragraph they actually spend discussing two minor issues sounds like it was written by someone who has never done serious work in Git Flow. Should be titled “The sales pitch for GitLab Flow”.

danw1979 6y ago

> Git flow forces developers to use the develop branch rather than the master. No it doesn’t. > Another frustrating aspect is hotfix and release branches I beg to differ. I know what would be frustrating though: > GitLab Flow is a way to make the relationship between the code and the issue tracker more transparent. Each change to the codebase starts with an issue in the issue tracking system. ... tying my repo to one particular git hosting platform.

hellofunk 6y ago

Trunk-based development FTW!

tupac_speedrap 6y ago

How is git flow complicated? I feel like some developers are doing shonky stuff with git branching and then blaming it on the branching strategy. If you used a system with less use of branches you'd just end up with dodgy code in master instead.

0x00101010 6y ago

man gitworkflows

alkonaut 6y ago

I immediately spot one huge issue with this > The production branch is essentially a monolith – a single long-running production release It assumes that only one version is deployed at a time, so you can't really service version1.0 after you shipped version2.0. Having multiple independent maintenance branches for production is critical for any branch pattern that should apply to both web software (normally single deployed version) and e.g. Desktop (normally multiple deployed versions). Th

somewhereoutth 6y ago

I think this sort of thing might become much more tractable if it were possible to visualize a git repo as it actually is - i.e. a directed graph of commits (occasionally with two parents - a merge commit), with moving labels (branch names) and fixed labels (tag names). Like when you buy a small shrub from the garden centre and it has a label attached to it somewhere. Pushes and pulls can then be visualized as two such shrubs reconciling themselves.

nicky0 6y ago
Interesting analogy, but as a gardener, I've never encountered the concept of a shrub reconciling itself so I have no idea what this visualization reveals!
- somewhereoutth 6y ago
  Imagine a shrub made of shrub A and shrub B. Parts of the shrub (from the root) are from both, parts are from A only, and parts are from B only. Imagine also the 2 sets of labels from A and B. It would become clear how the push/pull is updating its target shrub, and indeed if and what bits of the 2 shrubs (or their labels) conflict.

polymeris 6y ago

On the topic of Git Flow and simpler & faster alternatives, last month I published a short blog post about my experience learning those alternatives exist at CircleCI[1]. The most important learning for me was that things like Git Flow aren't free: they slow you down and make developers feel more detached and less responsible for the code that's running in prod. [1] https://circleci.com/blog/you-are-what-you-git-how-your-vcs-branching-model-affects-your-delivery-cadence/ https://circleci.com/blog/you-are-what-you-git-how-your-vcs-...

rob74 6y ago

Interesting tidbit: according to the "SEO-friendly" URL, the title should actually be "what-is-gitlab-flow" - I wonder if that was also the original title of the article, before it was changed into something more "clickbaity"?

thisisastopsign 6y ago

Sometimes I feel there should be a survey for Git methods and people vote on it. Repeat annually. Eventually we'll settle the debate

steve_taylor 6y ago

This is idiotic. Different situations call for different workflows. Working in a corporate environment with planned, infrequent releases? Use Git Flow. Doing continuous delivery instead? Use the feature branch workflow. This smells like GitLab trying to increase its ownership of the ecosystem.

king_magic 6y ago

I've literally never had a problem with Git Flow, nor have any developers I've worked with. It's fine.

malinens 6y ago

the problem is that gitlab works very bad with other git flows and they are ignoring issues about them so they force their own flow sadly... I still enjoy working with gitlab but this annoys me very much

somewhereoutth 6y ago

I feel a whole lot of problems would just go away if merge was abandoned. Thus every 'merge' would require a rebase (and subsequent deletion of the merged in branch), and branches stay as branches. For example it then becomes obvious and inevitable that hotfixes must be on an independent maintenance branch (cherry picked in/out of the master if appropriate). There is no longer the proliferation of merged in feature branches - only features currently worked on (and yet to be rebased) would have a branch. There is no concept of release vs master vs dev as it is not possible to merge one into the other. Push/pull is fast forward or force rebase. Easy enough to write a wrapper around git to do this - I am tempted.

jjuel 6y ago

Am I missing something or is this pretty much Gitflow with develop being named master and master named production? Maybe I don't fully understand Gitflow or we are using it like Gitlab Flow already with different names.

sane_Doyle 6y ago

when I thought about the way things have been recently, i owe my thanks to God for letting me find this amazing personality, i mailed Mrs Deja Ellie roughly 2 months now, I was actually very uncertain about investing, very scared because i was also low on cash. I gave it my all, my first investment of $2,000 two weeks ago brought me $ 29,230 last week, and what intrigues me the most is the way him handles he partners, i recommend him too to my friend jeff, after trading with her, his testimonies have let me come here to attest for her. We are happy to meet a professional in you. I am proud to recommend her to any person who has a passion for trading, meet a good mentor and get good fortunes. Contact this veteran trader Dejaellie@gmail. Com

einpoklum 6y ago

My problem with this suggestion is, that I tend to do history rewrites on the development branch, if I realize I've fucked something up; but I don't do that on master. So on master, broken things get fixed with a new commit; on development - sometimes, sometimes they get fixed retroactively. That means that you can safely "git pull" the master branch, always, into the future, but if you try to pull the development branch, you may well fail.