Recently I stumbled on a tutorial named Learn git in 30 minutes . While there is nothing wrong with that tutorial, it’s actually pretty accurate, and clear and easy to follow – thumbs up to the author about the writing – I have great concerns about how should we learn Git.
Git is not that easy.
Don’t get me wrong, Git is a great tool, perhaps the greatest developers’ tool since C language. Where I work for, we switched from Team Foundation Server to Git two years and a half ago, and I’ve never looked back – Git does things right where TFS does wrong. It really helped my life, as a developer, easier. But it’s only when you know it enough. It can be a nightmare, when something goes wrong (or precisely, when you use it wrong).
And in a collaborative environment when you work in parallel with others on different branches, where merges are inevitable, something will always go wrong .
Merge conflicts, missing commits, rewritten history, etc. all kinds of nightmare can happen in Git. How to prevent those from happening, and more importantly, how to fix when those happens? I was the first one in my team to screwed our repository, and while I tried to fix my mistake, I made it worse. I’ve learned a lot since that day, and that’s something I want to share with you today:
- There are two essential concepts in Git: commit and branch . Try to understand what a commit is, what does a commit hash mean, what is its parent commit and its children commits.
Try to understand what is a branch – what will happen when you check out a branch. Try to understand a branch tree – how does your branch relate to its remote one, and how does it relate to other branches.
Branch tree is a reason I always recommend Git beginners to start with a Git client (And in those clients, I always recommend Git Extensions , as the client to beat). With the visualization, you can quickly grasp the idea how branches work in Git.
- Try to understand what is a merge is – how can it result in merge conflicts . Learn how to deal with conflicts – by using a good merge tool, likeBeyond Compare.
- Try to understand the arguably most powerful and scary feature of Git – rewrite history. Know what a rebase is – and the difference between a rebase and a pull with rebase, and when you should use a pull with rebase . What does it do when you do a force push and why you should not do it, and when you need to do it. Learn how to disable force push in your repository, if it’s not already.
Learn that a Git commit is immutable and how can you get back a missing commit by git reflog . Understand what does amend commit do, and when should you use it.
- Have someone really good at Git to cover you up. This is very important, due to nature of Git, while it’s easy to clean a mess, it also easy to make a bigger mess . There are ways to screw up entirely your repository, to the point you just can’t fix it (like you mess up with a public branch and nobody has an up-to-date, healthy branch to push back, and your backups are simply not recent). When you do something wrong, ask for help, don’t try to fix it yourself when you are clueless about how to fix it.
If you simply have no one to back you up, try to practice on your own private repository first – it’s time to learn about fork.
In conclusion, the tutorial is a very nice write up – read it. But do not stop there, not with the illusion of you can use Git. Like other tools, it takes time to master Git – days, if not weeks to fully understand the concepts. Once you master it, you can (and you should) spend more time on thinking and writing code and solving code problems, not struggling around and sweating solving Git problems.
Use Git with confident. And Save the day!
Shameless plug : I happen to be writing a book about Git: Git in easy steps, with examples in Git Extensions. Check it out at Leanpub .