Git, Github, and Version Control: What Apple Admins Need to Know

Chances are your IT team has a library of shared files that you all use and, more importantly, that you all edit. That library might include shell scripts you deploy to new Mac computers that enter the organization. It might contain a .logrc file your team shares to standardize log output. Maybe there’s a text document outlining your ever-evolving ticket escalation workflow.

Whatever the specific content of those files, you need a single canonical version of each one that everyone can share. But—whether you realize it or not—you also need a record of the changes that have been made to each file, letting you track not only the changes themselves but also who made them and when. In other words, you need a version-control system. And while there are competitors out there, the most common such system is Git.

Unfortunately, Git—and its most popular incarnation, GitHub—have a somewhat intimidating reputation among the uninitiated. That reputation isn’t entirely deserved. If you’re among the Git-curious, here’s a quick overview of how version control in general and Git in particular work and how you can get started using both. If your organization already uses a different but similar solution, don’t worry; these same concepts still apply.

Why You Should Use Git for Version Control

If you’re collaborating with other people on some kind of text-based project, version-control systems such as Git offer several specific advantages. 

The first advantage, obviously, is version control itself: Git’s core functionality is to let you track changes to code or text over time. This is especially valuable if you maintain complex collections of files, with multiple dependencies and configurations. Using version control, you can easily roll back changes if something goes wrong or test new features without affecting the stability of the canonical version.

But that’s not all Git can provide. It also supports collaboration: With Git, you can share code, track changes, work on updates, and manage conflicts between team members, unlocking a more streamlined and efficient development process.

Git also provides integration and automation: It can integrate with the most popular Integrated Development Environments (IDEs) for Mac and other platforms, so you can use it as your default file system in the most popular development apps, including Xcode, Visual Studio Code, BBEdit, Pycharm, Vim, and Nova. GitHub and other Git platforms also offer automations that help you test scripts, build packages, or deploy code, saving you time and reducing the risk of errors. 

Even if you're working solo, version-control platforms such as GitHub can still be handy. They give you a source of truth that isn’t dependent on your file-naming conventions. It also gives you a reliable system for backups and recovery. That means you can restore your work after a system failure or back out of dead ends in writing code or other content.

One softer side-benefit of using Git-based version control: You can connect to communities of other developers and IT professionals, who can provide feedback, answer questions, and share resources. (For example, there’s a GitHub community specifically for Mac admins.)

Of course, you don’t need version control for every file your team shares. Maybe your team maintains a list of the best local restaurants. It gets updated a lot, but it isn’t exactly critical that you can trace the provenance of every change made to it. In that case, a simple file-sharing system (such as Google Docs) may be sufficient. But if you do need granular visibility into who made which changes and when, then you need something like Git. 

Git and Version Control: A Quick Introduction

To understand Git and version control, it helps to understand some of its specialized lingo.

Git: A distributed version control system that allows multiple team members to work on the same files simultaneously. Where’d the name come from? When Linus Torvalds created the initial commit for the Git code, he said that the name “can mean anything, depending on your mood,” including: 

• stupid, contemptible, despicable;
• simple;
• a random three-letter combination that is pronounceable and not used by any common UNIX command;
• acronym for "global information tracker."

Repository: Commonly referred to as a “repo,” a collection of files and directories that make up a project, along with the history of changes to those files. A project can consist of a single file or multiple related files.

Commit: A snapshot of changes made to a repo at a particular point in time. Commits are used to track the history of changes made to a project. A commit can track anything from complete rewrites of multiple files to removing a single character from just one of them. 

This snapshot metaphor is the most important difference between Git and other version-control systems: Other systems keep track of changes to a file in comparison to a base version (commonly referred to as delta-based version control). Git, by contrast, stores a snapshot of your files every time you commit a change. 

Branch: A separate version of a repo that allows each team member to work on their own changes independently without affecting the main codebase. Branches can then be merged back into the main branch when changes are complete. This is one of Git’s most important features. 

A Git branch relates to the original source material the same way a tree branch relies on the tree it grows from; the branch remains part of the original. A fork, by contrast, is a completely separate copy of the original repo. 

Fork: A new repo based on an existing one. This allows individual collaborators to create their own versions of a project and make changes independently. One common mistake that beginners make is forking a public repo, not knowing that, when a public repo is forked, that fork is also public and cannot be made private. Instead, you should clone the repo and copy the cloned contents to a new directory. From there, you can start a whole new private repo. 

Clone: A local copy of a repo on your computer. Cloning allows team members to collaborate without affecting the original repo. Similar to fork, except that a clone retains a link to the original repo, which you can then sync back to.

