B
Bhaskar Sharma
Guest
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)
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
git init
git clone
git status
git log --oneline --graph --decorate
git add .
git commit -m "feat: add healthcheck endpoint"
git branch -M main
git switch -c feature/healthcheck # or: git checkout -b feature/healthcheck
git merge main
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.
Continue reading...

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.

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.

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.

set identity (do once)
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
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
**

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.

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.

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.

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.

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.

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

Iβll cover Bash scripting for DevOps β turning repetitive terminal steps into reliable automation.
DevOps #Git #GitHub #VersionControl #SourceControl #CICD #Automation #Collaboration #SoftwareEngineering #CloudNative #ContinuousIntegration #ContinuousDelivery #OpenSource #DevOpsEngineer #CodingBestPractices #DeveloperTools #SRE
Continue reading...