| this does not sound like a problem with git, but a problem with culture and developer practices, and bad workflows. in my 8 years of using git as a primary tool for vc, i have not once run into confusion on how to switch branches, create branches, prune branches, sync remotes with locals, and other common workflows. does that mean i have only dealt with simple merges or haven't fucked something up bc i did not understand something and made things way harder than necessary (merging/replaying 50 commits vs squash rebase workflows, for example). and no, you don't need to 'fetch' before you switch, fetching is only relevant if you're needing to bring in remotes or you're preparing for merges etc. someone committing bunk to a main branch or something considered a production branch is not a git problem -- that's just bad development practices, and the onus is on the developer there to not do that and to understand why it is bad. as for your other complaints, these are much more easily managed when the developers are not just arbitrarily commiting to branches without any strategic thought, but to point out, a lot of those problems are solved via working with commit hashes and branching, assuming you have already plugged the leak that is committing breaking changes to a main branch. why are breaking changes that are mega changes even making it through to main? |