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?
11 comments
So this was something that a former boss/colleague and I kinda worked on for a few months at a prior company to help architects collaborate on global development standards.
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.
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.
There's no easy way to explain why Git is powerful.
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.
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.
Contrarily to what devs may think git is a fairly complicated and powerful system for steep learning curve, especially for your average Joe.
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.
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.
The mental overhead and complexity is simply not worth the investment. Geeks are already killing themselves for fun and profit with similar tools, geeks understand the underlying logic, know where to find info, etc. Non-geeks can't fathom why would anyone go through all this. Usually there is no satisfactory answer other than: it's pretty cool, you can solve ${crazy corner case}, look you can ${enter 5 commands with 6 flags each}.
The workflow and needs are completely different. The final deliverable of most non-dev groups rarely need to be able to jump back to a prior commit. You don't read a sentence in a legal document, and say, "That doesn't quite sound right, let me go git bisect to see where we broke the wording...", you just fix it.
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.
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.
The UI itself would have to make it clear what is happening. So clear that it can be used without training. Is this even possible to achieve? maybe yes. I've seen visual representations of branch and re-base that make it clear what is going on, but they were teaching tools, not the actual tool itself.
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 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.
Interesting question. I would say that collaborative editing of documents with changelog kind of captures that. For e.g Google Docs.
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?
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?
Yeah, fair point! I think adaptations can be made.
So I'm not a dev, but I've worked on product for a while. Bridging dev workflow and 'rest of business' workflow shows vast inefficiency gaps all over the place for the latter. I feel the trail of decision-making goes missing at the moment too.
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.
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.
[deleted]
The concept of tracking changes, branches, history & blame are pretty universal across different domains and should apply well.
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.
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.
Lots of people use Jira for non programming related things. One of the guys who works at Jira used it to assign tasks to the family for preparation of thanksgiving dinner :)
haha nice!
Using a git GUI is a less 'technical' option, but no matter who the target audience, there'll be some learning involved.
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.
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.
Without have the ability to merge two files that have started from the version and then diverged, git loses a lot of its usefulness, IMO. Unfortunately it's not trivial to merge the type of files that other professions use (eg: images for marketers or drawings for architects or even standard .doc word files). Not to say that conceptually it shouldn't be possible to merge the files, but the tech isn't there.