They aren't limitless, it is one of the three I've mentioned and I was asking so I know what you think the solution is.
I never said people are perfect but ignoring pipeline failures and delaying fixes or integration is worse than fixing them immediately. A typo is easy to fix since the person that made the change can just make another change.
Sure, we can get to that. This article was just about identifying that feature branching isn't compatible with continuous integration.
I think it is important to note that the people that wrote the gitflow document don't recommend it and propose trunk development as a better practice. Either they are saying gitflow was a misstep or trunk development isn't the same as what was before both.
They aren't limitless, it is one of the three I've mentioned and I was asking so I know what you think the solution is.
The solution is to stop thinking there are only three options of deployment, in order to justify dismissing gitflow. I can deploy my feature branch just fine, infact I can deploy each seperate pull request for a feature branch and show the result to my team members or clients and it wont interfere at all with other branches or pull requests that are deployed. But most importantly I can run integration tests on each pull request seperately, without them interfering.
I think it is important to note that the people that wrote the gitflow document don't recommend it and propose trunk development as a better practice.
I agree it's sad that they dismissed gitflow and mention a replacement, without explaining how it is actually better. I don't really care what anyone says if they dont offer a better solution and nobody has explained to me yet how trunk development is better than gitflow. If something better comes along that doesn't block the dev process and the release cycle, I'd be happy to switch.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
They aren't limitless, it is one of the three I've mentioned and I was asking so I know what you think the solution is.
I never said people are perfect but ignoring pipeline failures and delaying fixes or integration is worse than fixing them immediately. A typo is easy to fix since the person that made the change can just make another change.
Sure, we can get to that. This article was just about identifying that feature branching isn't compatible with continuous integration.
I think it is important to note that the people that wrote the gitflow document don't recommend it and propose trunk development as a better practice. Either they are saying gitflow was a misstep or trunk development isn't the same as what was before both.
The solution is to stop thinking there are only three options of deployment, in order to justify dismissing gitflow. I can deploy my feature branch just fine, infact I can deploy each seperate pull request for a feature branch and show the result to my team members or clients and it wont interfere at all with other branches or pull requests that are deployed. But most importantly I can run integration tests on each pull request seperately, without them interfering.
I agree it's sad that they dismissed gitflow and mention a replacement, without explaining how it is actually better. I don't really care what anyone says if they dont offer a better solution and nobody has explained to me yet how trunk development is better than gitflow. If something better comes along that doesn't block the dev process and the release cycle, I'd be happy to switch.