Git & Source Control for Infrastructure Engineers

A Git repository (repo) is a version-controlled folder that contains all the source code, configuration, and history for a project. Every change ever made is recorded — who made it, when, and why. Nothing is lost, and anything can be rolled back.

Think of it the same way you think about a Cloud Template or an IaC definition in Aria Assembler. The repo is the source of truth. Nobody edits a running server directly — just like nobody should bypass the repo and hand-edit code on a live web server. The repo drives everything.

The three most common Git hosting platforms are GitHub, GitLab, and Azure DevOps (Repos). All three provide the same core Git functionality plus web-based UI, access controls, and CI/CD pipeline integrations.

This depends heavily on the company's architecture philosophy. There are two dominant strategies:

Monorepo

One large repository holds all code for all teams and services. Companies like Google and Meta operate this way. The advantage is easy code sharing and atomic changes across services. The trade-off is significant complexity at scale — specialized tooling is required to manage build times and access controls inside a single massive repo.

Polyrepo

One repository per service, product, or team — the most common approach. A mid-size software company might have 20 to 200 repos. A large enterprise like Microsoft has tens of thousands. Each repo is independently deployable, has its own pipeline, and is owned by a specific team.

For a documentation-focused software company, a reasonable polyrepo layout might look like this:

This is the question most infrastructure engineers ask first: "Okay, the code is in a repo — but how does it actually get onto a server?" The answer is a CI/CD pipeline.

CI/CD stands for Continuous Integration / Continuous Delivery. A pipeline is an automated workflow that triggers when code is merged and handles building, testing, and deploying it — with no one manually copying files to a server.

Common Deployment Targets

Depending on the architecture, the pipeline pushes the build to one of these destinations:

• Static CDN — Files synced to Cloudflare, Azure Static Web Apps, or AWS CloudFront. No web server to manage. Most common for documentation and marketing sites.
• Container Registry → Kubernetes — Pipeline builds a Docker image, pushes it to a registry, and applies updated manifests to a Kubernetes cluster. New pods spin up, old ones terminate.
• VM / Web Server via SSH or agent — Pipeline SSHs into a server and copies the build artifact, or a deployment agent running on the server pulls from the registry. Used in older or on-prem architectures.
• Serverless / PaaS — Pipeline deploys a function or app package directly to Azure App Service, AWS Lambda, or similar. No server management at all.

A Pull Request (PR) is a formal request to merge code from one branch into another, with a built-in review, discussion, and approval process before anything actually changes in the target branch.

Developers work on isolated branches so their in-progress work never touches main until it has been reviewed and approved. A PR is the gate between a developer's idea and code running in production.

When a PR is opened, teammates can see exactly what lines of code changed (the diff), leave inline comments on specific lines, ask questions, request changes, and ultimately approve or reject the merge.

Most teams also require that automated checks pass — unit tests, linting, security scans — before a PR can be merged. This keeps bad code out of main automatically, not just through human review.

Draft Pull Requests

A developer can open a Draft PR before their work is complete. This signals: "I'm not done yet, but here's the direction I'm heading — early feedback welcome." Draft PRs cannot be merged until explicitly marked as ready for review.

1. Developer creates a branch off main — e.g. feature/add-search-bar
2. Writes code, commits changes to that branch locally and pushes to the remote repo
3. Opens a PR on GitHub / GitLab / Azure DevOps: "I want to merge my branch into main"
4. CI pipeline automatically runs — tests execute, linting checks fire, security scans run
5. Teammates review the diff, leave inline comments, request changes if needed
6. Developer addresses feedback, pushes additional commits — the PR updates in place
7. Required number of reviewers approve (usually 1–2 depending on team policy)
8. PR is merged — CI/CD pipeline triggers and deploys to production

Branch protection rules are enforced policies on the main branch (or any branch you designate as protected). They prevent careless or unauthorized changes from reaching production code.

If you come from a server infrastructure background, you already understand every concept in this article — the terminology is just different. Here is the direct mapping: