Git Cheatsheet for Cloud Teams

Git is the foundation of every modern cloud deployment pipeline. Knowing it well is not optional — it is the mechanism by which code gets from your laptop to production.

Core Commands#

Command	What it does
`git init`	Initialise a new local repository
`git clone <url>`	Copy a remote repository to your machine
`git add <file>`	Stage a file for the next commit
`git add -p`	Interactively stage chunks (review before committing)
`git commit -m "message"`	Record staged changes with a message
`git status`	Show staged, unstaged, and untracked changes
`git log`	Show commit history
`git diff`	Show unstaged changes
`git diff --staged`	Show staged changes (what will be committed)
`git branch`	List local branches
`git branch -a`	List local and remote branches
`git checkout -b feature/my-feature`	Create and switch to a new branch
`git switch -c feature/my-feature`	Same as above (newer syntax)
`git merge feature/my-feature`	Merge a branch into the current branch
`git rebase main`	Replay commits on top of main
`git push origin feature/my-feature`	Push a branch to the remote
`git pull`	Fetch and merge remote changes
`git fetch`	Download remote changes without merging
`git stash`	Save uncommitted changes temporarily
`git tag v1.0.0`	Create a lightweight tag

Useful Flags and Shortcuts#

# Compact log with branch graph
git log --oneline --graph --all

# Push and set upstream tracking in one step
git push -u origin feature/my-feature

# Amend the last commit message or add forgotten files (local commits only)
git commit --amend

# Apply stash and remove it
git stash pop

# Apply stash but keep it in the stash list
git stash apply

# Stash including untracked files
git stash -u

# Show what changed in a specific commit
git show abc1234

# See which commits touched a specific file
git log --follow -- path/to/file.tf

Branch Workflows#

Feature branch workflow#

This is the most common pattern for teams using GitHub or GitLab.

git checkout main && git pull           # start from the latest main
git checkout -b feature/add-gcs-bucket  # create a feature branch
# ... make changes ...
git add -p                              # stage carefully
git commit -m "feat: add GCS bucket for audit logs"
git push -u origin feature/add-gcs-bucket
# open a pull request / merge request
# after merge:
git checkout main && git pull
git branch -d feature/add-gcs-bucket

Trunk-based development#

Branches are short-lived (hours, not days). Teams commit directly to main or via very short feature branches.

Requires feature flags to hide incomplete work
Reduces merge conflicts because branches diverge for less time
Common in teams with mature CI/CD pipelines

GitOps pattern#

The Git repository is the single source of truth for what runs in production.

Infrastructure config (Terraform, Kubernetes manifests) lives in Git
A CD tool (Argo CD, Flux) watches the repo and applies changes automatically
To deploy: open a PR, get it merged, the CD tool does the rest
To roll back: revert the commit in Git

Merge vs Rebase#

	Merge	Rebase
History	Preserves branch history; creates a merge commit	Rewrites commits onto the target; linear history
When to use	Integrating long-lived branches; preserving context	Cleaning up local commits before a PR
Risk	None — does not rewrite history	Never rebase branches others have checked out
Result	Non-linear history with merge commits	Clean linear history

Rule: rebase your own local work before pushing. Never rebase a branch that has already been pushed and shared with others — it rewrites commit hashes and will break their local copies.

Undoing Things#

# Undo the last commit but keep changes staged
git reset --soft HEAD~1

# Undo the last commit and unstage changes (changes kept in working directory)
git reset HEAD~1

# Discard local changes to a file (cannot undo)
git restore path/to/file.tf

# Discard ALL local changes (cannot undo — be sure)
git reset --hard HEAD

# Safely undo a commit that has already been pushed (creates a new commit)
git revert abc1234

# Unstage a file without discarding changes
git restore --staged path/to/file.tf

git reset --hard discards all uncommitted changes permanently. git revert is the safe alternative for undoing pushed commits because it does not rewrite history.

Remote Operations#

# Show configured remotes
git remote -v

# Add a remote
git remote add origin https://github.com/myorg/myrepo.git

# Change a remote URL (e.g., after a repo rename)
git remote set-url origin https://github.com/myorg/new-name.git

# Fetch all remote branches without merging
git fetch --all

# Delete a remote branch
git push origin --delete feature/old-branch

fetch vs pull#

git fetch downloads changes from the remote but does not touch your working directory. git pull is shorthand for git fetch followed by git merge. Use git fetch first when you want to inspect changes before merging.

Conflict Resolution#

When Git cannot auto-merge, it marks conflict zones in the file:

<<<<<<< HEAD
resource "aws_s3_bucket" "logs" {
  bucket = "prod-logs-bucket"
=======
resource "aws_s3_bucket" "logs" {
  bucket = "prod-audit-logs-bucket"
>>>>>>> feature/rename-bucket

Steps to resolve:

Open the conflicted file and decide which version is correct (or combine both)
Remove all conflict markers (<<<<<<<, =======, >>>>>>>)
git add path/to/resolved-file.tf
git commit (or git rebase --continue if you were rebasing)

Use git mergetool to open a visual diff tool if your editor supports it.

Tags#

# Create a lightweight tag (just a pointer to a commit)
git tag v1.0.0

# Create an annotated tag (stores tagger name, date, message)
git tag -a v1.0.0 -m "First stable release"

# Push tags to remote (git push does not push tags by default)
git push origin v1.0.0
git push origin --tags        # push all tags at once

# Delete a local tag
git tag -d v1.0.0

# Delete a remote tag
git push origin --delete v1.0.0

# List all tags
git tag -l

Use annotated tags for releases. They carry metadata and can be signed. Lightweight tags are fine for local bookmarks.

.gitignore Patterns for Cloud Projects#

# Terraform
*.tfstate
*.tfstate.backup
.terraform/
.terraform.lock.hcl
*.tfplan

# Credentials and secrets
.env
.env.local
*.pem
*.key
*credentials*
secrets.yaml

# Cloud provider credential files
.aws/credentials
gcloud/

# Node / Python
node_modules/
__pycache__/
*.pyc
.venv/
dist/
build/

# Editor files
.DS_Store
.idea/
*.swp

Never commit .tfstate — it can contain secrets and causes conflicts when multiple people share it. Use remote state instead.

Git Configuration#

# Identity (required for commits)
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Set the default branch name for new repos
git config --global init.defaultBranch main

# Store credentials (use a credential manager in production)
git config --global credential.helper store

# Set your preferred editor for commit messages
git config --global core.editor "vim"

# Show the config
git config --list

Typical CI/CD Pipeline Triggered by Git Push#

Developer pushes to a feature branch on GitHub/GitLab
CI system (GitHub Actions, GitLab CI, Cloud Build) detects the push
Pipeline runs: lint → unit tests → build → integration tests
On pull request merge to main: pipeline also runs Docker build + push to registry
CD system (Argo CD, Flux, or a deploy step) applies the new image to the cluster
On tag push (v*): pipeline creates a release artifact or triggers a production deploy

The git event (push, PR open, tag create) is the trigger for every step. Getting comfortable with Git is getting comfortable with your entire deployment process.