Master Common Git Commands: Your 2026 Cheat Sheet

meta_title: Common Git Commands for DevOps Teams in 2026 Guide meta_description: Learn the common Git commands DevOps and FinOps teams use to manage IaC, scripts, and cloud schedules with clearer workflows and safer collaboration. reading_time: 6 min read

From Chaos to Control: Mastering Git for Infrastructure Automation

You update EC2 stop schedules in one account, tweak an RDS resize script in another, and patch a weekend shutdown rule in a third. A week later, nobody knows which version is live, why a cron changed, or who introduced the drift that pushed cloud costs back up. Git fixes that by giving infrastructure automation a shared history, controlled collaboration, and a clean path from local edits to production-ready changes.

Tired of managing complex scripts for cloud cost savings? Server Scheduler offers a point-and-click visual grid to automate EC2 and RDS scheduling, cutting cloud bills by up to 70% without touching a line of code. Try it free today.

If you want a broader walkthrough beyond this article, this Git guide for developers is a useful companion.

Initial Setup

A lot of Git problems start before the first commit. A Platform Engineer builds a Terraform module for non-production shutdowns, a FinOps analyst updates a schedule export, and both files sit in a local folder with names like final-v2 and final-really. git init fixes that first control problem by turning the folder into a repository with history, diffs, and repeatable change tracking.

Use git init when you are starting from local files that are not under version control yet. That is common with early IaC work, one-off automation scripts, or Server Scheduler exports that began as manual experiments and now need an audit trail. Initialize the repo in place, commit the current baseline, and add a remote after the team agrees the work should be shared.

For teams joining an existing project, git clone is the entry point. Cloning pulls down the current codebase and its history, which matters when you need to review why a cost-saving schedule changed, compare older maintenance windows, or trace who modified an automation script before it reached production.

What this looks like in practice

Use git init for new internal work. Use git clone for shared repositories that already serve as the source of truth.

A practical example helps. If you are building a new repository for EC2 and RDS scheduling policies, start with git init, commit the initial Terraform, shell scripts, and documentation, then connect the remote repository once naming, access, and review rules are settled. If the repository already exists because another engineer built the first version, clone it instead so your changes start from the same history and branch structure as the rest of the team.

Practical rule: If more than one person will touch the same schedule or script, move it into Git before the edits spread.

If your setup work also includes local script automation, this bash commands cheat sheet for daily shell work pairs well with the first Git commands your team will use.

Daily Workflow

A normal day in an infrastructure repository is rarely a single-file edit. You adjust a Terraform variable for off-hours shutdown, update a shell script that tags idle instances, and revise the runbook so the next on-call engineer knows why the schedule changed. git add is the control point that lets you stage only the files that belong together.

That selectivity matters in IaC and FinOps work. If a commit mixes a production schedule change with unrelated script cleanup, review gets slower and rollback gets riskier.

git commit saves that staged set as a local snapshot with context. For platform teams, that means you can record work as you go, test it locally, and keep a clean history before anything reaches a shared branch.

Commit messages are your audit trail

In cost optimization work, the commit message often answers the first operational question: why did this change happen? "Update schedule" forces someone to inspect the diff. "Shift dev RDS stop window for holiday coverage" gives reviewers, approvers, and auditors immediate context.

Keep each commit focused on one operational decision at a time. A single commit for "adjust non-prod EC2 stop schedule" is easier to review, easier to revert, and easier to trace than one commit that also changes IAM policies, cron timing, and script logging.

A practical pattern looks like this:

git status
git add terraform/schedules/dev-rds.tf
git add scripts/apply-scheduler-tags.sh
git commit -m "Shift dev RDS stop window for holiday coverage"

Run git status before and after staging. It catches accidental file changes, especially in repositories that bundle Terraform, Ansible, Bash, and scheduler configuration in one place.

If repository access is still slowing local work, set up keys first with this Ubuntu SSH key guide for Git access.

If you spend a lot of time working in shell-based automation, the earlier bash reference is a useful companion for the scripts that often change alongside these commits.

Team Collaboration

git push publishes your local commits to the shared remote branch. In infrastructure work, that often means your team can review a schedule change, trigger CI checks, or promote a tested automation update into a deployment path. git pull does the opposite direction. It fetches and merges remote changes into your local branch so you're not building on stale assumptions.

That “pull before push” habit prevents a lot of avoidable friction. If another engineer changed a maintenance window while you were editing a start-stop script, you want that conflict now, not after both versions have diverged.

