Should I expect my team to have more than a basic proficiency with our source control system?

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

Yes.

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.