Git for DevOps: What to Learn Beyond Commit

Why Git comes now

You already have something worth protecting: the runbook from Linux and your notes from networking. Right now, an edit you regret is gone. Git fixes that, and it starts to matter a lot once your scripts can change real servers.

Git also becomes the way work moves through a DevOps team. A change to a server or a pipeline is often reviewed as a pull request, just like app code. CI/CD runs when code lands in Git. Terraform files live there too. So this step is short, but every later step uses it.

What to learn, in order

1. Commits and the staging area. A commit is a saved snapshot of your files. Use git status, git add, git commit and git diff. Small commits are easier to review and to undo.
2. Reading history. Use git log --oneline and git show <commit>. When something breaks in production, one of the first questions is what changed.
3. Branches. A branch lets you work on a change without touching main. Learn git switch -c <name> and how to merge.
4. Remotes. A remote is a copy of the repo on another machine, usually GitHub. Learn git clone, git pull and git push. You already know SSH keys, and GitHub can use them too.
5. Pull requests. A pull request asks a team to review a branch before it merges. It is also where automated tests will run at step 7. Use them even when working alone, so the habit is in place.
6. Merge conflicts. Git stops when two branches change the same lines, and it asks you to choose. Learn to resolve a conflict from the command line. Conflicts look scary the first time, but they are usually a small edit.
7. Undoing work. git revert adds a new commit that reverses an old one. This is the safe choice on a shared branch, since nobody's history changes. git reset moves your branch backward, so keep it for commits you have not pushed.
8. What never to commit. Passwords, API keys and .env files stay out of Git. Learn .gitignore so Git ignores those files.

If you want more depth on any item, the free Pro Git book is the standard reference.

What to skip for now

• Git submodules.
• Git internals, such as how objects are stored.
• Learning git bisect and interactive rebase. You can learn these the first time you need them.
• Debates about branching models such as Gitflow. Your future team will already have one.

Common mistakes

• Force-pushing a shared branch to tidy the history. git push --force replaces the remote history. It can erase a teammate's commits and break their copy of the repo. Protect main with branch protection rules, which can block force-pushes.
• Deleting a leaked password in a new commit and calling it fixed. The old commit still holds it. Treat the secret as stolen: replace it first, then clean up. On public repos, GitHub's secret scanning can spot known secret formats, but do not count on it to catch everything.
• Adding .env to .gitignore after committing it. .gitignore only affects files Git does not track yet. Remove a tracked file from tracking with git rm --cached .env, and replace any secret it held.
• One huge commit at the end of the day. A commit that mixes five changes cannot be reverted cleanly. If one of the five is bad, you lose all of them.
• Editing files directly on the server. Those edits exist nowhere else, and the next deploy can overwrite them. Make the change in Git.

Your project

Create a GitHub repo and add your runbook and notes. Add a .gitignore first. Turn on branch protection for main, so changes must go through a pull request. On GitHub Free, this needs a public repo, so keep secrets and private details out of your notes.

Then practice each move on purpose:

1. Make one change through a pull request and merge it.
2. Create a conflict between two branches and resolve it.
3. Merge a bad change, then undo it with git revert.

From now on, every change on this roadmap goes through a pull request in this repo. Your scripts from the next step go there first.