It isn't a sales problem either. It's a tooling problem.
Git really ought to be treated as a low level tool that is called by a higher level tool that assembles content management workflows designed by developers that can be used by developers and non-developers alike.
Non-developers ought to be able to make 'commits' with git and pull requests without even realizing that git is the underlying tool.
Developers should just script their most common workflows and then use them 99% of the time.
Unfortunately the tooling that sits atop git is largely all shit and people have gotten it into their heads that one needs to have a deep understanding of git's quirks to be considered a 'serious' developer.
I agree with your premise, but don't understand your conclusion...
> Non-developers ought to be able to make 'commits' with git and pull requests without even realizing that git is the underlying tool.
Absolutely. By why 'ought'? What's stopping you?
Git has an API, lots of tools use it. There are commercial products that wrap git for designers and such. Many of my systems are GIT and Github enabled (Octokit), and the users are none the wiser.
> Developers should just script their most common workflows and then use them 99% of the time.
I am almost positive this already exists in many various forms online (on github in particular), for personal needs. I know a significant number of projects script checkins, builds, etc.
It breaks down, IMO, because of environmental constraints. You're trying to maintain alias sets across machines, on colleagues machines, or handle tricky merge issues per-project. At the end of the day the APIs breadth is required to handle corner cases, and familiarity with the breadth makes a lot of noise 'straightforward'.
I don't know of any decent tools. Something that would give an end user a nice UI to let them edit a markdown or JSON/YAML file and issue a pull request following a team defined workflow, for example? Or a WYSIWYG markdown editor that can issue pull requests following a team defined workflow at the click of a button?
>Git has an API
I noticed.
>I am almost positive this already exists in many various forms online
Most teams I've worked with don't have anything. One of the first things I do when I join a team is figure out their workflows (typically baked into people's heads) and get them down in a script.
>It breaks down, IMO, because of environmental constraints. You're trying to maintain alias sets across machines
A) git aliases are a poor substitute for a decent workflow program.
B) A lot of workflows integrate a lot of different things - e.g. by convention, branch names on new tickets often contain the JIRA ticket number followed by a slugified name. That means to properly script a workflow you need to make an API call to get a ticket number and slugify the name and use it to create the new branch.
> Git really ought to be treated as a low level tool that is called by a higher level tool
> Developers should just script their most common workflows and then use them 99% of the time.
FWIW, that is how git is organized: low-level "plumbing" commands for the content-addressable file system, and the high-level "porcelin" commands for a VCS. Moreover, most git commands have human and machine readable variants, to facilitate abstraction.
Git really ought to be treated as a low level tool that is called by a higher level tool that assembles content management workflows designed by developers that can be used by developers and non-developers alike.
Non-developers ought to be able to make 'commits' with git and pull requests without even realizing that git is the underlying tool.
Developers should just script their most common workflows and then use them 99% of the time.
Unfortunately the tooling that sits atop git is largely all shit and people have gotten it into their heads that one needs to have a deep understanding of git's quirks to be considered a 'serious' developer.