My team of 8 engineers is currently transitioning to Git (from Subversion) for our next big thing. We have a handful of 'more experienced' engineers that are finding it quite difficult to pick up Git. I get asked the same trivial questions despite having provided user manuals, training activities and whiteboard sessions. We had two Junior consultants who picked everything up in a few days and it really shone a light on the issue. This isn't a pattern that is limited to Git but it has become visible as a result.


I don't feel particularly favourably to engineers who can't/won't learn - especially staff with the levels of seniority we have here. However, I do want the team to succeed and build a great product. We are using a centralised Git Flow model and I feel like all the new terminology is baffling them.

Is there anything I can do to help these employees to learn Git?

Sourcetree is the client that is being used by the whole team.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – maple_shaft
    Commented Jun 27, 2017 at 11:35
  • 3
    The simple binary logic of fire vs keep may work for computers, it doesn't for people. You may want to check out workplace.stackexchange.com for your question once you feel ready to address it beyond the Git aspect.
    – Frank
    Commented Jun 27, 2017 at 13:47
  • Point out that Git looks good on the CV ;-)
    – Mawg
    Commented Jun 28, 2017 at 10:25
  • 1
    This is really a people / psychology problem, not a software engineering problem.
    – Jesper
    Commented Jun 29, 2017 at 13:32
  • @Jesper yes and no. I was going to put it on workplace but saw potential for some very Git specific advice (which I received!) that might be immediately applicable.
    – Gusdor
    Commented Jun 29, 2017 at 13:52

17 Answers 17


Give them a toy.

Git is hard. Especially if you've been doing source control in a different paradigm. I broke the build the first time I tried to work with git. It made me so paranoid that I didn't want to check in until everything was done. I was hiding versions in folders. Then I finally figured out what I needed to get past it:

I needed a safe place to play.

Once I had that, I was intentionally causing problems so I could learn how to fix them—all in my safe place. I developed a pattern I could use even if interrupted and still get back into a good state. Before long, people were coming to me for help with git. All because I took the time to play with a toy.

If you just toss them into the deep end, you'll be lucky if they manage to float.

  • 39
    I like this answer, but to my mind it raises another question: how do you motivate them to play with that toy when they are "too busy doing real work"?
    – David Arno
    Commented Jun 26, 2017 at 13:06
  • 20
    Give them credit for doing it if you have to. Hand out "Git qualified" certificates if you think you can sell that. But seriously, if this isn't of interest to them naturally you have bigger problems then Git. All developers should be able to use the developer tools. Commented Jun 26, 2017 at 13:07
  • 51
    @DavidArno Tell everyone to spend an hour per day on it, regardless of other work. Or even two hours. Being able to use source control properly is vital to a project. Learning those tools is "real work".
    – coinbird
    Commented Jun 26, 2017 at 13:50
  • 18
    'how do you motivate them to play with that toy when they are "too busy doing real work"? ' - This is real work.
    – David
    Commented Jun 26, 2017 at 14:33
  • 18
    I'm baffled. Nobody mentioned the obligatory xkcd!
    – GnP
    Commented Jun 26, 2017 at 22:26

The average dev doesn't need a lot of git's goodies. It's a distributed source control system but most teams will use it with a central canonical repo to push and pull from.

The core commands that your team will need are:

  • pull and merge changes from remote and handle resulting conflicts (potentially rebasing)
  • commit and push commits to remote (or push to staging repo/branch to get the changes pulled into main after review)
  • For support: fix mess after doing something wrong.

ones that the more advanced users will need are

  • handle local commits
  • manage branches

For people unfamiliar with git and those who don't want to learn it setup a few quick aliased commands to do them and make sure that everything is correct (add new files, remove deleted files from repo, etc.)

Make sure these are well documented and decently fool proof.

