My company switched from Subversion to Git about three months ago. We had weeks of advance notice prior to the switch. Since I'd never used Git before (or any other DVCS), I read Pro Git and spent a little time spinning up my own repositories and playing around, so that when we switched I'd be able to keep working with minimal pain. Now I'm the 'Git guy' by default.

With a couple of exceptions, most of my team still has no idea how Git works. For example, they still think of branches as complete copies of the source code, and even go so far as to clone the repo into multiple folders (one per branch). They generally look at Git as a scary black box.

Given the fundamental nature of source control in our daily work (not to mention the ridiculous amount of power Git affords us), I'm of the opinion that any dev who doesn't achieve a certain level of proficiency with it is a liability.

Should I expect my team to have at least some understanding of how Git works internally, and how to use it beyond the most basic pull/merge/push operations? Or am I just making something out of nothing?

  • 30
    Did the company offer any training on Git?
    – yannis
    Commented Nov 12, 2012 at 17:25
  • 9
    Any dev who is not productive is a liability. Assuming they are productive at large, knowing or not knowing git is inconsequential. At the end of the day it is just another tool.
    – MrFox
    Commented Nov 12, 2012 at 18:16
  • 9
    I would call understanding how Git branches work part of "basic proficiency" with it...
    – Shauna
    Commented Nov 12, 2012 at 18:35
  • 16
    If your teammates can't figure out Git you've got bigger problems than source control. Commented Nov 12, 2012 at 19:52
  • 4
    @Caleb That wasn't a boast. Far from it. Commented Nov 12, 2012 at 21:44

8 Answers 8


Professionalism would naturally dictate that a developer become familiar with their team's standard tools, even if they are new and unfamiliar (or even unwanted).

However, a few things in your post give me pause.

We had weeks of advance notice prior to the switch.

Weeks? Swapping out source control is a big deal. There should have been months of notice leading up to a change like that.

With a couple of exceptions, most of my team still has no idea how Git works.

So, your company switched to a source control system that few, if anyone, understood at the time?

Unless there is some other context, it seems like the whole move was ill thought out (the move, not the choice--I'm a huge git fan).

  • 3
    Granted. They made the switch to a system that pretty much nobody understood. It would have been wise to offer training prior to the switch. However, I was comfortable using Git with less than a week's practice. I don't feel like I'm overachieving, so I'm wondering if it's appropriate to expect the others to be practicing as well. Commented Nov 12, 2012 at 17:36
  • 3
    Did anyone bother to figure out the workflows you had and map them to the primitives that the new VCS has to offer? It's quite easy to shoot yourself in the foot with commands that sound like the ones you're used to, and you really need someone to orchestrate something like this. Where's the bloke responsible for this change? Commented Nov 12, 2012 at 17:38
  • 19
    @JoshuaSmith When changing standards or development tools, you should always operate on a "No Child Left Behind" style transition. The team can only move as fast as its slowest member so make sure that things are made as clear and dumbed down to the lowest possible level before the transition occurs. Sure you can label as many people a liability as you would like, but getting rid of "liabilities" is a difficult and messy thing to do, especially over something as trivial as a source control tool.
    – maple_shaft
    Commented Nov 12, 2012 at 18:18
  • 3
    Sounds like you "Dumped GIT on to them" rather "Rolled out a new revision control system" - GIT is a program that does source control. It is not a source control system -that would require user manuals, training, maintenance schedules, life cycle management etc. Please tell me you have a backups in place
    – mattnz
    Commented Nov 12, 2012 at 21:10
  • 7
    Learning how git works is pretty trivial. It definitely doesn't take a month to learn how to use it. In my opinion a simple "Guys, we're going to use git in a few weeks. Take a few hours to learn how to use it, there's a bunch of resources online.", would've been more than enough.
    – Moox
    Commented Nov 13, 2012 at 2:22

We've been introducing Git where I work and there has naturally been resistance. It was for a new project so we are now maintaining two repositories.

Part of the problem is that people won't see the benefits of switching to a different SCM when the one they've been using works for them. It helped when we sat down with our team for a couple one-hour sessions where we would just show use cases from our projects and how Git made it easier. For example, the things that helped us:

  • Local branches to encourage experimentation
  • Git bisect to easily track down bugs
  • frequent commits without interrupting others
  • Fast switching between branches

etc. Each of these solved a problem that we had encountered with our previous SCM and so people could appreciate Git more.

The other thing is that you can't expect people to go off and read books about it because very few will. Maybe they need to get work done, have other responsibilities, or any number of reasons.

So, as the 'Git expert' you have to sit down and make it as easy as possible for people to use it. They want to be writing code, not messing with their SCM system.

Git's CLI is cryptic and trivial problems (to you and I) will block people from working. Here's what happened on our team (mind you, these are fairly competent developers):

  • Git with SSH on Windows was a common issue.
  • People would pull, merge, but not push the merge. So the graph would be a huge confusing mess
  • Performance problem on Windows made "git status" take 15 seconds
  • Couldn't figure out how to pull a new branch. They would do a "git checkout -b " which would branch off of whatever they were working on
  • EGit in eclipse had an overwhelming menu. Ended up telling everyone to use command line at first
  • Based off the previous item, merging and setting up git mergetool
  • Confused about differences between "git add" and "git commit" and "git push."

We still get some resistance but people can definitely see the benefits. It is vital to have a few Git people for guidance and be willing to help out. Also I would avoid teaching cool things like reset/rebase/--amend/etc. because most people will use Git like SVN, it's better to let them discover it if they so desire.

  • 7
    @JoshuaSmith You seem to have high expectations of people. Do you feel disappointed in your peers often?
    – maple_shaft
    Commented Nov 12, 2012 at 18:41
  • 4
    @maple_shaft I'm rarely disappointed with my peers on this team (my last job was a different story). Typically the people here are professional and a pleasure to work with. And yes, I do have high expectations for myself and those around me. I'm not a jerk about it though. This is probably naive, but I feel that if we all demand excellence from one another we'll inevitably improve. Commented Nov 12, 2012 at 18:51
  • 9
    @JoshuaSmith, if you expect people to regularly have time for reading books, I'm going to hazard a guess: You don't have kids, do you?
    – Kyralessa
    Commented Nov 12, 2012 at 21:29
  • 13
    @JoshuaSmith do people get paid for reading those books? If my boss told me "we're switching technology, I expect you to have learned it in your spare time by next month" I'd be pretty pissed.
    – Matsemann
    Commented Nov 12, 2012 at 21:42
  • 13
    @JoshuaSmith, yes I'd say so - anything an employee does on their own time is extra, not mandatory. So buy switching, you should supply them with enough information to use the tool, or enough time during work for them to learn it themselves (usually this is provided in the form of training, even if that's just a lunchtime training session). Now, if the employees were freelancers, there's a case for them having trained themselves, but not during their contract. Employees expect certain benefits - like training, and not being stressed out by having a job change dumped on them like this.
    – gbjbaanb
    Commented Nov 12, 2012 at 23:03

GIT is a just tool to do a job, and one of it's biggest problems is that many GIT evangelists expect all GIT users to become under the bonnet experts understanding the finest points of how it works. This is GIT's biggest weakness - to use it you need to know how it works. There are no recipes with GIT, you are expected to be a GIT expert or not use it. It's great that you read Pro-GIT your organization needs a "goto" GIT guru ( or two ) to maximize the investment in it, because not every developer wants to become a GIT Guru - and that is OK.

The team need to know how use GIT (In fact they only need to know how to use the parts of GIT that the workflow requires them to use), not how GIT works. It is detrimental to expect every developer to know every detail about every tool they use. If you have not got a recipe book that supports your workflow, you have not deployed GIT, you have dumped it on the developers.

I don't give a monkeys how GIT works, as long as I know how to make git work for me.

  • 1
    And there lies the need for custom training ...and then again neither Linus expects anyone to embrace all of git's technicalities, that's why there are the two classes of commands: porcelain and plumbing.
    – ZJR
    Commented Nov 16, 2012 at 2:32
  • 1
    There are plenty of recipes for git if all you want to do is migrate from a workflow you used in Brand X to a workflow in Git.
    – Jherico
    Commented Mar 24, 2013 at 0:37

Proficient vs. Git-mania

A term like basic proficiency may mean different things to different people. A lot of people seem to have git-mania (not that there is anything wrong with that). Many of us have been burned really badly by our own and other people's sloppiness with source control.

Why it Matters (So Much)

Source control tools are critical because misuse can slow not just one person, but a whole team. Misusing Git should be less problematic than misusing SVN, CVS, and other systems. Historically, inept use of systems that locked files was particularly problematic, and companies hired discrete build teams so that when someone got into trouble, there was a fluent expert who did almost nothing but source control who could come cure the wound to the repository. This partially explains some of the passion you find behind git.

What does basic proficiency look like?

Some concrete criteria include:

  • Without reference to documentation:

    • Can add files, commit changes, push and pull updates.
    • Can view status and revision activity.
    • Can branch and merge quickly and without introducing errors.
    • Can use checkout appropriately.
    • Create commit comments that meet the group's criteria for comments.
    • Diff changes between working copy and archive.
  • With documentation:

    • Add users and credentials for local repo.
    • init a local repo.
    • Administer remote repo.
    • Configure ignored files, generate PKI public/private key pairs.
    • Move and delete files.
    • Use bisect to find the change that introduced a particular bug.

A solid mental model of git and the code being managed is critical to avoid mistakes.

What would you add for advanced proficiency / expertise?

Fluent use is essential for developers and possibly some other members of your team. Tools like Git are overhead and should be learned to a level where they can be nearly automatic. Minimizing time and distraction produced by using git commands that are repeated thousands of times per year has high value.

There will always be some members of your team who will be power users and use almost every command with almost every option. My recommendation is that team members be encouraged to keep learning git (and other tools) until the ROI for learning drops below the value of doing something else on the project, with the main limitation being keeping on pace with assigned burn down items from the current sprint.



No matter what tool the "company" has decided on, your development team should spend some time learning how to properly use the tool. Nothing hurts productivity more than a bunch of developers afraid or ignorant of a tool. If they are using it wrong or working against it, problems will arise and as the go to guy, you will be tasked with cleaning up the mess.

Git is a tough transition for many, so a mandatory sit down training session may be in order. This should help hammer out a lot of the issues people are having.

  • 3
    "Nothing hurts productivity more than a bunch of developers afraid or ignorant of a tool." So presumably a company would be crazy to go live with a tool that the team has not been trained in and doesn't understand.
    – Jaydee
    Commented Nov 16, 2012 at 15:13
  • Companies, especially big ones, have to push technology sometimes. Tt may also be one team within an organization that has already done the initial push and is using the tool fully. Commented Nov 17, 2012 at 17:21

I have only used Git in a personal setting and not a professional one, and while I do like the power it has and the idea of a more decentralized source control, it has major problems. Git has leaky abstraction and it takes multiple commands to do simple things (for example to make a change: git add, git commit, then git push). Also some of the documentation is lacking and/or confusing like with the rebase command description... "Forward-port local commits to the updated upstream head". I have no clue what that means, and although I now know you can move commits around and rewrite history with it (another annoyance... why should you be allowed to do this???) I would never have guessed that from that command description. I think some reading on the part of your team, and some more training provided by you is in order.


Training and understanding are the minimal requirements. Someone in charge should have made sure there was a plan on how your team would use it. You wouldn't adopt a new programming language without guidelines. Driver's training is much more effective when established rules of the road are incorporated.


No; I think it's reasonable to expect the following:

  1. Do everyday tasks (commit, push, pull, branch, merge, bisect, etc) without hand-holding.
  2. Do non-routine tasks without repeated instruction. (A few repetitions is ok - I have to meet someone 2-3 times before their name really sticks.)

If they can't do #1, then the training part of your roll-out was probably insufficient. If they can't do #2, then first make sure you're explaining things clearly enough before getting too upset.

  • This isn't really an answer to the question; the question was what level of proficiency should he expect from others, not how does he improve their proficiency. I'll take the downvote off when you notify me in comment with @MyName that you've corrected your answer to be on topic. Commented Nov 16, 2012 at 3:09
  • @JimmyHoffa I think you misunderstand my answer. They need to be proficient in their everyday/routine tasks, and pick up other tasks reasonably quickly. I identified a couple of possible causes, but tried to stay clear of prescribing any remedial action. You're reading between the lines and extrapolating if that's what you see.
    – pgs
    Commented Nov 16, 2012 at 3:53
  • No, the question is "Should I expect my team to have more than a basic proficiency..." and you didn't say "Yes, here's why" nor did you say "No, here's why". You answered a question with a question. I appreciate that your answer is thoughtful and the content is useful but you still should answer the question with a yes or no and try to back up why you think a yes or no... Then feel free to leave below your answer the current content. Make sense? Commented Nov 16, 2012 at 4:02
  • @JimmyHoffa My answer is "No, here's a minimum you should reasonably expect"; I just didn't say it in those exact words.
    – pgs
    Commented Nov 16, 2012 at 4:16
  • Oh, I thought you were alluding to a "yes", put that preface in and it's addressing the question, otherwise it just doesn't make sense heh Commented Nov 16, 2012 at 4:18

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