Version control is an important tool for anyone looking to track their changes these days. It’s especially helpful for programmers, sysadmins, and site reliability engineers (SREs) alike. The promise of recovering from mistakes to a known good state is a huge win and a touch friendlier than the previous strategy of adding .old to a copied file.
But learning Git is often oversimplified by well-meaning peers telling everyone to “get into open source.” Before you know it, someone asks for a pull request or merge request where you rebase from upstream before they can merge from your remote—and be sure to remove merge commits. Whatever well-working contribution you want to give back to an open source project feels much further from being added when you look at all these words you don’t know. …
Knowing where you are in a Git project starts with thinking of a tree. All Git projects have a root, similar to the idea of a filesystem’s root directory. All commits branch off from that root. In this way, a branch is only a pointer to a commit. By convention, master is the default name for the default branch in your root directory.
Since Git is a distributed version control system, where the same codebase is distributed to multiple locations, people often use the term “repository” as a way of talking about all copies of the same project.
Read more at OpenSource.com
