It's late and I'm feeling blunt. It's hard to take an article seriously when it talks about Git Flow being too complicated - it is not complicated on its face, or on any other part. It makes a ton...
It's late and I'm feeling blunt.
It's hard to take an article seriously when it talks about Git Flow being too complicated - it is not complicated on its face, or on any other part. It makes a ton of sense and is really easy and intuitive; it took me 15 minutes to explain it to our non-technical client liaison, and only 30 minutes to explain it to our junior devs. Since the alternative is tagging, it's important to note that tags are inherently a bit less understandable, in general, than branches; you need to know how branches work to use git, but you don't need to know how tags work.
It's also hard to take it seriously when it takes one of the actual strengths of Git Flow (disentangling / wrangling commits for continuous integration) and tries to frame it as a drawback somehow. Commits to master trigger automatic deployment. It actually doesn't get much easier than that, and I'm perplexed as to how someone can actually bring this up as a point of contention for Git Flow. Well, I guess it could get a bit more complicated; you could have commits to develop automatically deploy to your stage environment. That's not really that complicated.
In my experience the people who are against Git Flow tend to cite the desire to have a "healthy commit tree". I've never understood why some people have their heads so far up their own asses about having a nice looking tree of commits. The graphs that they are looking for are typically what you would describe as "a lie". Your git commit history should be the history of the work that you've actually done. If you spend your time making the connecting points of the graph that shows how work was integrated look pretty, then that is a waste of time. It's better that it actually shows the things that happened, so that if you need to look at why something ended up in a particular state, you can identify it.
I'm not saying that there is no utility in a clean looking tree, but far too many people spend far too much time sculpting their git log into something that it wasn't so that they foster this lie about how the development happened.
Git Flow, like almost every other branching model, has strengths and drawbacks. Saying "Stop recommending Git Flow" is as stupid as saying "stop recommending JavaScript". Sometimes that's actually the right tool for the job. This guy's inability to wend their way through a drawing because they prefer tags and rebasing doesn't mean that Git Flow is necessarily bad or wrong. I'm actually getting pretty sick of articles like this, where someone makes a proclamation about how everything should be based on their very limited understanding of one very small section of the industry.
Go ahead. Use Git Flow if you like it. It's not harmful; it can be beautiful when you implement it correctly. Note that there is a high likelihood that the model isn't right for your use case - it's not necessarily great for a single developer working on something on their own, or for a startup with 50 people trying to push out something new every day. But if you have a mid size tech company that works on a dozen different projects a year, it might be worthwhile to check it out!
I get what you're saying in your aside, since some of the articles submitted here definitely do seem to be somewhat hyperbolic/contrarian at times and designed to intentionally illicit...
I get what you're saying in your aside, since some of the articles submitted here definitely do seem to be somewhat hyperbolic/contrarian at times and designed to intentionally illicit controversy, which I am also not a fan of... but even so, your rant comes across as a very personal attack against the users submitting them, and is pretty mean-spirited, which is rather inappropriate here, IMO.
So, generally, <3 you, <3 your points of view. I agree with @reese here to some degree. On Tildes, and on other platforms, I have seen an increased number of articles from authors who are writing...
So, generally, <3 you, <3 your points of view.
I agree with @reese here to some degree. On Tildes, and on other platforms, I have seen an increased number of articles from authors who are writing things in a particular way to create controversy, which draws attention, which creates page views. This article is an excellent example of it; I'll allow that there are good points in the article, but generally it's a bad article. I would say that to the author's face if he were right in front of me. He should stop writing hit pieces that state things in terms of absolutes when there isn't an absolute answer to which branching strategy is the best (or really even which one is good, which is really a team by team basis sort of thing). In general, I think we should stop giving views or time to articles like this. I would say the same to the person who submitted the post (I guess I have: @SUD0). I am absolutely not saying this as an attack on the submitter, who is great, but instead as someone who generally wants to see fewer articles like this because I think these are actually detrimental; nobody who reads this is going to become a better programmer, which I think should be the desire for things that are linked to from here.
I would personally have stopped short of saying "Does baby need a bottle", but that's only because I can't see myself actually saying that. I think that the article itself is very juvenile, and is the sort of thing that an intermediate developer might write to try to sound important.
Just to be clear, I absolutely do agree with you (and @aphoenix) there. Sorry if I came across as trying to incite others to attack you, as that was genuinely not my intent. I perhaps got a bit...
But the article itself is baiting controversy.
Just to be clear, I absolutely do agree with you (and @aphoenix) there.
Sorry if I came across as trying to incite others to attack you, as that was genuinely not my intent. I perhaps got a bit triggered here myself and went overboard in my criticism of your choice of words... so, I'm sorry about that too. Perhaps I should have started this whole thing as a PM? Anyways, 💖🕊️
Good point. I'll keep this in the back of my head when deciding on whether I should post something here. I didn't have any ill motives for posting this. I thought it was interesting that this...
.... nobody who reads this is going to become a better programmer, which I think should be the desire for things that are linked to from here.
Good point. I'll keep this in the back of my head when deciding on whether I should post something here. I didn't have any ill motives for posting this. I thought it was interesting that this author had such a strong opinion against a branching strategy that I was taught in school. Wanted to hear what other people thought about it.
I think there's actually a place for discussion like that, and Tildes is actually a great way to set up for this sort of discussion, so I absolutely do not want to discourage you from posting. I...
I think there's actually a place for discussion like that, and Tildes is actually a great way to set up for this sort of discussion, so I absolutely do not want to discourage you from posting.
I think that just the context of "I thought it was interesting that this author had such a strong opinion against a branching strategy that I was taught in school. Wanted to hear what other people thought about it." sets up such an interesting post! But I got caught up in disliking the blog post itself, and we ended up in this meta-discussion about if articles like this should even exist instead of the actual interesting part which is branching strategies!
Turns out that the actual important part of "branching strategies" is just "have a branching strategy". That's about 90% of the work right there; set up a system whereby you can get working software. The important thing in all software development is to develop software, so all decisions should be made through the lens of "how does my team function and what sort of strategy will enable them to actually get code out the door?"
It's a great question, and one that has a lot of different ways to answer, and touches just about all aspects of actually writing software, and there's no "right answer". While I think that this article is waaaaay off base because there's lots of great things about Git Flow, I don't actually think that Git Flow is something everybody should consider, because that's just as wrong. Git Flow is good for some situations, and not good in others. The same is true in most of the debates raging online: docker is great for some situations and not good in others. AWS is great in some situations and not good in others. Vim is great in all situations. Monorepos are great in some situations and not good in others. This list could go on, and could apply to things like operating systems, IDEs, programming languages, general architectural choices, javascript libraries, game development platforms... in almost every case there's no "right" answer, there's just answers that are varying degrees of goodness depending on what you're trying to do.
I would love to write an article about the pros and cons of a lot of different things, but it would mostly be about the journey to understanding that "this thing I don't like" is actually valid and useful for a lot of people. That journey is part of becoming a "senior developer". The other part is knowing how to approach problems and being able to make the decision that Git Flow is worthwhile for your team or not. Blanket statements of how things should be are not the mark of a good senior developer; they're the mark of someone who, as I bluntly said last night, has their head up their own ass too far.
Even with the most charitable interpretation it still comes across as a personal attack against the authors, at the very least, but regardless of that, it's still incredibly condescending and mean...
Even with the most charitable interpretation it still comes across as a personal attack against the authors, at the very least, but regardless of that, it's still incredibly condescending and mean spirited IMO.
And the paradox of tolerance is about tolerating messages (like calls to genocide) that could potentially lead to the tolerant being destroyed, and tolerance with them. How does posting opinions on computer science topics that you don't agree with the conclusions of, hyperbolic/contrarian/controversial or not, have anything to do with that?
I understand you're frustrated seeing these sorts of submissions pop up over and over (so am I, TBH)... but I still don't think that warrants making it so personal and being so mean about it. Imagine if the author (or submitter) was physically right in front of you... would you have dared to say all that to their face? I suspect not, as that would be incredibly rude and might even result in a serious altercation, so why is saying it online suddenly okay?
Well... if the guy who wrote it himself feels like this is a drawback, then I guess I stand corrected, but I have found it very simple to integrate continuous delivery into our git flow. About 70%...
Well... if the guy who wrote it himself feels like this is a drawback, then I guess I stand corrected, but I have found it very simple to integrate continuous delivery into our git flow. About 70% of our work is custom web applications and about 30% is custom web sites (usually using WordPress), and we use a slightly modified Git Flow (we don't avoid fast-forwards).
Our CI / CD for applications looks like this:
commits to develop trigger a build to the dev environment
commits to any release branch trigger a build to the staging environment
commits to master trigger a build to the production environment
We use pipelines to manage those builds and deployments.
Our CI / CD for web sites looks like this:
commits to any release branch trigger a deployment to the staging environment if that exists
commits to master trigger a deployment to the production environment
My shop is a bitbucket / JIRA shop, and we deploy to AWS. It did not take a significant amount of time to get these pipelines working, and it saves us a ton of time, and it really works well with our branching model, especially since bitbucket has support for our branching conventions "out of the box" which is great (ie - you can't PR a feature branch into master, a junior dev can't merge release into master etc).
It's hard for me to believe that there are a significant number of development teams where "choice of branching model" is really the largest unaddressed source of potential quality or speed...
It's hard for me to believe that there are a significant number of development teams where "choice of branching model" is really the largest unaddressed source of potential quality or speed improvements. I've worked with a bunch of different branching models and source code control software over the years, and as long as the SCM doesn't actually lose things (hopefully no one else ever had to depend on VIsual SourceSnakes), it doesn't seem to make nearly as much difference as things like developers actually talking to one another.
I kind of touched on it in another comment here, but some developers lose sight of the fact that all these processes are just things that people put in place to enable themselves to write and...
I kind of touched on it in another comment here, but some developers lose sight of the fact that all these processes are just things that people put in place to enable themselves to write and release software. Some people get off in the weeds, and then they start to get really worried about the process, and ensuring that the process is beautiful. Processes don't have to be beautiful, they have to be unobtrusive.
Git Flow for example, is really unobtrusive if approached correctly; I use it to abstract away "how does code get deployed" from the other developers. For them, Git Flow looks like this:
I work off develop
I write features called feature/JIRAKEY-9/feature-name and I make pull requests
aphoenix talks to me extensively about my code and we revise until his head doesn't a-splode
it gets accepted
That's it. Branch of develop, do work. Make a merge request on your branch when it's done. It's the easiest way to do things for them.
We also use it to abstract away development from the client liaison team. They only have to watch for release branches, and then read the changelog to see what's going out the door. Perfect! For them Git Flow looks like this:
a whole bunch of coding bullshit is happening over there in those rooms
a release branch appears! It details all the things getting launched, and the stories that they relate to in a Changelog! It's on the staging site right now, and I can go look at it
It got merged, so in half an hour it will be on the live site!
For me as the technical lead, it's a great system - the people involved only need to look at the stuff that is relevant to them, and I don't have to try to explain tags to a non-technical person. Branches they get, but tags are not understandable at all.
It’s hard to buy into this article’s argument without contrasting a different approach. Sone people I know are using a subversion-ish trunk model which makes liberal use of rebasing.
It’s hard to buy into this article’s argument without contrasting a different approach.
Sone people I know are using a subversion-ish trunk model which makes liberal use of rebasing.
It's late and I'm feeling blunt.
It's hard to take an article seriously when it talks about Git Flow being too complicated - it is not complicated on its face, or on any other part. It makes a ton of sense and is really easy and intuitive; it took me 15 minutes to explain it to our non-technical client liaison, and only 30 minutes to explain it to our junior devs. Since the alternative is tagging, it's important to note that tags are inherently a bit less understandable, in general, than branches; you need to know how branches work to use git, but you don't need to know how tags work.
It's also hard to take it seriously when it takes one of the actual strengths of Git Flow (disentangling / wrangling commits for continuous integration) and tries to frame it as a drawback somehow. Commits to master trigger automatic deployment. It actually doesn't get much easier than that, and I'm perplexed as to how someone can actually bring this up as a point of contention for Git Flow. Well, I guess it could get a bit more complicated; you could have commits to develop automatically deploy to your stage environment. That's not really that complicated.
In my experience the people who are against Git Flow tend to cite the desire to have a "healthy commit tree". I've never understood why some people have their heads so far up their own asses about having a nice looking tree of commits. The graphs that they are looking for are typically what you would describe as "a lie". Your git commit history should be the history of the work that you've actually done. If you spend your time making the connecting points of the graph that shows how work was integrated look pretty, then that is a waste of time. It's better that it actually shows the things that happened, so that if you need to look at why something ended up in a particular state, you can identify it.
I'm not saying that there is no utility in a clean looking tree, but far too many people spend far too much time sculpting their git log into something that it wasn't so that they foster this lie about how the development happened.
Git Flow, like almost every other branching model, has strengths and drawbacks. Saying "Stop recommending Git Flow" is as stupid as saying "stop recommending JavaScript". Sometimes that's actually the right tool for the job. This guy's inability to wend their way through a drawing because they prefer tags and rebasing doesn't mean that Git Flow is necessarily bad or wrong. I'm actually getting pretty sick of articles like this, where someone makes a proclamation about how everything should be based on their very limited understanding of one very small section of the industry.
Go ahead. Use Git Flow if you like it. It's not harmful; it can be beautiful when you implement it correctly. Note that there is a high likelihood that the model isn't right for your use case - it's not necessarily great for a single developer working on something on their own, or for a startup with 50 people trying to push out something new every day. But if you have a mid size tech company that works on a dozen different projects a year, it might be worthwhile to check it out!
I get what you're saying in your aside, since some of the articles submitted here definitely do seem to be somewhat hyperbolic/contrarian at times and designed to intentionally illicit controversy, which I am also not a fan of... but even so, your rant comes across as a very personal attack against the users submitting them, and is pretty mean-spirited, which is rather inappropriate here, IMO.
So, generally, <3 you, <3 your points of view.
I agree with @reese here to some degree. On Tildes, and on other platforms, I have seen an increased number of articles from authors who are writing things in a particular way to create controversy, which draws attention, which creates page views. This article is an excellent example of it; I'll allow that there are good points in the article, but generally it's a bad article. I would say that to the author's face if he were right in front of me. He should stop writing hit pieces that state things in terms of absolutes when there isn't an absolute answer to which branching strategy is the best (or really even which one is good, which is really a team by team basis sort of thing). In general, I think we should stop giving views or time to articles like this. I would say the same to the person who submitted the post (I guess I have: @SUD0). I am absolutely not saying this as an attack on the submitter, who is great, but instead as someone who generally wants to see fewer articles like this because I think these are actually detrimental; nobody who reads this is going to become a better programmer, which I think should be the desire for things that are linked to from here.
I would personally have stopped short of saying "Does baby need a bottle", but that's only because I can't see myself actually saying that. I think that the article itself is very juvenile, and is the sort of thing that an intermediate developer might write to try to sound important.
Just to be clear, I absolutely do agree with you (and @aphoenix) there.
Sorry if I came across as trying to incite others to attack you, as that was genuinely not my intent. I perhaps got a bit triggered here myself and went overboard in my criticism of your choice of words... so, I'm sorry about that too. Perhaps I should have started this whole thing as a PM? Anyways, 💖🕊️
Good point. I'll keep this in the back of my head when deciding on whether I should post something here. I didn't have any ill motives for posting this. I thought it was interesting that this author had such a strong opinion against a branching strategy that I was taught in school. Wanted to hear what other people thought about it.
I think there's actually a place for discussion like that, and Tildes is actually a great way to set up for this sort of discussion, so I absolutely do not want to discourage you from posting.
I think that just the context of "I thought it was interesting that this author had such a strong opinion against a branching strategy that I was taught in school. Wanted to hear what other people thought about it." sets up such an interesting post! But I got caught up in disliking the blog post itself, and we ended up in this meta-discussion about if articles like this should even exist instead of the actual interesting part which is branching strategies!
Turns out that the actual important part of "branching strategies" is just "have a branching strategy". That's about 90% of the work right there; set up a system whereby you can get working software. The important thing in all software development is to develop software, so all decisions should be made through the lens of "how does my team function and what sort of strategy will enable them to actually get code out the door?"
It's a great question, and one that has a lot of different ways to answer, and touches just about all aspects of actually writing software, and there's no "right answer". While I think that this article is waaaaay off base because there's lots of great things about Git Flow, I don't actually think that Git Flow is something everybody should consider, because that's just as wrong. Git Flow is good for some situations, and not good in others. The same is true in most of the debates raging online: docker is great for some situations and not good in others. AWS is great in some situations and not good in others. Vim is great in all situations. Monorepos are great in some situations and not good in others. This list could go on, and could apply to things like operating systems, IDEs, programming languages, general architectural choices, javascript libraries, game development platforms... in almost every case there's no "right" answer, there's just answers that are varying degrees of goodness depending on what you're trying to do.
I would love to write an article about the pros and cons of a lot of different things, but it would mostly be about the journey to understanding that "this thing I don't like" is actually valid and useful for a lot of people. That journey is part of becoming a "senior developer". The other part is knowing how to approach problems and being able to make the decision that Git Flow is worthwhile for your team or not. Blanket statements of how things should be are not the mark of a good senior developer; they're the mark of someone who, as I bluntly said last night, has their head up their own ass too far.
Even with the most charitable interpretation it still comes across as a personal attack against the authors, at the very least, but regardless of that, it's still incredibly condescending and mean spirited IMO.
And the paradox of tolerance is about tolerating messages (like calls to genocide) that could potentially lead to the tolerant being destroyed, and tolerance with them. How does posting opinions on computer science topics that you don't agree with the conclusions of, hyperbolic/contrarian/controversial or not, have anything to do with that?
I understand you're frustrated seeing these sorts of submissions pop up over and over (so am I, TBH)... but I still don't think that warrants making it so personal and being so mean about it. Imagine if the author (or submitter) was physically right in front of you... would you have dared to say all that to their face? I suspect not, as that would be incredibly rude and might even result in a serious altercation, so why is saying it online suddenly okay?
Well... if the guy who wrote it himself feels like this is a drawback, then I guess I stand corrected, but I have found it very simple to integrate continuous delivery into our git flow. About 70% of our work is custom web applications and about 30% is custom web sites (usually using WordPress), and we use a slightly modified Git Flow (we don't avoid fast-forwards).
Our CI / CD for applications looks like this:
developtrigger a build to the dev environmentmastertrigger a build to the production environmentWe use pipelines to manage those builds and deployments.
Our CI / CD for web sites looks like this:
mastertrigger a deployment to the production environmentMy shop is a bitbucket / JIRA shop, and we deploy to AWS. It did not take a significant amount of time to get these pipelines working, and it saves us a ton of time, and it really works well with our branching model, especially since bitbucket has support for our branching conventions "out of the box" which is great (ie - you can't PR a
featurebranch intomaster, a junior dev can't mergereleaseintomasteretc).It's hard for me to believe that there are a significant number of development teams where "choice of branching model" is really the largest unaddressed source of potential quality or speed improvements. I've worked with a bunch of different branching models and source code control software over the years, and as long as the SCM doesn't actually lose things (hopefully no one else ever had to depend on VIsual SourceSnakes), it doesn't seem to make nearly as much difference as things like developers actually talking to one another.
I kind of touched on it in another comment here, but some developers lose sight of the fact that all these processes are just things that people put in place to enable themselves to write and release software. Some people get off in the weeds, and then they start to get really worried about the process, and ensuring that the process is beautiful. Processes don't have to be beautiful, they have to be unobtrusive.
Git Flow for example, is really unobtrusive if approached correctly; I use it to abstract away "how does code get deployed" from the other developers. For them, Git Flow looks like this:
feature/JIRAKEY-9/feature-nameand I make pull requestsThat's it. Branch of develop, do work. Make a merge request on your branch when it's done. It's the easiest way to do things for them.
We also use it to abstract away development from the client liaison team. They only have to watch for release branches, and then read the changelog to see what's going out the door. Perfect! For them Git Flow looks like this:
For me as the technical lead, it's a great system - the people involved only need to look at the stuff that is relevant to them, and I don't have to try to explain tags to a non-technical person. Branches they get, but tags are not understandable at all.
It’s hard to buy into this article’s argument without contrasting a different approach.
Sone people I know are using a subversion-ish trunk model which makes liberal use of rebasing.