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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.