I think git was written to be distributed, hence merge being a front-and-center feature, but it is used as with a centralized repo (github/gitlab). This leads

I think git was written to be distributed, hence merge being a front-and-center feature, but it is used as with a centralized repo (github/gitlab). This leads to the UX that was initially planned becoming unwieldy. I think most organizations default to no-merge, rebase-and-commit-only mode, with master acting as the central branch to push to. Hence what git needs to improve it's UX to a newcomer is to help define a repository to be in a "no-merge", and then help translate user's following actions: git init <make changes> git commitchanges <this lists current changes, and tracked, untracked files, and asks which are to be commited, and makes the commit> git push <pushed changes to origin .. automatically rebases, and prompts the user for any conflicts> git pull <pulls changes, automatically rebases, and prompts for any conflicts> I'm convinced the entire workflow related to merges, and non-centralized features are what cause UX confusion for a new user.