Our team has just embarked on “Lunch and Learn”s. (A time for the team to get together over lunch and learn about something new). For the first one, my colleague Tom and I volunteered to teach the team to use Git…
Our development team was previously all located in the UK, but we are about to go distributed with teams in both India and the UK.
We are working on a .Net stack so of course, (shudder) we are using TFS. Due to the team changing to be distributed we are having to look at more distributed friendly source control systems, and thankfully Git is on the table.
Now I am definitely still a relatively Git noob. I was introduced to it on my last project, and we used it pretty extensively for a year. Now, I hate working without it. I think it’s changed the way that I work, so it’s hard to go back to the TFS dictated way of working.
We are planning on doing two sessions. This first one being just on the very very basics for someone who has never used Git or another distributed Source Control System. Literally, this is how you get stuff out, change stuff, and get it back in. Hoping nothing goes wrong.
Anyway, we bought pizza for everyone, to keep them happy, and quiet.
The first part of the session we did in a meeting room with whiteboards. Tom talked about some of the high level concepts of distributed source control systems. Along with a brief description of how it differs from TFS ***. Tom also talked through some of the key terminology that people would need to get used to. i.e. working trees, remote repository, the index/staging etc.
My job was guiding the team through the workflow that we’ll be encouraging. I chose to first explain the workflow we would be using, away from the computers using pictures, to ensure that everyone listened and understand why they were doing each command. I was worried that everyone would be distracted and race ahead without considering what they were doing with a shiny new toy in front of them.
Now I know that there are two different schools of thought out there. Local branches or committing on master. I was taught to use Git using local branches so that’s what I’m more comfortable teaching. Plus it means that your master branch is always clean, gives you a bit more of a safety net, but also it forces you to change the way that you are working, not just doing the same workflow you did in TFS or SVN. It forces you to start getting used to the concepts that really make Git powerful.
It went surprisingly well. I was expecting a lot of fear and resistance, but actually it create a great new energy around the team. Everyone rushed back to the computers to try out what we had been showing them, and it started a lot of good discussions.
See the following post for my detailed description and walkthrough of a sample workflow with Git.
*** to keep the “but in TFS…..” To a minimum, I asked everyone to keep an open mind and if anyone who wasn’t presenting brought up TFS they’d have to do star jumps in the corner.