47

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?

Joshua Smith
  • 2,050
  • 18
  • 24

8 Answers8

48

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

Michael
  • 6,437
  • 2
  • 25
  • 34
  • 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. – Joshua Smith Nov 12 '12 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? – Lars Viklund Nov 12 '12 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 Nov 12 '12 at 18:18
  • I absolutely don't want to get rid of anybody; I'm merely concerned about people tanking the repo because they didn't take the time to learn the tool. I do agree though that the company should have taken pains to get everybody up to speed before making the transition. – Joshua Smith Nov 12 '12 at 18:29
  • 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 Nov 12 '12 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 Nov 13 '12 at 02:22
  • 1
    I have to concur with Moox. Just moving from a workflow in some non-distributed SCM like SVN, CVS or Perforce to an equivalent workflow in Git is a matter of a couple hours of study at most. Also, in my experience the longer the lead time you provide in rolling out a replacement technology, the LESS likely people are to get themselves up to speed on it. Should have had someone come in on Friday and say "we're switching to Git on Monday" – Jherico Mar 24 '13 at 00:42
34

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.

Kryptic
  • 701
  • 5
  • 6
  • 3
    I agree with pretty much all of this, except "You can't expect people to go off and read books". I **fully** expect people to be reading on a regular basis (not just about their SCM either). – Joshua Smith Nov 12 '12 at 18:31
  • 7
    @JoshuaSmith You seem to have high expectations of people. Do you feel disappointed in your peers often? – maple_shaft Nov 12 '12 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. – Joshua Smith Nov 12 '12 at 18:51
  • 1
    @JoshuaSmith You seem like somebody I wouldn't mind working with :) – maple_shaft Nov 12 '12 at 18:59
  • 1
    @JoshuaSmith Don't get me wrong, I'd love to have such expectations and I'm fine being held to them. I'm just basing my assertion on my (albeit, limited) experience introducing Git in a corporate environment. – Kryptic Nov 12 '12 at 20:25
  • 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 Nov 12 '12 at 21:29
  • 3
    I do have kids (one really, #2 is due Thursday). I manage to find time. The comment about reading extends well beyond whatever our SCM is, and doesn't necessarily have to be books. My point was that as devs, our profession demands constant learning. I expect that from myself and my team, even if it comes in tiny bits at a time. – Joshua Smith Nov 12 '12 at 21:35
  • 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 Nov 12 '12 at 21:42
  • @Matsemann Nobody is required by management to read anything (and I'm not the boss). My question was, am I out of line for expecting professional devs to have done it anyway in order to be productive with their tool(s)? – Joshua Smith Nov 12 '12 at 21:58
  • 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 Nov 12 '12 at 23:03
  • @gbjbaanb Fair enough. I haven't opened my mouth yet, so perhaps I'll keep these thoughts to myself. Thanks for the feedback. – Joshua Smith Nov 12 '12 at 23:13
  • @Kyralessa I read developer books on my way to and from work on the train and before bed. I have a daughter... – Simon Whitehead Nov 13 '12 at 07:24
  • 2
    When I was a manager of a development team, I gave my team some books on Ruby, told them to take time to read them and learn ruby (on the clock). There was still a lot of initial resistance, but when they saw a jr. team embrace Ruby and saw a bit of threat, they really got into it. Eventually the whole company embraced the new technology and have become more open in general to new technologies (they are doing a lot of mobile now). – Bill Leeper Nov 13 '12 at 16:54
  • 1
    @BillLeeper you said it right: *on the clock* + *gave them the books*. From the context here it seems the OP is persuaded people around him is supposed to go buy unspecified books to read them on their spare time. – ZJR Nov 16 '12 at 02:30
  • @ZJR: I mentioned in another comment that the company doesn't balk at buying technical books. I don't expect people to be forced to spend their own money for training. Likewise, as a dev I insist on on-the-clock learning time. I asked this question in the first place because I see teammates not taking advantage of freely-available learning materials, on the clock or otherwise. – Joshua Smith Nov 16 '12 at 18:13
  • @JoshuaSmith, I really don't get the apathy some developers have to learning new technology. I have gotten "behind" in my skills before and it really creates problems if you want to change jobs or even improve at the one you have. – Bill Leeper Nov 17 '12 at 17:19
  • 2
    I have more kids than some here had girlfriends, and I do read technical books. However, I also have a big household to manage, two ex-wifes to haggle with, a garden to tend to, an ever-growing stack of non-technical books to read, and lots of other stuff, some fun to do and some not. So I either have to be intrigued by a technical book or I have to need the information it offers very badly in order to spend my precious reading time (mostly 120mins of commuting) with it, rather than with a good novel. And over the years I have learned that most devs are _a lot less eager_ to keep up learning. – sbi Mar 25 '13 at 11:07
  • @Joshua: That said, given your cow-worker's situation, I'd probably have demanded a git book long since and read enough in it to do the basic tasks for my everyday work. Let's not forget, though, that [git is a monster](http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump-jet-and-not-in-a-good-way/) to wrestle down. – sbi Mar 25 '13 at 11:08
12

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.

mattnz
  • 21,315
  • 5
  • 54
  • 83
  • 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 Nov 16 '12 at 02: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 Mar 24 '13 at 00:37
12

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.

samthebrand
  • 368
  • 2
  • 12
  • 27
DeveloperDon
  • 4,958
  • 1
  • 26
  • 53
10

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.

Bill Leeper
  • 4,113
  • 15
  • 20
  • 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 Nov 16 '12 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. – Bill Leeper Nov 17 '12 at 17:21
3

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.

Fred Thomsen
  • 239
  • 2
  • 7
2

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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
1

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.

pgs
  • 126
  • 1
  • 5
  • 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. – Jimmy Hoffa Nov 16 '12 at 03: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 Nov 16 '12 at 03: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? – Jimmy Hoffa Nov 16 '12 at 04: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 Nov 16 '12 at 04: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 – Jimmy Hoffa Nov 16 '12 at 04:18
  • @JimmyHoffa updated. – pgs Nov 16 '12 at 04:47