Lately I've seen a lot of new/aspiring developers talk about difficulties learning git. I was confused at first, because there are approximately a zillion git tutorials out there. But then I started really looking at what people were saying AND what all those tutorials contain. The problem is most tutorials start out with "here are a ton of git commands to memorize", and this is not where people are having problems. People are having problems with "what is git, why should I learn it, and what does it look like to use it in a real-life project?", and those questions are largely not answered in all those millions of tutorials. So at the risk of redundancy, I'm going to attempt to address these questions in Yet Another Article About Git.
First, I want to make it clear that
This is the short version of the answer to "why should I learn it?".
The long answer is all the stuff about version control and tracking changes and how much easier it makes large projects with multiple people and why git is easier than the alternatives (no, git is not the only version control software, yes, I have used others including CVS, Subversion, and Perforce because I'm old enough that git didn't exist when I got started, and I still prefer git, as do many others judging from the overwhelming popularity of it and the incredible speed with which it took over), but when you're just getting started you're probably not worrying about any of that. The thing to focus on is that this is something that you need to know if you want to be a programmer. Git's extensive use by other programmers means that you are going to look really foolish in an interview or even a conversation with another programmer if you say you've been programming for X number of years and you don't know git, or if you're a CS student who thinks they're going to get a job out of school but "doesn't want to learn git" (which is an actual thing that one of our interns heard in recent years)... Just learn git, OK?
GitHub is by far the most popular place to store git repositories online, on someone else's server. It has a lot of other cool features, but for the purposes of learning git, that's all you really need to know. It is not the only place to store git repositories (GitLab and Atlassian's Bitbucket are the other popular commercial options, but you can also set up your own server, which many companies do), and it's not actually necessary to start using git. You can use git on your computer and it will track all those lovely changes and branches all on its own. The reason people use GitHub/GitLab/Bitbucket is primarily to 1. create an off-site back-up of their work and 2. share their files so others can contribute to their project, or critique it, or just plain use it. Git itself, running on your computer, needs to be configured if you want to back-up or share your work. This is what people mean when they talk about remotes. You will need to tell git where the files should go when you push (the command to get your changes saved on the server), or where they should come from when you pull (the command to retrieve changes from the server and save them on your local machine). Luckily, this setup step usually only needs to be done once, and then you are good. So you can do it and forget all about it until you get a new computer and/or job.
The final thing I want to address about git is that, while git can get really, really complicated, and it can be intimidating to go to one of those tutorials and see huge lists of commands, the reality is that the vast majority of programmers are not actually git wizards, and they use a tiny fraction of all the available commands. As usual, XKCD has addressed this with a great comic:
So please, don't get intimidated by the enormity of the tool. 97% of the time the only things you will be doing are checking the status of your code, pulling, pushing, adding, committing, and branching. 6 commands. Really. Another 2 percent of the time you'll be creating pull requests (asking someone else to bring the changes you made in your branch of a project into the main branch of the project, which is usually done in a GUI anyway) and/or merging (doing the actual bringing in of changes made in one branch into another branch). The remaining 1 percent of the time, when you need to roll back a commit or discard your work before committing or start a brand new project (because in the real world projects are big long things, so you're not starting a new one every week) or when some other unusual situation comes up, you can use Google or a git cheat sheet or one of those cool mugs. To borrow Don Norman's concept, *the knowledge exists in the world; you do NOT need to keep it in your head. * The amazingly useful site Oh shit, git has the answers to how to get yourself out of many common messes. And of course, like the comic says, if all else fails save your work off elsewhere, delete the files on your local machine, and download a new copy from the server.
I'm a lead dev, I'm in charge of code reviews and keeping the codebase clean, all these repos that hold the code for our apps are my babies that I protect with my (professional) life, so I use git every day... But the above 100% applies to me. I've taken git classes that taught the more advanced features, I've read the docs... And I still have to Google them any time I actually need them, because it's so rare that I can't remember the commands off-hand. I don't even use merge from the command line anymore because we have our own GitLab instance and I like the GUI better due to the way it shows changes. I also start new projects from the GUI because at the same time I like to add a description and the project icon and set permissions and protect branches and......., so I also don't git init anymore (just a nice simple git clone after it's all set up). Since our team is so small I prefer to keep all the history from merging, so I don't even bother with rebasing.
I hope this simple overview and explanation will bring git down to earth for new developers. It's something you need to know, but it really isn't all that scary in practice. You can do it! I am planning to write another post soon about some real-world scenarios and the commands used, as well as explaining a couple of different branching models (which are essentially a way to organize/regulate how you use git within a group of developers), since this is another git area that seems to be under-explained. If you know of any other areas that are under-explained, please let me know! Git is such a ubiquitous tool, nobody should need to struggle learning or understanding it.