Ask HN: How to introduce git to colleagues? | Hacker News Reader

Ask HN: How to introduce git to colleagues?

1 pointdutchbrit3 comments

Hi HN,

2 weeks ago I started a new job at a small web development agency. To my horror, they don't use any form of version control.

My boss asked me to introduce git to my colleagues. I've never had the pleasure of training people, and I'm really excited. I'm also terrified. I have no clue where to start. Nobody in my team has any experience with git, besides finding code on Github through Google...

I don't like the idea of being the annoying new colleague that disrupts everyones workflow which they are comfortable with, although they all agree it's a good idea & I'm 100% sure that they will benefit from this in the long run.

My biggest fear is that it will take a while until they'll have a full grip on git. I want to implement the following model: http://nvie.com/posts/a-successful-git-branching-model/

I know that I have to start with baby steps here, does anyone else have experience introducing git into an organisation? Do you have any pointers and/or tips? I'm personally quite hectic when trying to explain certain things so I want to make sure I can teach them in a nicely structured manner.

Thanks in advance, looking forward to reading your comments.

Hello,

As part of a school project in Software Engineering, I had to help my team understand and use Git.

Making them commit their work is fairly simple, that they can do with little guidance. The problems occour when they have merge conflicts.

We all worked in the same branch (stupid, I know, I didn't know better then) which created a lot of merge conflicts. The team had some issues fixing that in the beginning, but tools like SmartGit / SourceTree made their experience better.

Based on my limited experiences, I would recommend the following:

1 - Start with the simple parts, checking out code and committing.

2 - Then, introduce the concept of feature branches. Do not go all the way that Git flow does in the beginning, keep it simple for now, and then, when more of the organisation understands Git, you can go over to the full Git flow model. Ensure that people focus their branches, and let them only live for a short amount of time. This so that work can be synced up regularily.

3 - What can go wrong? Show them a somewhat advanced merge conflict and how you solved it.

4 - Try to introduce it to them using a GUI client (SourceTree / SmartGit) if they're not into the Command line. It can make adoption easier and less painful.

Good luck!

With git, one doesn't realize its importance, unless they use it. So I would suggest first use it for smaller codebase like some utility libraries or something. This will give them real exposure to git.

Don't try git with repos where lots of people are committing very regularly. Once good number of people have got their hands-on with smaller repo, then shift larger projects to git. Also then you can convince everyone with the model u want to implement.

This way you should be able to start shifting major repositories in like 2 months.

I would start off with a single wiki page, that is dead-simple with nothing but instructions that are commands

To submit: type this To fetch: type this To resolve: type this

etc.

The internal workings of Git are way too messy to introduce all in one go

Reply on news.ycombinator.com