This is in the vein of the xkcd comic, just memorize the commands and hope things don't get messed up too much, when they do ask a professional.

  • 10
    He's using gitflow workflow so manage branches should not be considered an advanced topic - it is part of the core command his developers need to understand. Git in general treat branch management as something basic rather than advanced.
    – slebetman
    Commented Jun 26, 2017 at 14:46
  • 5
    @slebetman: Giving it a name doesn't make it any less complicated or difficult. Commented Jun 26, 2017 at 15:02
  • 3
    You mention "handle local commits" as something more advanced users will need. Theoretically managing versions in your own computer should be a notch lower in the difficulty scale that managing versions in a remote repo, shared with other coders. Commented Jun 26, 2017 at 15:59
  • Maybe if you work somewhere that has a full-time release manager then you don't need to worry about branches, but anywhere else devs should be pushing features to a testing branch each cycle, merging high-priority fixes from the testing branch to the development branch, and doing releases to production off the testing branch.
    – Rag
    Commented Jun 27, 2017 at 3:35
  • @RobertHarvey: Branching is neither complicated nor difficult. It's basic. The gitflow workflow is complicated in corner cases like bugfix releases but the common use-case is simple.
    – slebetman
    Commented Jun 27, 2017 at 4:02

Have them use a Git UI.

If they have experience with TortoiseSVN, TortoiseGit (Windows only) works almost exactly the same. Otherwise, SourceTree (Windows+Mac) is wonderful - we have multiple non-developer QA who have been able to easily master complex tasks in Git thanks to SourceTree.

  • 4
    +1 for SoruceTree. For a college project of ~30 students, I led a transition from Subversion to Git using SourceTree. People adapted rather quickly once they learned the basics, and we had plenty of links to documentation. I also encouraged experimenting in test branches. I'd say about 75% of the people were comfortable using it by the end of the semester, and some had even begun to use the command line.
    – Dewick47
    Commented Jun 26, 2017 at 15:05
  • 5
    Telling him to use a GUI he already said he is using does not answer the question.
    – WGroleau
    Commented Jun 26, 2017 at 16:08
  • 9
    The original post was edited to include that SourceTree was being used after this answer was posted.
    – Dewick47
    Commented Jun 26, 2017 at 16:11
  • 7
    I'll also suggest GitKraken. It's what I used to introduce some of my CS capstone project partners to Git. They picked it up within 15 minutes - it's dead simple, and has a beautiful, intuitive interface. And no, I'm not with GitKraken marketing. Commented Jun 26, 2017 at 21:04
  • 2
    git gui and gitk come with git itself, and I found them much easier to learn than the command-line tools. If you're naturally command-line oriented, then the simple GUIs are great for the very basics, and you can git rebase and more complex stuff from the command line. Commented Jun 26, 2017 at 21:59

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 ls and 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 add, 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.

Last words

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.

  • 13
    Possibly true, but the problem with this approach is that most programmers don't want to spend days understanding details of their source code control. They just want it to work, simply.. IMO, git fails at this. It's hard enough understanding how your actual code works to be worrying about blobs.
    – user949300
    Commented Jun 26, 2017 at 15:18
  • 1
    Your comment is 100% true, @user949300, hence my quip at the end about replacing git with some super-porcelain to not use git, effectively. The OP would need to adopt it (including the time involved) as appropriate for their business. As I wrote, I was not successful with this (or any other) approach, to get everybody "into the fold", but still, if I were (forced to) try again, this would be my approach again.
    – AnoE
    Commented Jun 26, 2017 at 15:43
  • 1
    Frankly I think you can get pretty far in using git without really understanding how it works. If you know branch, add, push, and pull there's like 95% of what the typical person will ever use.
    – Casey
    Commented Jun 26, 2017 at 16:47
  • 6
    @user949300 "Days" doesn't fit my experience with learning Git at all. Git has some of the best documentation I've seen on any project. You can pick up all of the basics from spending an hour reading the first 3 chapters of Pro Git, which is written in a very accessible format with plenty of diagrams. A quick "how do I ___ in Git" on Google almost invariably provides the rest - usually from a Stackexchange answer. Commented Jun 26, 2017 at 17:32
  • 1
    @Gusdor et al, keep in mind that this answer is specific to this very question - how to get senior programmers interested in learning about git. Obviously, all the other resources (excellent git documentation, tutorials etc.) are valid as well. Gusdor, if you want to know more, google "git objects" or "git data structures" and you will quickly find a wealth of information. I've added some links in the answer. You might even ask one of the seniors to make a brownbag session about that. ;)
    – AnoE
    Commented Jun 26, 2017 at 19:14

