What version control does
Anyone who has worked on a document with others knows the mess: files named “report_final”, “report_final_v2” and “report_final_really”, and nobody sure which is current. Version control solves this by recording every change to a set of files, along with who made it, when, and why.
With version control you can look at the state of your files at any earlier point, compare two versions to see exactly what changed, undo a mistake, and let several people work at the same time without overwriting each other. It is used for software, but it works for any text-based files, including scripts, configuration files, documentation and policies.
Git is the most widely used version control system. It is free and works on all the common desktop operating systems. Other systems exist, but the ideas below carry over.
The key terms
Repository. A project folder together with its recorded history. Often shortened to “repo.”
Commit. A saved snapshot of your files at a moment in time, with a message describing it. A repository’s history is a chain of commits.
Working directory and staging area. The working directory is the folder you edit. Git does not record everything automatically. You choose which changes to include in the next commit by adding them to the staging area first. This lets you group related changes into one commit and leave others for later.
Branch. A separate line of work. You can create a branch, make changes there without affecting the main line, and combine them back when ready.
Merge. Combining the changes from one branch into another.
Remote. A copy of the repository stored somewhere else, such as on a server, so that a team can share work and so that a copy exists outside your own machine.
A basic workflow
The usual cycle looks like this, using a command line, which is a useful skill to have anyway (see command line basics), though graphical tools also exist.
- Create or copy a repository. You either start a new one in a folder or copy an existing one from a remote.
- Make changes. Edit your files as usual.
- Review what changed. Git can show which files were modified and the exact lines that differ.
- Stage the changes you want to record.
- Commit with a short message.
- Share. Send your commits to the remote and fetch other people’s.
Repeat. The result is a detailed history of how the project evolved.
Writing good commits
A history is only useful if it is readable. Some habits help:
- Keep commits small and focused. One logical change per commit is easier to review and easier to undo.
- Write meaningful messages. “Fix backup script path” says more than “update.” Say what changed and, if it is not obvious, why.
- Commit working states where you can. It is much easier to go back to a point where things worked.
- Do not commit secrets. Passwords, keys and tokens do not belong in a repository. Once a secret is in the history, removing it fully is hard, and it should be treated as exposed and replaced. Keep such values in a password manager or a secrets facility instead.
- Avoid large generated files and binaries. Git works best with text and small files.
A file named .gitignore tells Git which files to leave out, such as temporary files or local settings.
Branches and collaboration
Branches are what make teamwork safe. A common pattern is:
- Keep a main branch that always holds working, agreed content.
- When you want to make a change, create a new branch from it.
- Do your work and commit on that branch.
- Share the branch and ask a colleague to review it.
- After review, merge it into the main branch.
Many hosting services provide a review feature, often called a pull request or merge request, where colleagues see the differences, comment on them and approve. This gives the team a chance to catch errors and share knowledge, and it keeps a record of why changes were made. Organizations often pair it with change management so that approvals are visible.
Occasionally two people change the same lines in different ways, and Git cannot decide which to keep. This is a merge conflict. It sounds alarming but is normal. Git marks the competing versions in the file, you choose or combine them, and you commit the result. Frequent sharing of small changes keeps conflicts rare and small.
Undoing mistakes
Because history is kept, most mistakes are recoverable. You can discard uncommitted changes to a file, create a new commit that reverses an earlier one, or look at an older version without disturbing the current one. Some commands rewrite history and are best avoided on work that others have already received. If you are unsure, make a copy of the repository or a backup branch before trying something unfamiliar.
Remember that a repository is a record of work, not a backup strategy by itself. A remote copy helps, but if a project matters, it should be included in your regular backups too.
Why IT staff should care
Version control is not only for software developers. System administrators use it for scripts, configuration files and documentation. It is the foundation under configuration management and infrastructure as code, and it is where automated build pipelines get their instructions. Even a small team benefits from having every script in one place with a history. If something stops working after a change, you can see what changed and by whom, and go back.
Getting started
Install Git, create a repository for a small folder of scripts or notes and make a handful of commits. Practice looking at the history, creating a branch, making a change and merging it. A home lab or personal project is a low-pressure place to do it.
The commands take a little time to learn, but the underlying idea is simple: record your changes in small, well-described steps, and work on separate branches until you are ready to combine.