Pull versus fetch matters

An ACM study on Git command usage found that developers mostly learn Git through self-learning, and it highlighted a practical point for teams: standardize a small command set and teach the difference between destructive and non-destructive sync paths, especially fetch versus pull (ACM Git command usage study). For day-to-day work, pull is convenient. For careful review before integration, fetch is often safer.

If a branch controls production-facing automation, fetching first gives you a chance to inspect incoming changes before you merge them into your local work.

If SSH setup is still slowing down repo access, use this Ubuntu SSH key guide.

Managing Parallel Work

A common Platform Engineering problem starts the same way. One engineer is tuning an RDS rightsizing policy, another is updating a holiday shutdown schedule, and neither change should touch the approved automation in main until it has been reviewed and tested.

git branch gives each piece of work its own lane. Create a branch such as feature/rds-resizing-test, then switch to it with git checkout feature/rds-resizing-test. For IaC and FinOps work, that isolation matters because branch boundaries keep a cost-saving experiment from changing the production schedule that starts and stops resources on time.

Keep unfinished work safe

The usual mistake is changing branches with uncommitted edits still sitting in the working tree.

If you are halfway through a Terraform update or adjusting a Server Scheduler rule and need to inspect another branch, stash the work first. That keeps partial changes out of the wrong branch and reduces cleanup later. In practice, this is one of the easiest ways to avoid accidental edits to scripts, schedules, or environment-specific config files.

Before you merge branch-based work back into the main line, compare the branches and review exactly what changed. That step matters more for automation than for app code, because a small diff can change runtime hours, resource sizing, or shutdown behavior across multiple environments. For a practical review workflow, use this guide on how to merge Git branches cleanly.

Integration and Auditing

A bad merge in an IaC repo does not stay small for long. One merged change can alter instance schedules, skip a shutdown window, or push higher-cost resources into the approved baseline for every environment that pulls from main.

git merge is the point where reviewed branch work becomes operational policy. For DevOps and Platform teams, that often means a Terraform change, automation script update, or Server Scheduler rule is no longer a proposal. It is now part of the versioned source your pipelines and operators will trust.

Before merging, verify the branch diff, confirm tests passed, and check that the commit history explains the intent. Squash merges can keep history easier to audit when a branch contains many small fixup commits. Standard merges preserve more context, which helps when teams want to see the full sequence of changes during an incident review. If your team is tightening that process, use this practical Git branch merge workflow as a reference.

Audits are where Git proves its value

git log gives teams the trail they need after the change is live. In FinOps work, that usually means tracing who changed a schedule, when it changed, and which commit introduced the policy that affected cloud runtime or spend.

A common example is a Monday question from finance or operations: why did staging run through the weekend? Start with git log --oneline --graph --decorate to find the merge commit, then inspect the related commits and messages. If your team writes commit messages that mention the environment, policy, or cost objective, the answer is usually minutes away instead of buried in chat or ticket history.

Use git log during reviews, not just after incidents. Clean history shortens audits, speeds up rollback decisions, and makes it easier to prove that schedule changes were reviewed before they reached production.

5-Point Comparison of Common Git Commands

Beyond the Basics

A real test of Git skill usually starts at 2 a.m., after a bad change lands in an IaC repo and the team needs to answer three questions fast: what changed, what can be rolled back safely, and how to restore service without losing good work. For DevOps and FinOps teams, that is not an edge case. It happens during Terraform updates, schedule edits for non-production shutdowns, and fixes to automation scripts that control cloud runtime.

The commands in this article handle the day-to-day work well. The next step is getting comfortable with recovery. That means understanding the difference between staged and unstaged changes, knowing how to unstage a file without discarding it, and knowing when to undo a local commit versus when to create a corrective commit that preserves the audit trail. Git's own Git cheat sheet and undo workflows is useful here because it organizes those choices around common mistakes, not just syntax.

Useful aliases help, but only if they reduce risk instead of hiding intent.

For example, an alias like git lg for a concise log view can speed up incident review, and git st can save keystrokes during frequent repo checks. I avoid aliases that obscure destructive commands. In infrastructure repositories, a shortcut that resets or rewrites history too aggressively can make an outage harder to investigate and a cost change harder to audit later.

Server Scheduler helps DevOps and FinOps teams replace fragile cron jobs and ad hoc scripts with a visual way to manage EC2, RDS, and cache scheduling. If you want tighter control over cloud runtime, clearer auditability, and less manual work around cost-saving windows, explore Server Scheduler.