Git for System Administrators

Most people who know about Git think of it as a repository for software projects. It’s actually more than that. It’s valuable with any kind of files, especially text files, that get periodic updates. Git is a valuable resource not just for programmers, but for system administrators.

In addition to source code, a Git repository can hold configuration files, scripts, and text documentation.

Benefits to Sysadmins

Using a repository makes the administrator’s life easier in many ways.

• It keeps a history of changes, making it easier to fix problems. If a new version of a file breaks the system, getting the previous one back is easy. If something is misbehaving, comparing the latest version with the one before helps to isolate the problem.
• Tracking changes is a good discipline. Each newly committed version should include a brief comment explaining the reason for the change. Sometimes it’s necessary to go back several versions and figure out why a change was made.
• A shared repository makes it easier for people to collaborate. Git includes features to prevent inadvertent overwriting of one another’s work.
• Git supports branches. You can try something out in a private branch and merge it into the mainstream if it works.
• Configurations and scripts can become part of the DevOps cycle. They can undergo automated testing each time they’re committed, along with application code.

Only files which people work on should be in the repository. Ones which software creates from them, such as generated documentation and binary files, shouldn’t be. Git works best with plain text files, where it stores differences between one version and the next very efficiently. You can use it for images and binaries, but the repository could become huge over time. Whatever approach you choose, never put highly confidential information, such as passwords and keys, into a Git repository.

The whole history, including changes committed by others, is in your repository. You can see what changes others made, as well as your own.

A Quick Introduction to Git

Git is free, open-source software for creating and maintaining distributed file repositories. It’s the invention of Linus Torvalds, who is best known for creating Linux. The word “distributed” is important. Unlike older version control software, such as CVS and Subversion, each participant has a personal repository. People on a team make changes locally, then push them to the team’s central repository. This lets them work offline and not give changes to others until they’re ready.

The central repository can be public or private. GitHub is the biggest and best known, but it’s not mandatory. Anyone can create a repository on a server.

You can use Git from the command line or from a GUI client. The client can be standalone or part of a larger application. Many options are available.

Unless you’re working from an existing repository, the first step is to create one on your own machine. It will be associated with a directory where you do your work. You can add a public repository later after you’re sure it’s a worthwhile project. You should create a .gitignore file to indicate types of files that don’t belong there.

Add the Files You Need

Shot of a group of young people using computers during a late night in a modern office.

At first, it’s empty, and you have to add files to it. The way Git handles adding and committing files is different from most source control systems, and it confuses everyone at first. When you create a file, it doesn’t automatically go into the repository. Git uses a staging area between your working files and the repository. You first have to stage your files. Then, when you’re ready, you commit them.

When you’re ready to share the project, or if you just want the extra safety of a copy that isn’t on your machine, you can create a matching repository on the central Git server. You then add a connection from your repository to the remote one and push your current state to it. The changes to your own repository don’t automatically sync to the remote when you commit them; you have to push them. This lets you wait till you’re sure the changes are ready to share.

Other users can now clone the shared repository. Cloning creates a copy on their machines. They can then pull changes from it and see everything you’ve committed. They can commit their own changes and push them. You can also give some users read-only access, letting them clone and pull but not push.

Types of Repositories

There are many ways to set up a remote.

• GitHub and GitLab offer private repositories to paying customers.
• You can set up and run a Git server on your own machine or a virtual cloud-based machine.
• Cloud development services provide their own Git repositories, such as Azure Repos. It’s free for teams of up to five users and allows unlimited private repositories.

All implementations provide the same features, and you can move a Git repo from one place to another whenever you like.

Types of Clients

The choice of clients for Git is even bigger. The command line gives the full power of the software, but it’s complicated and takes some time to learn well. Any self-respecting administrator should be up to the challenge. For occasional use, though, there are alternatives which are easier to use.

Various GUI applications are available. Not all of them allow full access to all Git functionality. In addition, Git clients are often built into developer software. Emacs includes some Git support, but many people find that add-ons, such as Magit, allow easier use. IDEs often include a client.

For serious use, the command line is best. It provides all the functionality and doesn’t disguise any of the steps.

A Valuable Tool

Tracking changes is important in both program source files and administration-related files. The reasons are similar in both cases: better collaboration, ability to recover from mistakes, and access to a project’s history. The DevOps paradigm makes administrators part of the team that updates, tests, and releases projects, and it works best if everyone uses the same tools. Using Git lets administrators manage change better.

AgileDevOps removes silos between IT operations and development teams, bridging the gap from traditional infrastructure deployment process to modern cloud DevOps. To find out how we can help, request a free quote today.