tags:

views:

345

answers:

5

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 this) 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.

+3  A: 

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:

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

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

Miguel Fonseca
Thanks. Yeah, I saw that tutorial, but there's no chance they'll use the command-line. Also, none of the GUIs listed there handle my requirements...
Mauricio Scheffer
+7  A: 

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.

VonC
+2  A: 

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.

Jefromi
+1  A: 

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)

sylvanaar
You make a good point, but I do think that there are some benefits to actually using git. Off the top of my head, the most relevant one is that it'll tend to end up providing way better tracking of an individual designer's work, for example by letting them easily make incremental local commits instead of having to get it all together into something stable to push to a central repo.
Jefromi
I agree there are advantages don't get me wrong - like your example of local commits. Now is that something they really want? Will they remember to push the commits? I think this is an instance where KISS might apply.
sylvanaar
+4  A: 

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.