Git is... tough.
There, I said it. If you look at the most-read pages on Dev.to, git is always in the top 5 every single week. There are a number of reasons for the difficulty curve, but for now I'll just say: it's not just you. Git is a challenge for any developer in the first decade of their career
The good news is that there are many people ready to help you, and the very nature of git means most mistakes can be undone pretty easily.
If you're here, you already know what Git is and how to run git commands from the terminal (note: if I'm wrong and you'd like a guide on these topics let me know in the comments!).
1. Have a safe space to learn
For many people, git is something you learn while working on a solo project. This is a great place to start, but treating git like a 'save point' system where you record straightforward progress means you won't face challenges like merge conflicts and rebasing until you've got your first job.
It can be incredibly stressful trying to learn about git while working on a repository that others rely on. We've all had the experience of messing up a repository such that others can't use it.
To get started learning any concept with git, start with a repository that no one else relies on. You can absolutely do merges and rebases on your repositories!
2. Everyone's commit history looks bad
Just to acknowledge feelings: it's can also be embarrassing to learn in an environment where everyone will see a log of your mistakes!
When Github, the place where most people publish their git repositories, first premiered, the most common feature request was for ways to hide your commit history. This wasn't about security or privacy, engineers were just embarrassed that they had made so many mistakes, either in their code or while using git.
There are reasons to alter the record of what has happened to your repository, essentially rewriting history, and I may cover them in a later guide. But as you get started it's better to start with the commands that functionally alter your code. No one's history looks great, and expecting yourself to be perfect is a terrible way to learn.
3. Keep a brute-force option available
Here's the secret that most often, when I tell it to new developers, they come back in a year to say it was the most valuable advice I ever gave: before you start messing with git commands, copy your whole folder of code to a backup location.
Git can move, manage, restore, and back up your files. And that's great, but if you're totally new to the tool, you should have a backup that's not git.
If you make a copy of a folder that's already been initialized as a Git repository, you'll get a copy of your files in their current state and their git history. The first few times you resolve merge conflicts or run a rebase, it's so nice to know that you have a backup in case things get really messed up.
Similarly, if you are working from a repository that you know has working code and you're struggling to merge your changes, there's nothing stopping you from re-downloading the repository to a new folder, and re-implementing your changes with a copy-paste.
So much git learning happens with stress, it's nice to have some sense of security.
4. Realize that learning git takes time.
The only surefire way to really fail at learning git is to try learning everything right at the start. git is a huge and complex tool. You're not going to master it all right at the outset. And after 10 years in development I can safely say that I haven't used most git commands. I may understand what git prune does but I've never had a need to use it and it (and many, many others) is something I don't need to do my job.
There are some fantastic guides out there, but many of them are not targeted at people new to git.
If you want a comprehensive beginner's guide, a tutorial like this one from IBM is a nice way to get an abstract understanding of beginner and intermediate concepts. If that feels like a bit much, try just searching 'git beginners' on dev.to and starting from there!
Up Next: A basic glossary
I'll publish a guide to basic git terms next week!
Top comments (3)
Nice article. The recommended tutorial looks really helpful. For me, the main hardness of Git is the workflow. When it's fine to commit? What is an optimal way of using branches? And so on... Surprisingly, I can't find any course on Git based on some real project and teaching this. Do you know any such resource? Thank you.
I really don't know a great course on the git 'strategies,' and I clearly should write my next article about this!
I'll give you the short answer now: your git workflow is going to be a reflection of your team's workflow. Even a basic component like branching and merging shouldn't be used if they're not what make sense for your team. If you're working solo, it may not make sense to use branching unless your project is becoming extremely complicated.
Appreciate your response and clarification of some issues. Looking forward to the article.