Git basics for engineers: commits, branches and remotes

Why engineers need version control

Without version control, scripts live in folders called final, final2 and final-really. Git is a distributed version control system: it keeps a full history of every change, lets several people work at once and makes it easy to undo mistakes. Network teams use it for scripts, Ansible playbooks, templates and even device configuration backups.

The everyday commands

git config --global user.name  "Your Name"
git config --global user.email "you@example.com"

git init netops-scripts && cd netops-scripts
git status                       # what changed?
git add check_hosts.sh           # stage a file
git commit -m "Add host reachability check"
git log --oneline --graph        # short history
git diff                         # unstaged changes
git restore check_hosts.sh       # throw away unstaged edits

A commit is a snapshot with a message. Good messages are short and say why: "Increase ping timeout for satellite sites" is far more useful than "update". Commit small, related changes together so each one is easy to review and, if necessary, revert.

Branches and merging

A branch is a movable label for a line of work. You create a branch for each change, so the main branch always holds tested, working code.

git switch -c fix/ping-timeout   # create and move to a new branch
# ...edit, add, commit...
git switch main
git merge fix/ping-timeout
git branch -d fix/ping-timeout

If two branches change the same lines, Git reports a merge conflict and marks the file. You edit the file to keep the right version, then git add and git commit to finish.

Remotes and collaboration

A remote is a copy of the repository on a server such as GitHub, GitLab, Bitbucket or an internal Gitea instance.

git clone git@git.example.com:netops/scripts.git
git pull                          # fetch and merge others' work
git push -u origin fix/ping-timeout

On the hosting platform you open a pull request (GitLab calls it a merge request). A colleague reviews the change, automated checks such as linters run, and then it is merged. This is the same peer review you would want for any production change.

A secret pushed to a remote should be treated as exposed: rotate it straight away, because removing it from history does not undo copies others may have pulled.

Tip: a public Git repository of your lab scripts and playbooks makes a strong portfolio when you apply for network automation roles.