This answer tries to address how to get senior programmers interested in
git, not about how to learn
git the quickest way - for that, the excellent git book is great, or any amount of tutorials (=> Google). Good links to go with this answer are Git is a purely functional data structure or especially the short How git stores your data.
I'm afraid I have a rather bleak view on this. I have been in exactly your shoes - I'm a
git nerd and wanted to transform a team away from
svn with, let's face it, minuscule results. In my case it has lead to me actively changing my own perception, and accepting that people, just cannot be "forced to happiness". People are not computers, it is incredible hard to program them. I am still happy for having tried, it has shown me in a rather soft way what I do and what I do not want to do in my professional life.
There are people who start to get motivated when new stuff is involved, and there are those who are demotivated. This has nothing to do with
git, but for
git specifically you always have the effect of "why should we use it at all if
svn is just fine?", which is a massive psychological barrier.
Also, really grokking
git requires an intense interest in abstract data structures. It may sound unbelievable, but in my experience there are programmers who have no interest that at all and who are bored and overburdened by elements more complex than simple arrays. You can argue back and forth whether those should be doing the job they are doing, but it is what it is.
If people are not interested in it, they won't understand it. Plain and simple. I'd wager that disinterest is the main reason of bad grades in school, not missing intelligence.
That said, here would be a curriculum as I would apply it, based on bottom-to-top build-up of knowledge. It has not worked for me, but you may take it as inspiration to roll your own.
While the following approach does not necessarily need GUI support for the actions (
git add in a hello world repository...), it helps tremendously to have a GUI for visualizing the repository, right from the start. If you can't decide on which to use, then take
gitk as last resort. If your guys use any kind of visual editor, find their
git GUI component.
The (static) data structure is key
Start by explaining the internal data types (there are only three-plus-one of them: blobs, trees, commits, annotated tags, the last of which is of no concern whatsoever at this stage) and their structure. You can easily do that on whiteboard / with a pencil; the tree is easy to draw as it can never be changed, you can literally just add stuff all the time. You can do a play session in a freshly created local repository and use
git cat-file to look into the actual objects to show them that they are in fact as trivial as advertised.
If you can help them to understand that
- ... there are literally only 3 types of objects in the history, all of them very simple, almost trivial, and
- ... most of the
git subcommands just "massage" those objects in one way or another, with near trivial operations (basically, there is only one: add a new commit somewhere), and ...
- ... everything can readily be seen right in front of you with
git cat-file ...
then they will have the mental translation of what is actually in the repository. At this point, the seniours may remember that the internals of
svn are arcane magic (ever had problems with locks inside the svn repository, or with "reintegrating" branches and such?), and this may just motivate them a bit.
One problem, specifically with people used to
svn, is to get used to the idea that one commit (the object, not the action) always is the whole directory tree. In
svn, people are used to commit individual files. It is a radically different approach. Oh, and the fact that the same term "commit" is used both for a static object and an action is not helping, either.
The other problem for
svn guys is that
svn uses a linear history, not a tree. This is, again, wildly different. So this is the time to point of these differences a lot.
Actions explained in terms of the structure
When they have understood what parts a
git repository is made out of, it is time to show them exactly what the individual
git subcommands do in terms of those.
I am talking about
commit, in conjunction with the local working directory and the stage (make sure they understand that the working directory is not the same as the staging area which is not the same as the repository).
When they have understood that these commands simply grow the tree (which, again, at this stage, consists of 3 of the types - blobs, trees, commits, not only commits), you can do a first
git push and
git pull (in fast forward mode!) to show them that
git is literally only pushing its objects around, that the hashes are really only content hashes, that you can easily copy this stuff around with a file system copy command and so on.
Obviously, stay far away from any nonessential options of those commands, we are talking
git add hello.txt here.
Note that branching is especially hard for
svn people, as it is totally different. The
svn model is much easier to visualize, as there basically is nothing to visualize - it is in plain view. The
git model not so much. Make sure they are aware right from the start that branches and tags are just "sticky notes" pointing somewhere, and do not actually "exist" in terms of the static, immutable history.
Then do example after easy example to show what you can actually do with them. As you yourself seem to be used to
git, you should have no trouble finding motivation there. Make sure they always view this in terms of how the tree grows.
If they have that down, you can explain how
git pull is really
git fetch && git merge; how all repositories actually contain exactly the same objects (
git fetch is almost the same as copying stuff over with
scp inside the git object directory) and so on.
Probably, if by this time you have not reached through to wake their interest, then you can just as well give up, but if they manage to get so far, then they have all the mental tools at their disposal, and there should be little fear involved anymore. The rest (git workflow...) should be downhill then.
This sounds like a lot of effort, and it really is. Don't sell this as "we need this for this project" but "this helps you personally to develop and will help you in all your further interactions". You need a lot of time for this, and time is money. If you don't have management acceptance on this, it may just not be worth it; you should maybe talk it over with your boss.
If you decide you want to give up teaching the developers who are seemingly not able to grasp it, but you absolutely must use
git in the future, consider replacing all interaction with
git commands by cooked-up scripts or some GUI which takes all
git specifics away. Pour all the error control etc. in the scripts, and try to get that working.