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?  

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