Why is there no Git workflow for non-devs?
it seems like a lot of the principles could be transposed (in some way) to how marketing, ops, legal, etc. work - why isn't there a product that does this?
There was a base set of standards which evolved over time, and regions whose standards would extend that base in different ways.
We actually got to the point where a small team of architects would write these standards in Markdown, use GitHub Desktop to manage their branching/PR-ing/reviewing workflows, and then tag releases. Then Jenkins would pick up the tag and process the Markdown with Pandoc to produce DOCX and PDF documents that adhered to our corporate style guide.
IIRC there were a few reasons why it never got widespread adoption. One thing that sticks is that even after we taught people how to use git and they ran with it while pushing out updates, without the daily reinforcement (e.g. like what software workflows require) the knowledge just didn't seem to stick.
The whole thing was really slick; in retrospect I wish we would have given a small talk about it and open sourced the workflow as an example. If nothing else, it reinforced my belief that with _just a little more polish_ force-multiplying dev tools could save people in other industries a lot of time/effort.
It's hard to conceptualise things like branching for non-dev's (or beginners). Even the name "branch" implies similarities to a tree branch, but branches from a tree don't merge back into the tree so the analogy kind of falls apart.
One of the biggest advantages of git is the diff and merge algorithms, merging in changes from multiple different sources is relatively easy. This is only really possible with "text" files, compiled documents like word and excel are much hard to negotiate merging.
Basically, if you can make the concepts of Git easy to understand, make merging work with other files, then it can be applied everywhere.
I’m by no means a full time programmer, but I do program few times a week and sometimes I get lost/break state in git. Now imagine that happens in you typical company where people have problems with basic computer uses sometime.
Once you throw out the need to step back through a commit history, then all you really need is tracked changes, and that is well supported in both Word and Google Docs.
One 'non-code' example: document editors (e.g., Microsoft Word) have a version of this in tracking of changes (with reversion options).
More practically, I don't think there are many domains where the granularity of control over 'versions' is as useful as with digital files.
The developer of the UI may be biased as they already have the hard-won knowledge of branch, merge, multiple remotes, pull/push, etc. The biased developer will confuse good looks UI with intuitiveness. Or they will go down the wrong path and create a UI that is very practical for people who already have hard-won knowledge, but no so much for normal people.
The biased developer will think the answer to these problems is "training" instead of making the UI naturally visually intuitive.
The checkout, edit, diff, merge, review, build, release workflow might be too onerous for other teams.
Curious to know, why do you ask this question?
This also peaked my curiosity: https://a16z.com/2020/01/09/the-developers-way/ and resonated...a lot haha.
+ something I'd love to see productised/productise myself.
The smallest unit of change in Git is a line (correct me on that), which doesn't work well with something as simple as a text document. E.g. collaboratively working on a ReadMe file on GitHub is quite cumbersome compared to Google Docs or MS Word.
Git is no more than a versioned file repo for CAD or vector files.
It's a reasonable question, though.