I would like to refer you to this blog entry by Joel Spolsky.

The reason you're seeing for these junior developers picking it up quickly is very likely because they do not have a predetermined notion regarding how version control in general works, or at least not an as deeply ingrained mental model of it. As such they come in with a clean slate. Your more senior programmers are likely trying to apply the concepts they already know, and are failing as a result of that.

In addition to this, as much as I don't like saying it; who actually reads user manuals? Typically they are very bad at explaining basic usage. Just look at the git commit page from the manual and consider how many new terms and phrases are being introduced to someone who isn't up to speed with the concept. Without a good introduction I'd likely have given up on using Git right there and then.

My personal advice would be to start explaining the commands:

  • git add < files >
  • git commit
  • git pull
  • git push
  • git status

Logically merge conflicts should be explained next, because that's definitely going to be your first issue once people learn how to commit code.

Typically situations will arise where people will need to invest more time into learning stuff (reverts, tags, merge conflicts, branches, rebasing, hooks) but trying to explain all of this before it's needed will not help the people who are having trouble getting into the flow.

Just to wrap it up: From my personal experience some people simply don't spend that much time exploring new techniques, concepts or tools and they typically tend to pick up things you introduce them to at a slower pace. This does not mean they are bad programmers or bad people, but they typically have a narrower skill set.

  • 1
    "who actually reads user manuals?" I feel like this might be a reasonable expectation of the newest junior developers, but I think that one of skills that that developers should learn over time is reading documentation. It's a skill to be developed, because the language of documentation isn't the same as the language of tutorials or more casual technical content, and because it's not always as obvious how different parts of documentation interact with each other. This shouldn't be as much of an issue with "a handful of 'more experienced' engineers". Commented Jun 26, 2017 at 15:19
  • 2
    Your blog entry link gave me an unrelated YouTube video.
    – WGroleau
    Commented Jun 26, 2017 at 16:12
  • 2
    I find git status to be vital, in addition to the four commands that you noted.
    – user949300
    Commented Jun 27, 2017 at 2:13
  • 1
    @JoshuaTaylor I did not intend to say that manuals are bad, they are actually great. However, imagine referencing someone to man git and just saying; come on, it's easy to learn, just read the man pages. My point is not that documentation isn't great, a lot of it is impeccably written and useful for people who know the domain it's written for but it's typically worthless for someone looking for basic usage. EDIT: And that last point is seemingly the issue that the OP is having.
    – Robzor
    Commented Jun 27, 2017 at 6:49
  • @user949300 Good catch, I absolutely agree.
    – Robzor
    Commented Jun 27, 2017 at 7:26

Git is a major rethink if you learned how to do source control on SVN. Many of the habits you developed there (which may have well been best practice for SVN) will misguide you when using git. This is primarily because git's branching model is so fundamentally different. It doesn't leverage folders for branches, and it's also possible to make it non-linear because it was designed to support the distributed use cases better. It takes some time to unlearn SVN habits and understand how you're supposed to use git.

Start simple

You say you've chosen Gitflow as your standard for branch management. This strikes me as your biggest mistake.

To quote Gitflow Considered Harmful:

All of these branches that are used force GitFlow to have an elaborate set of complicated rules that describe how they interact. These rules, coupled with the intangible history, make everyday usage of GitFlow very hard for developers.

