While version control used to be reserved for big corporate projects, it is very mainstream these days. You can attribute much of that to Git, the software that has nearly displaced other version control. Git works well, it is versatile, and it scales well. It is easy to use as an individual developer or as part of a worldwide team. But Git is also one of those things that people don’t always study, they just sort of “pick it up” as they go. That motivated [Glasskube] to create “The Guide to Git I Never Had.”

If you are ready to click away because you are not a software person, hang on. Git is actually useful for many different kinds of data, and there are a number of hardware projects that use Git in some form. That’s especially true if the project has some code associated with it, but there are projects that consist of PCBs, reverse engineering documentation, or schematics.

Simplistically, Git tracks a bunch of files and lets you rewind in time to answer the question: what did this look like a month ago? Or a year ago? However, the real power lies in producing and merging branches.

For example, you might be working on a product and decided to add feature “A.” Meanwhile, your partner decides to work on feature “B.” No problem. You can each work in your own separate branch and get everything working. You don’t even have to be connected to a server until the very end.

When either of you are ready, you can merge your branch with the main branch. Often, this can be done automatically, but Git knows when it is in over its head and will ask for help. When you are both done merging, both of your changes are “live.” If you do it right, Git can also help answer the question: why did we make that change two years ago? It is surprising how often that’s important.

If you think Git is just for code, we can show you some strange examples. If you don’t fancy reading a blog post to learn Git, would you like to play a game?