Git setup for non-developers

I'm trying to introduce git at work, and to do that I want to maximize team buy-in.

This is not a problem for programmers (we're usually delighted to learn new stuff like t开发者_JAVA技巧his) but it is a problem for designers and content managers who commit static content like html, css, etc. They can barely use Subversion via TortoiseSVN, so I need to simplify git as much as possible. This means that some concepts have to be somehow hidden, like index, stash, merges, rebase, branches.

Dirty working copies should be automatically handled with stashes.

Also there's no way they will use the command-line. They also won't read any guides or tutorials.

You might wonder why I don't just stick to git-svn: it's because designers have to tweak the html/css I create before it's merged into trunk.

So the questions are: has anyone used git with non-developers? how do you handle it? what's your workflow? could git-cvsserver be useful for this? Is there any GUI that does automatic stashing?

Anything that could be used to simplify git will be greatly appreciated.

Basically, you need to make Git:

• transparent for your non-technical users
• administered by one technical Git-savvy "superuser"

That means:

• one central Git repo where every designer/content manager will push to (even if they do not know it)
• scripts running every day (usually early in the night) for:
  • monitoring a central "instruction file" (which can instruct said script on each committer's station to change branch, or update a .gitignore file, or...)
  • git add -A, git commit
  • git push
  • git pull (they need to be aware to review each morning their workspace in order to take into account new works pulled from the central repo)
  • write the result of all commands in dedicated files (dated and named after the committer, in a central shared directory)

Each morning, the superuser would check if all pushes are successful and solve any conflict. He/She also would merge approved work in the local branches of the central repo (including the one which is pulled every night).
I would also recommend making those Git repositories (on committer's workstations) in a shared directory, in order for the superuser to be able to access them and directly manipulate them if need be.

We have a few designers working with git using GitExtensions. They don't have any problems because GitExtensions does everything automaticly like stashing, pushing and warning the user when there is any sort of problem/conflict. Settings are automaticly checked on startup and there isn't much that can be done wrong. It is a lot easier then tortoisesvn once you get used to the terms push/pull/commit.

You said they won't read tutorials, but maybe you can read this one an explain it to them..

http://hoth.entp.com/output/git_for_designers.html

As for the GUIs take a look at these posts:

https://stackoverflow.com/questions/157476/what-guis-exist-for-git-on-windows

https://stackoverflow.com/questions/83789/what-is-the-best-git-gui-on-osx

I just saw this question pop up. It mentions flashbake, which appears to be a set of python scripts (which you could install for designers as icons for double-clicking as suggested) that take care of a lot of common git actions. I've not used it, but it looks like it'd probably be way better than starting from scratch - and if you make some improvements, it'll help others in your spot! From the project page:

The main focus of the scripts is to generate a rich but automated commit message for git. Secondarily, it automates managing a git project so a single, invariant call to flashbake takes care of the most common git workflow, adding and committing files.

I definitely also think VonC's suggestion above about workflow including a lot of oversight by a superuser is another big piece of the answer here.

Why not just let them continue to use SVN, and let the more tech savvy use Git.

Git is able to work with SVN repositories. So keep an SVN repo for the designers, and a git repo for the developers. Have your expert users manage pushing and pulling between the two if need be.

TortoiseSVN is very simple, and it sounds like it is all that your non-techie users really need. What benefit will they see if they move to Git?

(Just a note - I don't really get why you can't use git-svn)