Our company uses git to to keep track of document/code changes, with several people making changes and pushing to a central repo. Most of them are novices when it comes to git or command line tools in general. For them we have scripts to update or publish their local repo after making changes.
Are there any workflows that work better for situations like these, to minimize merge conflicts occurring that have to be sorted out by someone more experienced with git?
Git is not a replacement for proper development practices. It will not code better for you.
If two developers are touching the exact same code, git has no way of making their job easier, if it's a merge conflict, it'll be one no matter if you're on a branch or not.
Short term solution: use proper local and remote branches to encapsulate work on different features. Use branch diffs (or github pull requests) to review feature sets and help go over diffs and conflicts.
Long term: fix your code, adapt your it to your team and vice versa, and use proper development practices.
The number one reason for merge conflicts is the time between each merge.
The longer you wait between each merge, the surer you get to see merge conflicts.
You can minimize that by choosing a merge workflow (like git flow for instance) which will advocate for branch per feature, and facilitate the isolation of tasks.
But as long as a common set of files is involved (in two different developments), you will end up with merge conflicts, especially if you wait too long.
So with a distributed VCS, learn to publish (push/pull) regularly, and learn to rebase before merging.
Not only will that decrease the number of conflicts, it will also reduce the number of semantic conflicts: those are merges which seem automatic (no conflicts), but produce an incorrect code.
See "Better, simpler example of 'semantic conflict'?".
Nothing magical. Mostly discipline.
If people have to do something like pull requests or to wait for commits to be reviewed before being merged with some "main" repo or branch, do try to make the time for review as short as possible.
You should probably try to make branch lifetime short, but that really depends on the kind of project you are working on.
Make it a rule that all commits must be as small as possible. Make it a rule that commits must change only one thing. Make it a rule not to mix cosmetic changes (like whitespace) with functional changes and significant refactoring. (Don't forbid whitespace changes completely - just separate them from other changes.)
Beyond version control itself, try to assign tasks to coders in a way that diminishes the chance that they change the same code on the same week or so.
There's an article written here that will help you understand better, "A successful Git branching model". It states that you should separate different types of branches, which include:
