FeedTeach your team some Git! Experiences of a team lead who cares.
Teaching yourself using Git is a long process, full of obstacles - just as teaching yourself anything else more complex than cooking pancakes. But it’s not enough to use Git at home, hacking some console applications for a couple of GitHub stalkers: you should use some great version-control system at your workplace. Our dev team moved to Git not so long time ago, and it was quite a difficult move.
So if your team is still using SVN, or if you’re tired of Mercurial (which seemed fine to me, but Git is greater), please start using Git as soon as possible, using my pieces of advice as an advice. I won’t be saying much about whether Git is the right choice or something and I’d like to escape from such discussions. Also, Git is not for cowards, so decide quickly and proceed - or not.
0. You should use GitHub. GitHub is a necessary part of introducing Git to young fellas. It visualizes everything in a simple software-agnostic way. Don’t try to show your team some fancy Git client, they won’t understand them. GitHub is understandable. You can commit/push and see all the changes on the server highlighted using cute colors. You can review everyone else’s changes just like you review their drunk photos on Facebook. And yes, make the GitHub repository the main one. You don’t need to be truly decentralized yet.
1. You should know everything about Git. Okay, that’s an impossible task, especially if you’ve never tried Git with a team. So you’re going to fake it. Everything you need at the very first stage is:
git status. Every time I’m uncertain what to do next, I just type this command in terminal. Everything is illuminated now! I see “untracked files” and…git add filename.txt. This moves from “untracked” to “to be commited”. Try out “git status” again if you don’t believe me.- Now when there is something to be commited:
git commit -m ‘some cool commit message, whatever’.
And also a little bit about this distributed yada-yada:
git pullgets everything from server - the GitHub server in your case - to you. Do this as often as possible or you’ll be screwed (seriously). If it says something about “conflict”, open files it mentioned, resolve conflicts (“remove unwanted lines from the conflicted files”) and commit (do you still remember how?).git pushputs everything from you to server. Do it only after successfulgit pull. Yeah, if it fails, you probably forgot aboutgit pull.
Don’t try to understand branches yet, even if you do - don’t try explaining them to anyone. They are not SVN branches, neither they are Mercurial branches, in case you’re wondering.
2. You should be a responsible adult. In my own humble opinion, the very task of a lead developer is to understand everything and solve every problem. There is nothing humiliating, it’s cool - think of yourself as House MD (or Sherlock Holmes). So from this point if anyone comes to you with a problem, you go and solve this problem. Not “tell how to solve” or “send a link to letmegooglethatforyou”, you solve it by typing using your left and right hands. That’s the point where every other innovator fails. By the way, if you’re a “lead developer” and you can’t (or don’t want) solve these poor tiny problems with Git, you should fire yourself.
3. Read all changes. There definitely will be someone clever enough to do “git push -f” and delete someone else’s work. In my own experience, one guy did exactly that and no one noticed for two weeks, until someone had started writing code for one of my “done” tasks again and I had a feeling that something is wrong. Fortunately, GitHub keeps logs of all pushes and pulls and I keep all my old branches on the local machine.
4. Don’t distract to useless things. There is no point in cargo cults. Noone knows what a branch is, noone knows what “cherry-picking” is, and noone on your team understands mysterious “rebase”. They are going to lie about it, but the truth is - they can’t use it. You should forbid them. git status, git add, git commit, git push and git pull are all the commands they use now.
5. Don’t distract to useless software. Don’t use any Git clients yourself. Git in CLI is awesome. It’s complicated - deal with it. You should also tell your people not to use them, but they won’t listen. However, they’re going to have a problem one day, you’ll open a terminal and type some commands, solve everything and they will be impressed. And again, you really need GitHub to visualize everything. That’s the only third-party software you need at this stage.
6. Understand branches. Branches are simple after you got used to commits and pushes. You’ve actually used two branches already: master and origin/master. Now try using a very personal branch for yourself: git checkout -b myverybranch. Show it to your colleagues as soon as you figure out how to push it to the GitHub repository. They probably won’t envy much, so you’re going to ask them politely to create theirs. Personal branches are stupid, but they are a great place to start.
7. Understand merging. Let’s assume you’re on myverybranch. git merge master will update your repository to the newest version of master while keeping your yet private changes. If you feel complete, git checkout master && git merge myverybranch merges myverybranch to master back, and your private changes become public. Don’t forget to return to this branch or to create new one before committing anything else.
8. Get over the merge conflict fear. That’s the thing everyone should do on your team, or the work will be split between branches nobody wants to merge. Someone is definitely going to use CRLF, and these are going to break your merges until you explain line breaking to them. But it’s not that horrible, so tell everyone: if there is a conflict, just open all the conflicting files and resolve it, don’t bitch about it. By the way, if you don’t test your software automatically, you are screwed.
8. You should really know everything about Git. You can start with listening to Linus himself (he is awesome) and reading Avery’s comparative explanation of branches (he is cool). Also try terrible things, like rebase and cherry-pick, understand why you shouldn’t do it for the next month and you’re cool enough.
9. Understand branching models. If your colleagues are smart, some of them will have several personal branches for different tasks. If they are very smart, some of these branches will have meaningful names based on tasks they carry. That’s the only branching model you need now, keep up the good work!
10. Use deadline as an opportunity. Of course, you should not start learning git just before a deadline, but deadline will come one day - and that’s awesome! Deadline is a great opportunity to learn. I’ve understood Chef in seconds because of a deadline. Our team understood how to commit small changes very often during a deadline hurry. Deadlines are awesome for learning, just try not to panic for at least 5 minutes per hour. If you just stop using cool things like git on deadline, everything you learn is how to lose everything you’ve built. Pity.
If you liked the post, please try pressing “+1” or something like that. I’m a very underconfident lead developer for two years, but I hope I can be helpful to other ones.
Please send your comments, ideas, rants and job offers at v.golev@gmail.com.
Made with Nginx, Jekyll, Git, EC2 and Emacs.
Regarding all the advertising and readability money-related stuff: I'm sorry. I'm really interested in whether one can make money by showing ads in his blog. Seems like I can't. If someone is really annoyed by adwords, drop me a line, I'll reconsider.