Git has become a must-know tool these days. Not only for programmers, but for any would be dev/sys/sec ops types. With the rise of configuration management and infrastructure as code, Git is no longer optional for someone in my line of work.
So What Is Git?
Git is a version control system. Git at its core keeps track of changes. It creates versions of files and allows us to compare versions and see what has changed between them. It also allows for a systematic way to review change history and revert to older versions. It lets us clone other people’s files(repositories), modify them on our own, and later commit the changes we made. These are the big features of Git.
History of Git
The original version control system was SCCS Source Code Control System and was used primarily on the UNIX OS. Next came RCS Revision Control System this was the first cross platform VCS. The next big VCS was Apache Subversion(SVN). Its uniqueness was that it was not just tracking files. Subversion was watching the files in a directory taking snapshots of directories. Transactions committed the entire set of changes to a directory at one time. Finally, Bitkeeper was the most commonly used VCS in the years preceding the creation of Git. The community edition was the main VCS for the Linux kernel. In 2005, Git was created, many say, because Bitkeeper discontinued the community edition. Git was created in 2005 as an open source project and is the most successfull VCS of all time.
Distributed Version Control
Git is a distributed version control system as an alternative to traditional VCS which had one central repo for tracking versions of files. Distributed version control tracks changes as their own entity and can be applied to multiple repositories. There is not one master repository that all other repositories are behind. There can be multiple repositories with multiple change sets. For example:
Repository 1: A, B
Repository 2: A, B, C
Repository 3: A, B, C, D
Repository 2 and 3 are not “behind” repository 1 the way you may think. Distributed repositories allow us to update each repository individually apart from the other. For example, we could update repository 1 with D from repository 3 without issue. But be aware that, by convention, people often have a master repository which everyone commits to, even if it’s not required by Git.
Benefits of distributed version control include no single point of failure, you don’t have to have network access, you can work independently and then later submit changes for review. Git allows the idea of forking a repository. All repositories are considered equal.
How to Install
This link provides instructions on how to install Git on Windows, OSX or Linux. Note: when installing on Windows make sure to choose “Checkout Windows-style, commit Unix-style line endings” when the installer ask about how to deal with line ending conversions.
Initial Git configuration:
apply to every user of the computer
apply to the current user
apply only to the local repository
The syntax for configuration is git config followed by a flag that identifies at which level you want to set the configuration.
git config --system
git config --global
Keep in mind that the settings at the lowest level take priority. For example, settings at the user level take priority over the system level setting.
Config File Locations
Location can be found on Windows machines with
More easily on *nix based systems, the system configuration is at /etc/gitconfig, the user level is at ~/.gitconfig and the project location is at project/.git/config.
Note how after Git config we are setting the level of configuration using the –global flags. Also note how the commands are updating the configuration file. The green arrows point to the command first, then to the locations in the configuration file where the modification was made. We could actually edit ~/.gitconfig for example with [user]/name instead of using –global user.name.
Git Help (Not a Pun)
will list the most common Git commands.
will give you detailed help on the command.
Git 101 coming soon!