Jon is a self-taught programmer, started in video games but now does web development. He follows principles, argues for scientific software development, and does not like writing in the 3rd person.
Isolating features into different branches is a crucial practice for any serious developer
This is exactly opposite the latest findings of highly effective teams, there is a correlation of highly effective teams and trunk based development or branches with a lifespan of less than a day. See "Accelerate: Building and Scaling High Performing Technology Organizations", it bases its data off of statistics that I imagine any one of us will be hard pressed to argue against effectively.
The point is to get changes in as soon as possible, not features, but changes. I try to only work in branches when I need a merge-request reviewed (e.g. if I couldn't pair on the change). BTW low-overhead change-management process is another correlation of effectiveness. And if talk of correlations bore you I'll just say it's a lot more fun to develop without all those processes :)
(and thanks for sharing your article and viewpoint, it's by discussion we grow)
Hi, I’m Steffen. I create Embedded software for a living.
I always strive to improve the quality of my code by studying new methods, paradigms and technologies.
Hey, Jon! Well, currently, our team prefers to separate each specific feature into a separate branch, since multiple people work on different features at the same time.
That being said, when it comes to hotfixes or any crucial bugs that need immediate and quick attention we push those changes directly without creating a new branch for each problem.
Sure, my pleasure, that's why this is a great community. We share opinions and grow. :)
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.
This is exactly opposite the latest findings of highly effective teams, there is a correlation of highly effective teams and trunk based development or branches with a lifespan of less than a day. See "Accelerate: Building and Scaling High Performing Technology Organizations", it bases its data off of statistics that I imagine any one of us will be hard pressed to argue against effectively.
The point is to get changes in as soon as possible, not features, but changes. I try to only work in branches when I need a merge-request reviewed (e.g. if I couldn't pair on the change). BTW low-overhead change-management process is another correlation of effectiveness. And if talk of correlations bore you I'll just say it's a lot more fun to develop without all those processes :)
(and thanks for sharing your article and viewpoint, it's by discussion we grow)
I can relate to that from my(limited) experience. Together with CI, pushing to master as soon as possible has worked quite well.
Hey, Jon! Well, currently, our team prefers to separate each specific feature into a separate branch, since multiple people work on different features at the same time.
That being said, when it comes to hotfixes or any crucial bugs that need immediate and quick attention we push those changes directly without creating a new branch for each problem.
Sure, my pleasure, that's why this is a great community. We share opinions and grow. :)