🚀 Day 3 of My DevOps Journey: Git & GitHub for DevOps (From Zero to Daily Workflow)

Hello dev.to community! 👋

Yesterday we explored Linux as the foundation. Today we’re layering the next essential skill: Git & GitHub — the backbone of collaboration, CI/CD, and reliable releases.

🔹 Why Git matters for DevOps

Traceability: every change is tracked with author, time, and reason.

Safe collaboration: branches, pull requests, and reviews prevent “it works on my machine” disasters.

Automation-ready: GitHub is often the source of truth that triggers CI/CD, security scans, and deployments.

🧠 Core concepts (quick glossary)

Repo: the project database of your code history.

Commit: a snapshot + message of what changed and why.

Branch: an isolated line of work (e.g., feature/login).

PR (Pull Request): propose, review, and merge changes.

Tag/Release: freeze a version (e.g., v1.2.0) for deploys.

🛠️ Commands I’m mastering (cheat-sheet)

set identity (do once)

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

start & inspect

git init
git clone
git status
git log --oneline --graph --decorate

stage & commit

git add .
git commit -m "feat: add healthcheck endpoint"

branching

git branch -M main
git switch -c feature/healthcheck # or: git checkout -b feature/healthcheck
git merge main

undo safely

git restore # discard unstaged changes
git revert # make a new commit that undoes another

git remote add origin
git push -u origin main
git push -u origin feature/healthcheck
**

🌿 Branching that suits DevOps

Trunk-Based Development (recommended for most teams):
Short-lived branches → small PRs → merge to main multiple times a day.

Release tags: v1.0.0, v1.0.1 for deploys and rollbacks.

Protection rules: require PR reviews, statuses (tests) to pass before merging.

🤝 GitHub features you’ll use daily

Pull Requests: code review, inline comments, required approvals.

CODEOWNERS: auto-request the right reviewers.

Branch protection: block force-pushes & direct commits to main.

Issues & Projects: track work; link commits/PRs to issues.

Actions (CI): run tests, linters, builds on each push/PR.

🧪 Hands-on mini-labs (do these!)

Start a repo: README.md, .gitignore, LICENSE → initial commit → push.

Feature flow: create feature/* branch → change code → open PR → request review → squash merge.

Conflict drill: create a conflict on purpose and resolve it via PR.

Tag & Release:

git tag -a v0.1.0 -m "first cut"
git push origin v0.1.0

Create a GitHub “Release” from the tag.

Protect main: require 1 review + status checks before merge.

⚙️ Bonus: a tiny GitHub Actions pipeline (runs tests on PRs)

Create .github/workflows/ci.yml:

name: ci
on:
pull_request:
branches: [main]
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm test

Swap Node for Python/Go/etc. as needed. This single file gives you instant feedback on every PR.

🧭 Good habits from day one

Write meaningful commit messages (use prefixes like feat:, fix:, docs:).

Keep PRs small & focused (easier reviews, faster merges).

Never commit secrets — use .gitignore and secret managers.

Tag releases that are deployed; link PRs to issues for traceability.

🎯 Key takeaway

Before Docker, K8s, or fancy pipelines — get comfortable with Git & GitHub. Clean history + protected main + automated checks = fewer outages and faster delivery.

🔜 Tomorrow (Day 4)

I’ll cover Bash scripting for DevOps — turning repetitive terminal steps into reliable automation.