Can you guess what happens whenever you set up a complex web of rules like that? That's right - people make mistakes and break them by accident. In the case of GitFlow, this happens all the time. Here is a short, by no means exhaustive list of the most common blunders I've observed. These are repeated constantly, sometimes every day, often over and over again by the same developers - who are, in most cases, very competent in other software areas.

Your developers are likely overwhelmed by the sheer complexity of this standard. I don't personally think it has any benefit, and the article above makes the same argument. But that's a separate discussion. Objectively, though, it's a pretty heavy standard with a lot of manual management, and it requires a lot of cognitive effort.

You need to start simpler. Don't worry about a branching standard right now. Focus on getting them used to using git first. You only really need a few operations to get started:

  • clone
  • pull
  • branch
  • merge
  • commit
  • push
  • knowledge about how .gitignore works
  • maybe tag

Yes, your history might look at little messy at first. This is okay. Don't worry about it right now. Just get them using git.

Gradually increase knowledge

From here, you can gradually educate them on slightly more advanced usage.

  • Teach them the epic stash command
  • Teach them how use reset when they want to throw away the local commit they just made
  • Teach them how to amend
  • Teach them how to rebase to avoid unnecessary merge commits
  • Teach them how to interactively rebase to organize their commits before they push
  • Teach them how they can checkout from any hash, tag, or branch

Especially make sure you take advantage of opportunities to show them cleaner ways of getting their code into the repository, but also teach this stuff in training activities and what have you. Having a guru or two that people can approach when they're not sure what to do will help a lot, too. If you have something like Slack, create a dedicated channel and encourage people to ask and answer questions there.

Then choose a branching standard

Once you have most of the company competent in using git at all, then you can look at branching standards. Choosing one up front is a really bad idea for multiple reasons:

  • They don't have enough knowledge of the tool to tell you whether the standard works well for the company's use cases
  • They won't be able to offer alternative standards
  • They have to learn both the tool and the standard at the same time
  • Some will assume the standard you pick is the only way they can use git
  • They won't be able to identify rare edge cases where the standard is doing more harm than good

You shouldn't be handing down a Git workflow from the mountain. Your team needs to have input on it and be able to give you feedback about whether it's going well or not. They can't do this if they don't even understand the fundamentals yet. You don't need every single developer to have deep knowledge like this, but you definitely need several who really get it. And you need the vast majority to be at least competent in git so they know enough to stay somewhat on the rails.

Here are a couple alternatives to Gitflow your team can consider:

Look at them and Gitflow, weigh them against your use cases, and pick one that fits.

  • 2
    +1 for mentioning alternatives to Gitflow. In my experience, a lot of suffering comes from dev shops trying to adopt it when it's overkill for their needs and/or don't use it properly. A simpler model is almost always better in those cases and has the added benefit of making Git far easier to learn. Commented Jun 27, 2017 at 0:14
  • 5
    @Thunderforge I disagree with calling it "overkill," as this suggests it's somehow more powerful or flexible or in some way advantageous. I really don't believe that Gitflow has any advantages. It seems to be a step backwards: trying to take complex workflows that are necessary in other version control tools like SVN and just use Git the same way. Git has the flexibility to enable simpler workflows in the first place, though. I think the appeal is that it gives the illusion of having to think less (rules and instructions) without delivering. But your point is taken. Thank you.
    – jpmc26
    Commented Jun 27, 2017 at 1:00
  • 4
    I agree with your approach. We converted to Git from SVN not too long ago. We gave the other devs a list of commands that they SHOULD use, a list of commands they SHOULD NOT use without help, and a list of commands they SHOULD NEVER use (at least not without help from the local Git experts). We gave several trainings on the basics of how Git works and how to use it. Over the course of several months, our team slowly got used to it. Now we only have occasional problems with devs getting confused.
    – Kyle A
    Commented Jun 27, 2017 at 1:00
  • 1
    @Gusdor Your question says "currently transitioning." What does that mean? Also, if you're not getting buy in, Gitflow is unlikely to succeed because it's so heavy weight, whether you think it has advantages or not.
    – jpmc26
    Commented Jun 27, 2017 at 12:56
  • 2
    @Gusdor My advice to you is that you may need to develop your teaching skills. You need to get better at identifying the root cause of a misunderstanding or missing information. You need to be able to work out where someone's reasoning is going wrong. To write documentation, you need to not only be able to tease it out of an individual, you also need to be able to anticipate where people will get confused or what will make them give up on trying to use it.
    – jpmc26
    Commented Jun 27, 2017 at 13:24

