skip to content
Dawid Rycerz

Git and more

Git is one of the most underrated tools in programming. Used the wrong way, it feels like unnecessary overhead. Used well - it saves a lot of time and headaches.

As a DevOps engineer you will use Git every day. Not just for code - for documentation, infrastructure as code, configuration, automation scripts. It’s the standard tool to track changes in system state.

The program is flexible enough to use it in many ways, but it’s the DevOps engineer’s job to help teams get the most out of it. Prepare flows that are not overcomplicated, while covering required standards in the company.

This post is not a tutorial. It’s a map of what I think you need to know about Git.

Use CLI

This is the most important thing. Learn Git from the terminal. GUI tools are useful for visualization, but you should be able to do everything from console without thinking too much.

The basics: add, commit, push, branch, checkout, merge, rebase. You probably already know this.

But then there’s more: cherry-pick, revert, stash, reflog, squashing commits, push --force-with-lease, resolving merge conflicts, working with multiple remotes.

And git log - learn to filter it, format it, make it useful. Same with diff and reset (know the difference between --soft, --mixed, --hard).

If you can do all of that confidently - you’re in a good place.

Know what’s under the hood

You don’t need to be an internals expert, but when something goes wrong (and it will), understanding the basics helps a lot.

Git stores everything as objects - blob, tree, commit, tag. There’s HEAD, refs, index, SHA hashes, the commit graph.

Knowing the difference between fetch and pull, understanding local vs remote state, knowing that reflog is your safety net - these things will save you one day.

Also worth knowing: fsck and gc for repository health, shallow clones for CI, Git LFS for large files.

Configuration

Good Git config saves time every day (mine has 220 lines).

Set up your ~/.gitconfig properly - aliases for commands you use often, conditional configs (different email for work and personal projects).

Configure GPG signing for commits and tags. Set up SSH for multiple remotes. Choose your credential storage.

Not the most exciting topic, but you do it once and it just works.

Workflows

Every team needs a branching workflow. The main ones:

  • GitHub Flow (simple, good for continuous deployment),
  • GitLab Flow (adds environment branches),
  • GitFlow (more structured, release cycles).

Know them, know their trade-offs, pick what fits the team.

Then there’s versioning - Semantic Versioning (SemVer) and Calendar Versioning (CalVer).

And commit conventions - Conventional Commits, Commitizen, Commitlint.

These seem like small things, but they make changelogs, releases and automation much easier.

One more thing - monorepo vs multiple repositories. Both are valid, both have problems. Know when to use which.

Pre-commit tooling

Automating checks before code enters the repository is one of the most valuable things you can set up as a DevOps engineer. The main tools:

  • pre-commit (language-agnostic, very popular),
  • husky (JavaScript/TypeScript world),
  • lefthook (fast, simple config).

You can also write hooks directly in .git/hooks/ but dedicated tools are easier to share across the team.

Security and history

Sometimes you need to clean up history - leaked secrets, wrong commits, sensitive data that should never be there.

Know git filter-repo for rewriting history safely.

Know rebase and reset for local cleanup. And sign your commits with GPG - it proves you are who you say you are.

For history analysis: blame to find who changed what, bisect to find which commit broke things, shortlog for summaries.

Tools that make Git better

Default Git experience is fine, but there are tools that make it much better. Terminal UIs like lazygit, tig, gitui - I recommend trying at least one.

Better diffs with delta or diff-so-fancy. Merge tools like meld or vimdiff.

And a few advanced Git features worth knowing: worktree (multiple working directories from one repo), submodules and subtree (managing dependencies).

Remote platforms

Git is distributed, but in practice everyone uses a hosted platform (see Read more).

Be comfortable with all of these: GitHub, GitLab, Bitbucket, Forgejo/Codeberg, and even bare repositories on your own server.

On each platform you should know how to create and review Pull/Merge Requests, fork repositories, create tags and releases, configure SSH and GPG keys.

These are basic operations but each platform does them slightly differently.

Get familiar with the email-based workflow - you most likely won’t use it, but you never know.

Good practices

Write clear commit messages - explain why, not just what.

Keep commits small and focused.

Don’t commit binaries or large files.

Be careful with force pushes on shared branches.

NEVER commit secrets to the repository.

And always review your own diff before pushing - you’d be surprised how many problems you catch this way.

Read more