15

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.

Mauricio Scheffer
  • 98,863
  • 23
  • 192
  • 275
  • You could write them a bunch of executable scripts that they could just double click on that perform common git tasks like 'git ci -a ...' Would that work? – Robert Massaioli Oct 22 '09 at 21:55
  • 3
    Forgive me for possibly not being too helpful but... if you're in any sort of position of power: explain to them that this is a requirement for their job. Things change, technology comes and goes. Point them at gitready.com or similar and simply expect them to get up to speed. – rfunduk Oct 22 '09 at 21:57
  • 1
    I do not want to talk you out of git, but have you considered mercurial? It's rather similar to svn (besides the distributed stuff ofc) and there is TortoiseHg, which works for win + linux. – ebo Oct 22 '09 at 22:00
  • 1
    I don't quite understand. They will be using it for what ... most of the functions it does you've excluded. They will only be commiting or ... ? To me it sounds like it will create more problems than gain, expecially if the crew is pro against it. (I'm aware I'm not helping - I'm just trying to understand your position ... I've tried introducing svn into non-programmer group (engineers mostly), and can imagine the trouble you're going to go through) – Rook Oct 22 '09 at 22:01
  • 1
    @Idigas: I think he wants to make sure the content is tracked, and have a way to "synchronize" between various people and probably a central version. Think of this as asking for another layer of abstraction - you've got the git plumbing, the git porcelain, and are hoping to find a git $2000 voice-activated Japanese electric toilet out there somewhere. – Cascabel Oct 22 '09 at 22:23
  • @Shhnap: yes, that could work. If you know any such set of scripts, please post an answer. – Mauricio Scheffer Oct 22 '09 at 22:26
  • @thenducks: I know, I just want to make things easier for everyone, I'm trying to "lower" (?) the learning curve. Plus, many of them are not fluent in english. – Mauricio Scheffer Oct 22 '09 at 22:32
  • @ebo I really like git but I could certainly consider hg if it makes things much easier for the whole team. – Mauricio Scheffer Oct 22 '09 at 22:33

5 Answers5

6

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
  • 1,262,500
  • 529
  • 4,410
  • 5,250
4

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.

user195595
  • 1,294
  • 1
  • 8
  • 2
2

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

Community
  • 1
  • 1
Filipe Miguel Fonseca
  • 6,400
  • 1
  • 31
  • 26
  • 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 Oct 23 '09 at 03:10
2

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.

Community
  • 1
  • 1
Cascabel
  • 479,068
  • 72
  • 370
  • 318
1

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
  • 8,096
  • 37
  • 59
  • 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. – Cascabel Oct 23 '09 at 16:18
  • 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 Oct 23 '09 at 17:09