I found stackoverflow very helpful while I was first picking up Git terminology. Questions like these ones were really useful for me (mostly because of their conciseness) and I kept them open in tabs during the first couple of weeks I used it. Maybe print out a couple of the answers in bold? Especially the diagram on the first one.

What are the differences between “git commit” and “git push”?

What is the difference between 'git pull' and 'git fetch'?

I also found a visual representation of the trunk to be amazingly useful but you're already covering that one with SourceTree.

Aside, this bit probably belongs in a comment but I lack the rep: I'm one of the junior consultants mentioned in the question. Before I started I had some idea what a source control system was and I'd poked SVN literally twice, Gusdor gives me more credit than I deserve. The whole team had high-quality specialised Git training, toys and time to play. The problem is not with Gusdor's instruction. I hope there's a good alternative solution to this so I can bookmark it hard and learn more.

  • Great links. I'm going to steal that Data Flow image!
    – Gusdor
    Commented Jun 26, 2017 at 17:41

Buy them a book

Honestly, I fell squarely in the camp you describe. I came from a background of SourceSafe and ClearCase. At first, Git was completely inscrutable to me, despite my boss walking through it several times.

What helped me was a book which clearly described what was going on, but more importantly, how Git was fundamentally different than any source control system that I had used before. Now, I prefer Git over any other choice.

Unfortunately, I cannot recall which book I had read at the time, but, just make sure whichever one you get for them (or point them at) focuses on how it's different and how it requires a different mind set.

Best guess for a book recommendation is:

