What can I do for developers who can't learn Git? [closed]

Question

Context

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.

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

GUI

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.

Branches

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.

Answer 5

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.

Answer 6

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:

• OneFlow
• Feature branch workflow
• Centralized workflow

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

Answer 7

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

Answer 8

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.

Answer 9

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

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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.

Answer 17

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.