When I was learning how to use git a few years ago, all of the tutorials had this picture of these lines, dots, and arrows like a metro map. It didn’t make sense, and don’t worry, this is not one of those tutorials.

If you’ve been searching around the web, I’m sure you’ve seen the images. They look kind of like this:

The problem with these illustrations is that while they make sense to someone using git on the regular, they are absolutely positively confusing to someone learning git for the first time.

I think a better place to start is by explaining what git is not.

Git is not GitHub.

One of the most common misconceptions that I see with inexperienced developers is mistaking git as a shorthand nickname for GitHub. Git is not GitHub.

GitHub is a social cloud platform to contribute code, submit bugs, read about software, and share projects. Experienced developers understand that it includes git as a feature, but if you don’t understand git, you might simply store projects in GitHub repositories without understanding how to use the platform with the git feature. I have seen beginners use GitHub as a cloud library of projects to download and upload, and never use the git feature.

Git is something that can be used without GitHub. It can be used on its own on your desktop or with other cloud repository tools such as GitLab, Azure, JIRA, etc…

Git is not a desktop application.

It is software, but it’s different type of software. Unlike Microsoft Word or Adobe Photoshop, git is not something you can double click an icon and open up the program. However, you can download a variety of tools that will allow you to open something like this — a graphical user interface (GUI) — that helps you visualize what you are doing with the software.

This is important to distinguish because I’ve heard from some people that git is hard to figure out, only to learn later that they were simply using a complicated GUI. When I tell them that they can switch to a different GUI to visualize it differently, it blows their mind.

Imagine it this way, you can use the internet in Firefox, Chrome, Safari, etc… it’s still all the same internet, but you are using a different GUI to interact with it. Git is similar. In fact, you can use git without any GUI using just the command line / terminal.

Git is not a “save” tool.

I’ve heard git described as a way to save code. Say that to any beginner and they’ll give you the side eye like …

“um… can’t we just Ctrl-S save our files?”

Git is a version tool. It allows you to go back in time to find a file as it existed in a previous version, but it does much more than that. Unlike the view history tool in programs like Photoshop, Git doesn’t restrict you to a single timeline. You can create as many timelines as you need — each with its own history that you may travel through at any time. What’s more is that you can merge different histories from different timelines into a new file.

“But, I don’t get it. Why would I ever need that? It sounds like it’s over complicating things for no reason. I don’t make that many mistakes that I would want to go back in time to fix.”

Git is not a personal tool for individuals.

You can and should use it in your personal projects, but the primary audience that benefits from git the most is teams of developers.

This is how it works. When teams of developers work on a project, they want to work on the same folder and files — at the same time. Imagine this scenario without git. Developers might each copy and paste the folder onto their desktop and then start working. But, how would they combine all of the folders back together again? What would happen if one developer wrote code that breaks another piece of code? What if developers overwrite the same code in the same place?

“What about real-time collaboration apps like Google Docs? Why can’t developers use something like that?”

What happens when you want a team of developers to write the same section in 5 different ways at the same time? What happens if you want one developer to test or refactor a breaking new feature, but want the others to work on the original code in the meantime?

Git solves these issues for teams because each team member can work on his own separate timeline history (branch) and then automatically merge with his or her team’s code later.

“Ok, but if each team member has their own branch, remind me why using it on my own would be helpful?”

Git is not just for fixing things.

Git is also helpful for iterating on something that already exists.
Yes, you could copy and paste your folder each time you want to experiment with new tools and open source software that you found, but once you start using git instead, you might like how easy it is to quickly switch between branches and merge into your master project certain things but not other things.

Git is not hard.

You can do this! There are really only a few steps to start using git today.
First, Download a GUI. While I usually use the one built into Visual Studio Code, GitHub Desktop might be easiest for beginners.

1. Create a Repository, Clone a Repository, or Pull an Existing Repository
2. Write Code & Commit with quick message about what you did
3. Push your changes back to the software
4. Create a new Branch and repeat steps 2 and 3
5. Merge your branch to the Master and submit a pull request for the team to review.

Repeat again and again. Eventually you’ll get the hang of it, and wonder what all the fuss was about. Git is pretty cool!