Pro Git by Scott Chacon (Amazon link for ease... buy from whoever you want: https://www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 )

Note: Do not buy a reference book for Git. That will not help at all.


From my experience, some people can be comfortable using git without understanding it. They find basic tutorial, pick up basic commands and they are good to go. That's probably where you junior consultants fit it. I don't believe that you can really learn git in few days!

Other people, can't do it, they need to understand what git is doing, and that takes more time. I was in that category; I found it really helpful to play with contents of .git directory, that's when things started to click for me. Also one on one sessions with our tech lead helped.

You can do one on one tutorials because people learn differently and can be really confused about different parts, in a one on one session it is easier to see, and resolve. If they are really bothered by the fact that they don't understand how git keeps track of branches, show them contents of .git directory, and so on...


I'm toying with introducing git where I am (from TFS) so your question is timely to me, especially as I've also had some push back when broaching the subject.

In Peopleware, the underlying theses of the whole book is:

The major problems of our work are not so much technological as sociological in nature.

I bring this up because ours is not a technical problem. git, whilst a little obtuse, probably isn't beyond the ability of yours or my senior devs, unless they are extremely stupid*.

Let's look at it from your devs point of view, as people, not technical machines:

You are asking them to stop using a source control system that they have (likely) mastery of, to one which they don't. It's a bit like asking a git expert to stop using git and move to svn isn't it? I reckon the git expert would be annoyed, and probably not put much effort into svn because git works fine and there are parts of it that she really likes that are really hard to do in svn.

That's probably why the juniors have taken to it better - maybe they haven't got the hang of svn and git is their chance to ditch it^.

The seniors though are wary of the opportunity cost - if they learn git, then they are not:

  • Learning React/Angular/Swift/Blockchain/Kotlin (some other thing they feel they should be learning).
  • Doing DIY/whittling/sailing/poetry/glockenspiel/whatever else they actually want to do.
  • Spending time with their children/relatives/friends/significant others.
  • Delivering this "big new thing" - there's a deadline, budget etc. They're probably worried about it.

    "I need to do all of the above, why do I have to use git when we already have source control?"

What reasons have you given them for switching from one thing that they are good at, to another thing which is frankly awkward when you're new to it, and requires a complete rethink on how you do dev? Have you explained the benefits of git features?

Pull-requests? Fine grained checkins? Distributed source? Forks?

Have they brought into these reasons? These are massive, structural changes if you are in a centralised source control mind set - not just technical changes but cultural too, and we know how difficult it is to change a culture.

So basically, think through what it is you're asking your developers to do and make sure it is for the right reasons. If you just want to do it because svn is stupid and old and no-one uses anymore then fine, but that's harder to sell to others that don't think like you and just want to crack on with their day. You need to state the benefits in terms that make sense to your team and to the project. If you can get them to agree that git is worth the pain, then you don't have to worry about them learning the tech, just agreeing to whatever workflow you've set up.

Good luck.

* I highly recommend people remember that most developers are not stupid when it comes to technical stuff. Just discard that as a reason till there are no other explanations.

^ and be more employable, which is something seniors may not think about so much, especially given the ageism prevalent in our industry.


I think this is less of a software engineering question and more of a psychology question. I'd like to refer to Algorithms to Live By: The Computer Science of Humand Decisions. In it the author goes into the topic of the explore/exploit tradeoff. Humans usually go through a phase of exploration and then through a phase of exploiting (using) what they've explored. There is some solid mathematical theory behind why this is the case in order to get optimal use out of something in a certain interval.

This also extends to age and experience. Humans see their own lives as an interval, and after a certain exploration phase it's optimal to start using your knowledge. They quoted a study in which older participants were asked if they wanted to meet someone famous who they like or rather a family member. They usually chose the family member, while younger people chose the famous person more likely. However when asked to imagine how they would decide if they were 20 years younger, the older people routinely also chose the famous person. Which suggests that people stop building their social networks when they believe they have less from exploration than from exploiting what they already know.

Your senior engineers are probably older, they've probably gone through a few version control systems. SVN is probably the best one they've used until now (at least looking at the older versioning systems I used, SVN beat them all).

Their optimal strategy is to exploit SVN, because they've done their exploring and have found this is the best, which they exploit now.

This is basic human psychology, and hundreds of thousands of years of evolutionary optimization you're fighting against.

You'll need to show them a) how long a career they have in front of them, to prime them for thinking from a different perspective on the interval they see themselves on and b) ask them what they think is great and what they're missing in SVN. You can lay out hundreds of benefits of git, but they'll already have a clear idea why SVN is the best, after all they experienced probably 5 version control systems before. You need to find the chink in the armor of that argument, and then see if git can solve for these problems, then they'll have convinced themselves.


Don't give them a tool or a GUI to use Git. It will only confuse things. Git was conceived to run on a command line so that should probably be the place it is learned. Any GUI may come with its own terms and peculiarities, stick with what is simple.

Next would be to look at some of the problems Git does better than SVN. To get your team to learn it you need to motivate them to see why git is better.

  • Ability to commit while not connected to network
  • Ability to make and play with their own branches
  • Patches that can be sent between each other and still merge track
  • cherry picking without pain.
  • rebasing changes
  • finding bugs with git splice

I'm sure SVN has moved on in the last few years, but those used to be things that would cause a world of pain. If the devs see that this new tool is not just some fancy thing but has solid advantages for their work they may be more likely to get behind it.

It is a new thing to learn and there are enough similarities that it can get confusing, but really in 2017 DCVS is pretty much an essential skill for every dev.

  • 1
    +1 Other that the very advanced topics like cherry picking and rebasing (rocket science to me), learning with the command line is an advice that actually makes a lot of sense. It's the only way to actually learn Git. You first learn HTML before using Dreamweaver, right? I would create some aliases to the most common commands front the get go. For example the Log command is byzantine and arcane, just create an alias for them that prints a nice history. Commented Jun 26, 2017 at 16:12
  • 7
    I totally disagree. A view of the DAG is by far the most important tool for understanding what is happening. A view which will only come from a GUI. Commented Jun 26, 2017 at 19:34
  • 1
    git log --graph --abbrev-commit --decorate --date=relative --all Commented Jun 26, 2017 at 20:07
  • 1
    git gui and gitk come with the main git package, and don't try to make git look like anything else. They're excellent, especially gitk --all for seeing all the branches, and for resetting the current branch to point to other commits, or stuff like that. In gitk, "cherry-pick" is one of the options you get when you right-click on a commit. It uses the same terminology as the command-line tools. Commented Jun 26, 2017 at 22:03
  • 3
    @JeremyFrench ASCII art is not a very useful way of viewing a graph as complex as a git repo.
    – jpmc26
    Commented Jun 26, 2017 at 22:18

Tell them not to worry

In Git, once work is committed, it's nearly impossible to lose. The only work you can easily lose is work that hasn't been committed yet.

Show them how git reflog works. They don't have to know how to use it; they just need to know it's there, so they can get help to get their work back if something goes wrong.

Then impress upon them this one simple rule: When in doubt, commit. They can always back out the commit later (even from the remote!).

Don't use a GUI

A GUI will give them a quicker start, but they'll never really understand Git. Furthermore, I've found that it's not "nearly impossible to lose" committed work when using a Git GUI. I've seen GUIs do horrible things like present a checklist on merge and then, if the user unchecks an item, wipe out that file from the history with no warning and no record of it. A GUI is far worse than simply learning command-line Git.

Pair-program code commits

Learning git add -A followed by git commit shouldn't be too hard, but particularly when merging (or rebasing) against the remote, they'll need some assistance. Make it clear that anyone is welcome to ask for assistance at any time. Stand by while they type the commands and take notes. Over time they'll gradually increase the number of situations they can handle without help.

Git is already safe

Someone above talked about having "a safe place to play." But Git is that safe place. There are only two normal, everyday cases where it's easy to lose work:

  • Uncommitted code
  • Using a GUI

Make sure they commit early and often, and that they don't start down the wrong path with a GUI, and they'll soon see that they can trust Git with their code even more than other source control systems in the past.


I would advise a look at Gitless. It's a wrapper over git that simplifies the basic workflow a lot (no need to worry about a staging area, branches keep their own working copies of files, the simpler uses of git rebase are handled with gl fuse, etc.) while maintaining an underlying git repository for collaboration or if you need to do something unusual. Also, the messages are a bit more novice-friendly. And the commands are close enough to git to act as a stepping-stone if they need to use a system without gitless on it for whatever reason.

  • 1
    This is a very interesting idea, but I have to wonder—if Gitless isn't truly drop-dead simple (and what is?), then the investment in learning it might be a waste of time. You might as well put in that little bit of extra effort to learn git proper, which would be a more versatile and marketable skill. Perhaps if we could convince Torvalds, Hamano, et al. to integrate the Gitless interface, then we'd really have something. Commented Jun 27, 2017 at 7:20
  • Well, it's as simple as you're going to get within scope of a Git-compatible porcelain. All the usual commands are one-ops with distinct names and no arguments needed.
    – Vivian
    Commented Jun 27, 2017 at 12:35

I tried documenting the basics of how to use git's command line. It was still confusing -- both to myself (who had experience using Perforce and Source Safe), and to programmers who preferred the old "just zip up the relevant folders" paradigm. It was worrisome having an opaque tool modify the contents of my working directory, and often having to argue with the tool to incorporate particular changes into my working directory.

Instead, I use two kinds of indirection.

  • I use GitKraken to provide a visual history of my branches, and a GUI that hides the command line statements. GitKraken handles the interactions between the "origin" remote repository and what git thinks is my local working directory.

  • I also keep a "real" local working directory that is separate from what git thinks is my local working directory. I manually sync these two working directories, which lets me be far more comfortable that any changes in my working directory are what I intended to have.


Is there anything I can do to help these employees to learn Git?

Are you sure that the issue is Git and not something else? What I get from the comment is that management decided to change something without getting buy in from the senior contributors and are tasking someone junior to them to drive the change. That seems a good starting point for failure, what ever the change is. Git complexity is not an issue, the issue is that a change they don't feel a need for is forced upon them.

So don't focus on how to teach them Git, as long as they don't see an advantage for the switch they'll be dragging their feet. Show them how Git is a solution to issues they have now. Not how Git can provide them things they don't feel yet a need for, not how Git provides a solution to other people issues, how Git solves issues they are fighting now. Then teaching them Git will be a non issue.


Often Git is brought into use at a company to solve problems with branches. Yes it is better at branches then Subversion, but it does not do any magic.

It is very likely that the experienced developers have work in many companies that have.

  • Created branches as management is not willing to decide between conflicting demands
  • Have used a branch for each customer rather than configuration switches.
  • Have had to have a bug fix branch for each customer as management was not willing to make all customers upgrade to the same version of the software
  • Etc.

Therefore as soon as some tells me that a tool is good at branching my mind says to me.

The management do not want to deciding what way the company is going, and would rather that I wasted by life having to merge my work into 101 different branches, along with having to test 101 different releases of the software.

Also the concept that two people would be working on the same file at the same is “good”, is just not acceptable to someone that has experienced a well run project, therefore promoting Git as a tool for doing so, is unlikely to get experienced developers liking you.

Every time I have look at history in Git, it is very hard to see why code was change, as 50% or more of the history is merges that logically should never have been public and they become meaningless as soon as the code leaves the developers machine.

But I would love to work somewhere where:

  • No code gets into the central system until it has been compiled and unit tested on a trust server.
  • There is a easy way to track code reviews
  • Where whenever I do a “get”, the code always compiles and works
  • Where I can push my changes without having to have a race with someone else, or having to stray in the office to see if I have broken the build.

So solve the real problems and if Git is part of the solutions your experienced developers will buy in, but don’t expect them to like Git just because it is a cool toy that can do “magic merges”.

Therefore anywhere that lets a developer push from their local Git to the central Git is doing it wrong, a controlled automated process should be taking the changes from the developers and after testing them etc, and checking mergers are ok updating the central Git flatting out all branches etc that are not of long term interest.

I expect that Kiln (http://www.fogcreek.com/fogbugz/devhub) or even GitHub using a “pull request” workflow would keep experienced developers happy, e.g. don’t start with the low level took, start with the improved process.

  • 1
    The reasons for transitioning to Git are: 1. Community advice and documentation 2. Wide tool compatibility 3. No vendor lock. We have built a tooling pipeline (largely jira > bitbucket > bamboo) that enforces code review and unit testing before reintegration. What gave you the view that we are cowboys?
    – Gusdor
    Commented Jun 27, 2017 at 11:59
  • @Gusdor because GIT was created for organizations without central control e.g. cowboys.....
    – Ian
    Commented Jun 27, 2017 at 12:10
  • From the question body: "We are using a centralised Git Flow model..."
    – Gusdor
    Commented Jun 27, 2017 at 12:19
  • 1
    Thats an interesting point. When I was first hired, the VCS went bang and i was asked my opinion on the replacement. I chose SVN because I assumed GIT could not be used centrally. No sure many of our guys browse SO though :O
    – Gusdor
    Commented Jun 27, 2017 at 12:43
  • 1
    @Ian By this reasoning, all Internet users are advancing US military interests because the proto-Internet was originally created by and for the military (DARPA). Also anybody wearing velcro strap shoes obviously is NASA because velcro was invented for zero-G applications.
    – maple_shaft
    Commented Jun 27, 2017 at 12:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.