In regards to the subject I think it is also important for the developers to understand and agree upon what the mainline (master/main/etc.) branch represents. F

In regards to the subject I think it is also important for the developers to understand and agree upon what the mainline (master/main/etc.) branch represents. For me it should contain only commits/changes which result in the new HEAD properly working and having a bug fixed and/or feature added. So the feature/bug/etc. branches can contain multiple commits which are helpful for the developer(s) that's working on it but it all should be squashed into a single one during merging into master. In short the history noise in master should be kept in check and reduced as much as possible which makes e.g. bisect easier as we don't take into account pointless commits and the history is cleaner. Problem is many think "more is better" and they end up with branches that are much more complicated to work with and reason about.