It's easier to figure out the various workflows you need (most teams need very few - work on feature, sync code, commit/push/issue PR, release) and then scripting them.

I noticed that git errors on my team were almost eliminated when we started doing that - especially once I started adding sanity checks to the git workflows. It also allowed members of the team who previously struggled with git to contribute much more effectively - they'd be rebasing without even necessarily knowing what rebasing was, for instance.

It also meant that the git workflow, if it was version controlled, could also be amended.

This worked out much better than the git course people were sent on.

> It's easier to figure out the various workflows you need

Fine, that might be cheaper than properly training your employees. Of course, if your employees aren't training themselves out of genuine interest that's really the only option.

But then once something goes wrong you'll have to resort to "oh shit" websites and hope that you can the exact issue that you're having, since you really don't understand what's going on anyway.

> This worked out much better than the git course people were sent on.

I submit this must be because people came out of the course without really understanding the tool. Why they didn't understand I won't speculate, but I submit that they didn't.

EDIT: I think that which one is more appropriate depends on where it's used. I a big structured company I can believe that yours is better, or even crucial. But on a scenario where I'm starting a company with two other guys on a garage, I wouldn't want the guys to be the type of people who can only use a workflow that someone designed for them and never had the interest to dig under.

I tended to find that a few things were likely to go wrong and simply changing the git workflow scripts to account for those things was enough.

If things went wrong, people could come to me. That often resulted in me fixing their problem and fixing the script to ensure that kind of problem didn't happen again - after which people stopped coming to me because they didn't have problems.

Basically it was like releasing software.

>I submit this must be because people came out of the course without really understanding the tool.

I submit that not everybody needs to be an expert in the tool. Non-programmers can actually help a lot with writing stuff that needs to be version controlled with code - e.g. writing test scripts, updating translations, various configurations, etc.