After your stuff works again, you do the rebase again and repeat this until there is nothing to fix, and then you make the pull request and let others review and then approve it. I can not see how this is a bad thing.
Then you realize is 4am and all of you are still on the office because two guys on their bubble made architectural decisions that impacted each other because they forgot to rebase frequently and now all of you need to code a third set of classes to handle the communication between those two subsystems.
No thanks I don't want to return to those nightmares.
Nothing is because git or branching, those are just tools what I like about not branching is that it doesn't requiere for the developer to be systematic and remember to do this and that.
I think this is more of a band aid approach which will eventually lead to further problems. If the issue is communication then you should fix that instead. Committing directly to development doesn't mean you resolve the issue of two individuals who decided to implement their own architecture. It just means if you weren't communicating then you get to see it sooner when you pull their recent commits but the issue still exists. It's just now it's been committed to the main dev branch.
CI is not a fix for bad planning and bad code. Fix the communication and planning and you end up with surprisingly good results. CI exists to help with quality, but the quality must start from the planning. CI does not help with maintainability and performance. Maintainability and performance directly affects to upkeep costs of the project.
I think you need to read a book called The Clean Coder. And The Phoenix Project while you're at it.
"and you fix it when is still a minor issue instead of a fully developed feature with, in the worst case, several days of work on it."
This again is a communication issue. Poor architectural design or not following implementation guidelines will not be resolved by checking in directly to a dev branch vs having a feature branch. It actually results in forced roll backs because things are being directly checked in to the same branch as everyone else. Just because they checked in code directly into the dev branch does not mean they didn't implement something incorrectly and didn't spend several days doing it.
Proper use of PRs for code reviews and communicating implementation with the team will help alleviate this issue.
There are different projects with different people and different needs. For my research project, where most of developers are non-professionals and do not follow all the rules (and cannot be forced), we use only single branch. It may sound crazy and really counter-intuitive, but it works best. People commit small and often, mistakes and bad code get quickly noticed. Everything is exposed to others and not hiding in their own branches. We don’t even have resources to do much code reviews. But main branch is heavily tested and we use CI. Now, all the features are in the maim branch and work together. Earlier (with cvs, svn and git) we ended up having dozens of branches living on their own since many people never cared pushing them to master. Or if they did, they ended up into integration hell - while sorting the merge problems somebody else pushed his 3 months work to master. Yes, we have a communication problem since the project is very loose. Now, we have always a working version on single remote branch (except occasional hickups between pushes and finished tests). Branching works well only when it is tightly coordinated. Of course, people still can have local branches.
Our “project” is quite special, what I want to say that not all projects are the same.
I think just because some are non-professionals (I assume they want to someday be one) it doesn't constitute bad practices. I think it's important to teach good practices so that they can use good practices moving forward. I also disagree that branching only works when things are tightly coordinated. I think when everyone is on the same branch coordination becomes even more important because you are on the same branch. Again working on the same branch will not prevent someone from pushing in 3 months worth of work.
You are right, it does not prevent. But most people do follow the commit small and often principle. The important thing is that code gets as early visibility as possible and it is not hiding anywhere. In a loose and distributed team, the early pushes serve as an important way of communication - hey, my name is N.N. and I am working on this feature. Often, others step in and propose a better way to do it. In separate feature branch, it often happened that a guy worked months on conflicting/duplicate or badly implemented feature. Then senior developers noticed the problem too late. Then we were left with 2 bad options, accept bad merge to main or loose months of work. In both case, we have at least one angry and frustrated developer... Although we try to force people (esp. the newbies) to communicate their plans in Jira before they do single line of code. Another major problem was that earlier certain branches started to live their own lives, causing serious fragmentation of the code base.
I understand the importance of code visibility and this can easily be done with feature branches via a pull request that does not get completed until code is reviewed and accepted. Direct commits and push to development does not fix issues of poorly implemented code. A developer can easily lose months of work because they committed to their local development branch that tracks origin and then push all their work once. The issue here is that you now are faced with an issue where that code is now in development and you have no chance to deny or approve it. This results in higher need to roll back commits on your development branch as opposed to only accepting code that meets requirements.
You have to prevent people from committing to master willy-nilly. Either make master a protected branch and require the tech lead to approve any merges, or have an automated regression test that runs before merging to master. At least make sure it compiles, or runs even a small "smoke test" (for non-compiled languages)
If a problem comes up, the person who caused the problem has to fix it, and it hasn't polluted the working master. The simplicity of that is probably too much for some people.
Then you have a crappy team, somebody failed to communicate how to work on the team or something else; definitively flesh based problem rather than software tooling problem
I think something to consider for all the nay-sayers... The author sounds like he has working experience on teams making branches and on teams without branches. He also claims that having a workflow that doesn't involve branching has aided in communication and healthy coding practices. Most of the people arguing against what he said seem to be in the realm of theory. But he is actually letting you know what his practical work experience has been. There is a difference in theory and actual experience. The author isn't theoretically saying he thinks this works better, he is saying he has literally experienced it working better. Git and branching are tools that you and your team can use as you see fit. If you don't want to use the same tools the way he is suggesting that is fine, but why are people trying so hard to convince him he is wrong? He already knows whether or not his teams workflow improved by making the changes he told you about.
Another way to put this is avoiding feature branches enables a team to achieve better continuous integration. Its related to continuous delivery and continuous deployment but those are downstream benefits to achieving better continuous integration.
A team can use feature branches and still achieve a high level of continuous integration, but it requires more discipline.
Reading this discussion, I think I have concluded that there are a lot of pain points for a team to encounter when switching from feature branches to trunk based development. However, I think I would argue that those pain points already exist and just aren't as apparent when using feature branches.
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.
Then you realize is 4am and all of you are still on the office because two guys on their bubble made architectural decisions that impacted each other because they forgot to rebase frequently and now all of you need to code a third set of classes to handle the communication between those two subsystems.
No thanks I don't want to return to those nightmares.
Sounds a lot like there is a problem in communication and planning. This is not because of git or branching.
Nothing is because git or branching, those are just tools what I like about not branching is that it doesn't requiere for the developer to be systematic and remember to do this and that.
If the developer isn't going to be systematic, how well do you think the product is going to work?
Well enough if you have a well configured CI server and QA processes.
I think this is more of a band aid approach which will eventually lead to further problems. If the issue is communication then you should fix that instead. Committing directly to development doesn't mean you resolve the issue of two individuals who decided to implement their own architecture. It just means if you weren't communicating then you get to see it sooner when you pull their recent commits but the issue still exists. It's just now it's been committed to the main dev branch.
and you fix it when is still a minor issue instead of a fully developed feature with, in the worst case, several days of work on it.
Communication problem are unavoidable or so says my experience.
CI is not a fix for bad planning and bad code. Fix the communication and planning and you end up with surprisingly good results. CI exists to help with quality, but the quality must start from the planning. CI does not help with maintainability and performance. Maintainability and performance directly affects to upkeep costs of the project.
I think you need to read a book called The Clean Coder. And The Phoenix Project while you're at it.
"and you fix it when is still a minor issue instead of a fully developed feature with, in the worst case, several days of work on it."
This again is a communication issue. Poor architectural design or not following implementation guidelines will not be resolved by checking in directly to a dev branch vs having a feature branch. It actually results in forced roll backs because things are being directly checked in to the same branch as everyone else. Just because they checked in code directly into the dev branch does not mean they didn't implement something incorrectly and didn't spend several days doing it.
Proper use of PRs for code reviews and communicating implementation with the team will help alleviate this issue.
There are different projects with different people and different needs. For my research project, where most of developers are non-professionals and do not follow all the rules (and cannot be forced), we use only single branch. It may sound crazy and really counter-intuitive, but it works best. People commit small and often, mistakes and bad code get quickly noticed. Everything is exposed to others and not hiding in their own branches. We don’t even have resources to do much code reviews. But main branch is heavily tested and we use CI. Now, all the features are in the maim branch and work together. Earlier (with cvs, svn and git) we ended up having dozens of branches living on their own since many people never cared pushing them to master. Or if they did, they ended up into integration hell - while sorting the merge problems somebody else pushed his 3 months work to master. Yes, we have a communication problem since the project is very loose. Now, we have always a working version on single remote branch (except occasional hickups between pushes and finished tests). Branching works well only when it is tightly coordinated. Of course, people still can have local branches.
Our “project” is quite special, what I want to say that not all projects are the same.
I think just because some are non-professionals (I assume they want to someday be one) it doesn't constitute bad practices. I think it's important to teach good practices so that they can use good practices moving forward. I also disagree that branching only works when things are tightly coordinated. I think when everyone is on the same branch coordination becomes even more important because you are on the same branch. Again working on the same branch will not prevent someone from pushing in 3 months worth of work.
You are right, it does not prevent. But most people do follow the commit small and often principle. The important thing is that code gets as early visibility as possible and it is not hiding anywhere. In a loose and distributed team, the early pushes serve as an important way of communication - hey, my name is N.N. and I am working on this feature. Often, others step in and propose a better way to do it. In separate feature branch, it often happened that a guy worked months on conflicting/duplicate or badly implemented feature. Then senior developers noticed the problem too late. Then we were left with 2 bad options, accept bad merge to main or loose months of work. In both case, we have at least one angry and frustrated developer... Although we try to force people (esp. the newbies) to communicate their plans in Jira before they do single line of code. Another major problem was that earlier certain branches started to live their own lives, causing serious fragmentation of the code base.
I understand the importance of code visibility and this can easily be done with feature branches via a pull request that does not get completed until code is reviewed and accepted. Direct commits and push to development does not fix issues of poorly implemented code. A developer can easily lose months of work because they committed to their local development branch that tracks origin and then push all their work once. The issue here is that you now are faced with an issue where that code is now in development and you have no chance to deny or approve it. This results in higher need to roll back commits on your development branch as opposed to only accepting code that meets requirements.
You have to prevent people from committing to master willy-nilly. Either make master a protected branch and require the tech lead to approve any merges, or have an automated regression test that runs before merging to master. At least make sure it compiles, or runs even a small "smoke test" (for non-compiled languages)
If a problem comes up, the person who caused the problem has to fix it, and it hasn't polluted the working master. The simplicity of that is probably too much for some people.
Then you have a crappy team, somebody failed to communicate how to work on the team or something else; definitively flesh based problem rather than software tooling problem
Same problem as you described in the original post and same solution: communication.
I think something to consider for all the nay-sayers... The author sounds like he has working experience on teams making branches and on teams without branches. He also claims that having a workflow that doesn't involve branching has aided in communication and healthy coding practices. Most of the people arguing against what he said seem to be in the realm of theory. But he is actually letting you know what his practical work experience has been. There is a difference in theory and actual experience. The author isn't theoretically saying he thinks this works better, he is saying he has literally experienced it working better. Git and branching are tools that you and your team can use as you see fit. If you don't want to use the same tools the way he is suggesting that is fine, but why are people trying so hard to convince him he is wrong? He already knows whether or not his teams workflow improved by making the changes he told you about.
Another way to put this is avoiding feature branches enables a team to achieve better continuous integration. Its related to continuous delivery and continuous deployment but those are downstream benefits to achieving better continuous integration.
A team can use feature branches and still achieve a high level of continuous integration, but it requires more discipline.
Reading this discussion, I think I have concluded that there are a lot of pain points for a team to encounter when switching from feature branches to trunk based development. However, I think I would argue that those pain points already exist and just aren't as apparent when using feature branches.