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
share
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.
Top comments (0)