Time warp: back to the past

Back in 2010 I came into contact with git for the first time. It was introduced to me by a colleague who used it for his projects and he was confident it would be a good idea to use it across the whole development team. My colleague was one of these guys who always knew when something is worth the effort to learn it and he was the guy I was looking up to. He built the tools and systems which enabled us to deliver our data records to our clients. He was the smart guy with the nerdy hairdress.

Because he was the developer and later maintainer of some really cool stuff – one system provided extensive data of german soccer matches – today it would be called “Microservice” – he had the respect of other developers and also some influence to our technical lead. So git was open for evaluation and used for a major project which required four to five developers to work on this over half a year.
We had no theoretical introduction to the concepts of git (or any other distributed source code management) and no one had time to become an expert, furthermore the project was already behind schedule. We regularly struggled with the concepts of git: daily merge conflicts, someone force-pushed to master and rewrote history and now and then mysterious data loss which caused headaches to all of us.
So my colleague was asked to give advice but educating others how to use git also prevented him from getting his work done.

Quickly, some guidelines where defined, which enabled us to collaborate and avoid conflicts. I just list them here for sentimental reasons, not to make them appear to be the most brilliant guidelines ever written.

  1. pull before you start your work (in case of merge conflict, merge together with the author of the other changes)
  2. push before you go home
  3. use a command line interpreter because the plugin for Eclipse is crap
  4. communicate with others if you think you might break their changes or you know they’re working on the same files
  5. never force push (again)

As you can see, there is no word about checkouts, branching or merging. We integrated everything on master. Back in the day it was a lack of knowledge how to use feature branches properly. That came later. But for the scope of this project, we just used the master branch.

Time warp: back to the not so distant past

When I picked up my latest job, I came into a team of developers who merely heard of git. The situation was somewhat similar to the one in 2010, but in the meantime I learned to use and love git. One of them was using git in a project, which should become my first project, so we collaborated and he should become my first adopter. In fact it was pretty easy to convince him to use git from now to eternity.

But I faced some resistance when I demanded others, who were required to contribute to my project, to use git. Especially those who used Subversion for a long time. This was made clear to me when I was asked: “I don’t understand why we can’t just use svn for this?”
I assume this was caused by the amont of steps git requires you to do, and if I try to take the perspective of my older svn-loving friends I can understand this:

  1. I have to clone the project – no problem so far.
  2. Telling git my name and my e-mail? Are you crazy?
  3. I have to checkout another branch? Why is that so? The source code is exactly in front of me? Why is there a development branch I have to use? But okay, you’re the guy, I do as you command.
  4. I have to create my own branch and switch to it? Why is that so? I did that a second ago? Well, just did it. What’s next?
  5. Ah cool, I can do my stuff. Cool, I’ll do my stuff. Eh wait – where are you going? Leaving me alone with this shenanigans? Ah okay, you’ll come back as soon as I run into any trouble. Ah, you’ll come back as soon as I want to publish my changes? Don’t you think I can do that on my own, kid?
  6. Ah cool, there you’re again! I just can’t commit my changes. Something seems to be broken. Ah, you’re saying I have to add them first? That requires an extra step? Okay. Seems fine to me now.
  7. Can you please come back again? I commited my changes but apparently they’re not available to others. Ah, I have to publish my changes explicitly? Wait! What do you mean: “Merge or rebase your changes before pushing. And maybe do some interactive rebase here and there and ammend this commit.”?
  8. This feels … not … right.

Okay, I’m kidding. I know that there are some obstacles when you’re working with git for the first time. When I made first contact with git, I didn’t know what I was doing at all. But I think the problem is not the human, it’s the work environment.
When I started this job, there was a lot of pressure to all of us to get things done. And a new tool which costs you a lot of time before you earn the benefits is not welcome. Of course I can not claim that there’s always pressure by a closing deadline. But in an unhealthy work environment there are other factors which prevents you from learning new tools and techniques.

With unhealtly I mean: there’s someone under pressure, it’s maybe not always the same person, but if it’s a small team and you never have the opportunity to get all people together to review and evaluate some new stuff, change is always an additional burden. Also the team may consist of too similar personalities which might reduce the effort to explore something new and stick to what is already proven useful. In the case of this team, there’s a core of developers who are really loyal and are with the company for many years. On the other hand, there’s a heavy fluctuation of new members who eventually leave after some months. Such a fluctuation impacts the performance of the team immensely and leads to cynical thinking of some individuals who then are only interested in getting their work done and not caring about the opportunities other techniques come with.

Make others love the idea, not the tool

So we had to come up with a plan to fight these struggles, in particular to improve the skills and knowledge about git so that each developer has a sufficient knowledge and can operate on his own. Luckily, a way of spreading the knowledge was the project I mentioned earlier. It is one of our major projects and it requires constant development. And since it is too big to be handled by my colleague and myself, others have to contribute from time to time, consequently they have to use git because it is a git project.

Despite we are not using pair programming on a regular basis, we already know that it is a great way to share knowledge and it is always an opportunity to learn. It’s much less of a rushed instructional session and more of a dialogue which enables the teaching person to give insight into the advantages and concepts of git. It is really educational for people when they realize that it’s actually quite hard to lose data with git.

Another action to promote collaboration and change in mindset was to remove our old code repository. We used a minor provider where we stored our repositories. We moved to Bitbucket, which is slightly more expensive, but the benefits outweigh the costs: code reviews, forks and pull requests, issue tracking, better user interface and activity streams to name a few. In other words: using the source code management became much more fun and improved the developer experience.

So legacy projects will be migrated from svn to git once they are touched and then pushed to Bitbucket. We also committed to a policy that new projects will be under git. It is a slow process and to monitor the progress we have to sit together or have a talk while cooking coffee in the kitchen, since we’re not pairing for programming. But my impression is this: it’s constantly rewarding to all of us.