I’ve noticed an anti-Git sentiment on a popular webmasters forum. Some of the reasons I’ve seen are grounded (documentation and other guides for webweaving shouldn’t assume everyone knows Git), and others are simply ignorant, so in this article I hope to make the case for why Git is useful for webmasters and how to get started using it.
What is Git?
Let’s start with the basics: what are we even talking about? Most outsiders seem to think Git is this weird thing programmers use to upload their code to the internet. That is true only for the greenest developers who haven’t yet learned the reasons why the rest of us started using it.
Fundamentally, Git is a tool for keeping track of changes in files. That’s it. The generic name for this type of software is a version control system, named so because it lets developers manage various versions of their software.
But you can use it to track changes in anything! I’ve used it to keep history of my school reports before. It’s useful for any document or collection of documents (like a website) that changes over time.
Why should I track my documents’ changes?
The main utility of a version control system isn’t merely keeping history of changes. There are 5 major benefits to using such a system:
- The ability to roll back a change that contained a mistake.
- The ability to un-delete files you thought you didn’t need anymore.
- The ability to make experimental or otherwise destructive changes without risking what you already had.
- The ability to cleanly merge those changes with the main version when they’re ready to go live.
- The ability to work collaboratively on a project without an always-online editing software or other cumbersome document merging strategy and without the risk of one collaborator’s changes getting overwritten by another’s.
I’m sure people can come up with more, but these are the most relevant benefits for webmasters in my opinion. Number 5 may not be relevant to you if you’re a solo webmaster, but it is the primary reason why programmers use Git, and I imagine it would be useful for larger web projects as well.
Do I need to learn to use the command line for this?
No! A quick search for Git GUI software yields dozens of graphical Git clients you can try if you are intimidated by the command line. The remainder of this guide will use command line examples because the CLI is universal to Git and because it is where most of my experience lies. That said, with a bit of intuition, you should be able to find your GUI’s equivalent to any command; they tend to always use the same language. For instance, if I reference git commit, you should look for a “Commit” button in your software to accomplish the same task.
For those who are following along on the command line, this guide assumes all commands are running from the directory where your project is stored.
Initial setup
Before starting your project, if this is your first time installing Git, you’ll need to do just a tiny bit of setup. Git requires a name and email address to attach to your commits. This does not require any sort of account registration, and you can use anything you want.
git config set user.name "Your Name Here"
git config set user.email "you@example.com"
And that’s it!
Starting a Git project
The first step is to initialize a new repository, or repo for short. A repo is a collection of files tracked by Git.
If you’re starting a new project from scratch, just make a new empty directory (folder) for your repo. If you have an existing project that you want to start tracking in Git, you can use that directory.
Now, let’s initialize the repo:
git init
This creates a .git directory in your project, where all Git-related files for your project will live. At this point you can run git status to confirm that Git is active, and it will show you a list of your files, which at this point are untracked.
Choosing which files to track
Git is not greedy to track all your files without your confirmation first. By default, any new file that you have not explicitly told Git to track will be left out of the history. This includes your entire project when you first init the repo. To start tracking a file, simply do:
git add your-file
Adding files one at a time like this would be annoying. We can add all files using:
git add -A
However, maybe there are some files you don’t want to include, but you still don’t want to have to type the rest by hand. For this purpose, you can create a .gitignore file. This is just a text file called .gitignore in your project directory that contains a list of files which Git should ignore. You can ignore individual files by name, entire directories, or even patterns of files using * as a wildcard. For instance, if you are using a static site generator and want to exclude its HTML output from your repo, you can just add public/ (or whatever your SSG’s output directory is called) to the .gitignore file. This is also useful to exclude any files such as site upload scripts which may include private credentials.
To confirm that your .gitignore is set the way you want, run git status. If you see a file listed under “Untracked files”, that means Git is still noticing it and will track it if added to the repo. Ignored files should not appear in the status output at all.
Once that is set up the way you like, you can freely git add -A without the risk of including a file you wanted to leave out of tracking.
Committing your changes
Commits are the unit of history in Git. Changes are tracked from one commit to the next. Any changes you make between commits is not stored, so you should always commit when you are at a point in your work that you want to be able to return to again if needed.
After adding files to Git tracking as in the above section, you can commit them with:
git commit
You will be prompted for a commit message. Every commit should include a message describing what changed between this and the last commit. For your first commit, “Initial commit” is a standard choice. If you’re using the command line and don’t want a text editor to open for your commit message, you can simply provide it directly on the CLI like so:
git commit -m "Your commit message here"
After your first commit, new changes must still be added as in the above section to include them in the next commit. However, it is often the case that you want to include all changes in the next commit. You can save yourself a step with the -a flag like so:
git commit -am "Your commit message here"
That extra a in there tells Git to automatically add all updated files which were already being tracked by Git before committing. If you created a new file which has not been included in any prior commit, you still need to add it as in the above section.
Branching
Branches are where Git really begins to shine. Following only the steps above, your changes will have been committed to a default branch, such as main or master. However, you can make your own branches for experimental changes that you want to keep separate from the default branch until they are ready.
Let’s say you want to rewrite your CSS entirely, but you want to continue making posts on your website even before the rewrite is finished. First, create a new branch for the CSS changes:
git branch css-rewrite
Then, switch to using that branch:
git switch css-rewrite
Now, any commits will be made to the css-rewrite branch and leave your default branch alone. When you want to return to the default branch to make a new post, simply commit your current changes and then switch back to it:
git switch main
You can check which branch is currently active by running git branch. When you’re satisfied with your CSS changes and want to include them in the main branch, merge it like so:
git switch main
git merge css-rewrite
You may be prompted for a commit message at this time. This happens if there have been commits in both branches before the merge. You can simply accept the default commit message and move on.
If you have no reason to return to your css-rewrite branch again, you can delete it as follows:
git branch -d css-rewrite
Collaborating and sharing
Up until this point, everything you’ve been doing is local to your machine. For many use cases, that is sufficient, but perhaps you want to transfer your repo to another computer, work collaboratively over the internet, or share your work publicly. Enter: remote repos.
The most commonly used form of remote repo is the online public Git host, such as GitHub, Codeberg, SourceHut, and many others. These require you to register an account, and they all work slightly differently, so I will not include complete setup instructions here. The basic sequence goes as follows:
- Create a new repository on the Git host (do NOT choose the option to initialize the repo when creating it; you already did that on your local machine).
- Open the page for the newly-created repo, and follow the instructions to add a
remoteto your repo. This usually involves agit remotecommand. Graphical Git clients will also provide a way to add new remotes. - Push your changes to the remote repo using
git push.
Pushing your changes requires you to specify which branch you want to send and to which remote, such as:
git push codeberg main
In this example, I created a remote called codeberg, and I’m pushing my main branch to it. It is common for the default remote to be named origin, under the assumption that the repo originated from the remote host. You can call it whatever you want.
To set up defaults, you can use the -u flag:
git push -u codeberg main
This sets the default upstream for the main branch. Now, in the future, when pushing changes from the main branch, you can simply do:
git push
One caveat: when you give a branch name to git push, you are actually telling it what to name the current branch on the remote side. If, for instance, you are currently working in the css-rewrite branch but run the above commands, you will push the css-rewrite branch to the main branch on the remote host! Be careful of the current branch when pushing. It is possible to recover from such a mistake using git push -f to force overwrite it with another branch, but it’s better to be careful up front.
As you might expect, you can use git pull in a similar way to receive updates from the remote repo. If you need to pull down the entire repository on a new computer, use git clone. Instructions are specific to each platform, but you should be able to find them quickly if you open the web page for the repo you want to clone.
It is also possible for a remote to be a directory somewhere else on your computer, or on a USB flash drive, or on another computer on your LAN. Again, the specifics of setting this up can differ between operating systems, so it is out of scope for a beginner’s guide. The short explanation is that the URL for a remote repo can begin with file:// to point to a directory, and you can use SSH or other network protocols to reach into other computers on your LAN. You can find other guides online for things like creating a repo on a flash drive.
Wrapping up
I hope this guide has been helpful for those wondering where to start with Git and that it has been persuasive or at least thought-provoking to Git skeptics and haters.
As you might expect, this guide only scratches the surface of Git’s capabilities. Most of the time, these commands are all that’s needed for using Git effectively, but if you’re curious to dig deeper, check out the docs on the official Git website.
If you have feedback or find errors in this guide, please reach out.