Merge: The act of rejoining two forks of a repo. On Github, this happens visually: When a branch is merged, any changes made in that branch are integrated into the main branch, and you can see exactly what's been removed, added, or changed in a given file or set of files. 

Push: An upload of changes from a local repo to a remote one.

Pull: A download of changes from a remote repo to a local one. Developers use pulls to keep their local repos up to date with the latest changes made by other team members. 

Pull request: The proposal of changes to a repo, which other team members are asked to review and approve before they’re merged into the main codebase. Pull requests can be created from both forked and clone repositories. (Confusingly, “pull” and “pull request” are not in fact related.)

How to Get Started with Git and GitHub

There are a variety of cloud-based ways to work with Git-based version control. GitHub is the best-known of them, but it’s not the only one; there’s also GitLab and Bitbucket, among others. GitLab is notable for allowing you to deploy it on your organization’s servers.

If you don’t need to work with files locally, you can accomplish a lot, including creating and forking repositories and managing files, using one of those cloud solutions in your browser. But to work with files locally as well as online, you’ll need to install Git on your local computer. Instructions for doing that can be found here. 

Once you’ve downloaded and configured Git itself, you could download and configure a desktop client that will work with it. One option is an app that will serve strictly as an interface to your online Git repo. GitHub Desktop is one, but there’s also SourceTree and Tower. 

Alternatively, you can integrate Git with your preferred IDE. Visual Studio Code, Xcode, and IntelliJ IDEA, among others, all have Git integration built-in. Once you’ve installed Git locally, you link your IDE to your cloud repo; most of the time, you can do so directly in the IDE.

Once you’ve installed Git locally and configured the desktop client, you can check your setup—and start learning your way around—by following GitHub’s Hello World project. (For a deeper dive, check out the book Decoding Git, which walks through the remarkably lean code that underlies the whole system.)

If you really want to get serious, you can interact with Git directly from the command line, instead of using a desktop client. All you have to do is install Git. GitHub also offers its own CLI, which adds some additional command-line options; for more details on that, see "About GitHub CLI."

How to Use Git for Version Control

One simple way to start getting comfortable with Git and its processes: Try adding a text file to a repo to which you have access. The steps: 

• clone the repo;
• create a text file on your Mac; then
• push the change up to GitHub.

If you’re using the command line, you'd start by issuing the command: 

git clone https://github.com/username/repo_name

Replace username with the GitHub username of the repo owner and repo_name with the name of the repo you want to clone. This will create a folder on your computer matching the name of the cloned repo. 

Next, create a new text file using whichever text editor you prefer; just be sure to save the file with a .txt extension and put the new file into the git repo that you just cloned. Stage the file to get it ready to add to your local Git repo:

git add filename.txt

Replace filename with the name of the file you created. Next, commit the file with the -m option:

git commit -m "Add new text file"

That -m switch and the text that follows ("Add new text file") adds a comment; replace that placeholder text with whatever brief description you like. Commenting is not optional. If you try to commit without it, Git will open an editor (usually the one that the commit was initiated from) and request that you enter a message.

Finally, you’d push the changes to GitHub:

git push origin main

This will update the main branch of the remote repo on GitHub with your new text file. In this case, origin is the shorthand name chosen for the remote branch, which in this case ismain; both are just common conventions.

One thing to be careful about, particularly when you first get started with Git: Don’t accidentally push any sensitive data to your repo. Secrets like passwords and API tokens that are pushed will be visible in perpetuity (unless you contact the cloud service you’re using and ask them to please scrub it.) In the event that a secret is pushed to a repo, the best thing is to revoke the secret immediately.

Such breaches often happen when you’re forking a repo. As noted above, if the repo you’re forking is public, the new repo will be public too, so any changes you make to the new copy will be visible. The better path: Clone the repo to your local computer.

Like any technology you’re learning, getting used to Git requires a bit of study, then a bit of practice. Get comfortable with the documentation for whichever Git solution you or your organization chooses, try things out a bit at a time, build up your confidence and skills, and pretty soon Git will be an integral part of your workflow and you won’t know how you and your team worked without it.

About Kandji

Kandji is the Apple device management and security platform that empowers secure and productive global work. With Kandji, Apple devices transform themselves into enterprise-ready endpoints, with all the right apps, settings, and security systems in place. Through advanced automation and thoughtful experiences, we’re bringing much-needed harmony to the way IT, InfoSec, and Apple device users work today and tomorrow.