thanks a lot for taking your time and provide such detailed answer. I understand that there is a bunch of ways of doing things, and it is incredibly hard to have consensus over how to adapt the team workflow to the tools available.
I have had years of experience using Git with a rather large number of teams, and even though I purposely try to spend a long time at the beginning of a project defining the way we are going to collaborate (which others, normally a majority, think is too long), I notice that the time invested doing that really pays off over time, not only because we end up speaking the same language over the collaborative tools, but also because it hugely saves developing/testing/shipping time.
One day I heard (or read) something and I have never forgotten it, and even use the following quote in the Git workshops that I've held for teams new to the tool: "the Git history is part of the code, and it has to be treated as such". For example: just as you would reject a pull request with buggy code, a pull request with an amazing piece of documented and tested code might (and should IMHO) be rejected if it has superfluous commits or dubious commit messages, as this is something that the developers can fix themselves. This, among other things, might or might not be enforced by each team lead, depending on the maturity of the project.
Thanks a lot for sharing your experience!
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.