Git, GitHub Actions, Shell, and Docker: From Local Development to CI/CD and Containers

These tools solve delivery problems: collaboration, automated testing, packaging, runtime consistency, and deployment.

Git Workflow

Common commands:

git status
git add .
git commit -m "feat: add login"
git pull
git push
git checkout -b feature/login

Common concepts:

merge: preserves branch merge history
rebase: moves commits onto a new base for linear history
reset: moves the current branch pointer and may affect working tree
revert: creates a reverse commit, safer for shared branches

GitHub Actions

A workflow is made of triggers and jobs.

name: CI
 
on:
  push:
  pull_request:
  workflow_dispatch:
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

Common triggers:

push
pull_request
schedule
workflow_dispatch

Git Hooks

Git Hooks are local scripts that run before or after Git actions.

Common uses:

format before commit
lint before commit
test before push
validate commit messages

Shell Pipes and Redirection

cat app.log | grep ERROR

A pipe sends output from the left command to the right command.

node script.js > output.txt
node script.js >> output.txt

> overwrites. >> appends.

Docker Concepts

Image is the packaged template. Container is a running instance of an image.

Dockerfile describes how to build an image.

Volume persists data.

Network lets containers communicate.

Dockerfile

FROM node:20
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
EXPOSE 3000
CMD ["npm", "run", "start"]

Copying dependency manifests before source code helps Docker reuse build cache.

docker-compose

docker-compose starts multiple services together.

services:
  web:
    build: .
    ports:
      - "3000:3000"
  db:
    image: postgres:16
    volumes:
      - db-data:/var/lib/postgresql/data
 
volumes:
  db-data:

It is useful for local development, integration tests, and small deployments.

Deeper Notes

When reviewing this topic, do not memorize names only. Focus on Git workflow, CI, Git hooks, shell pipelines, Dockerfiles, and Compose as an engineering workflow. If this stays at the definition level, it becomes hard to explain in interviews or apply in projects. A stronger way to study it is to place it in a concrete scenario: who calls it, where the input comes from, what happens on failure, and whether data or state can be processed twice.

DevOps is about shortening feedback loops while reducing release risk; tools are only the mechanism.
CI/CD should cover build, test, static checks, image creation, deployment, and rollback, not just command execution.
Scripts, Docker, and GitHub Actions should be repeatable, auditable, and stable locally and in CI.

In a real project, use it as a decision framework: identify inputs, constraints, failure modes, and observability before choosing a specific tool or pattern. If a solution looks simple, keep asking whether it still works when scale grows, permissions change, recovery matters, and more people collaborate on it.

Practical Checklist

Identify where this concept sits in the system: development-time constraint, runtime behavior, infrastructure capability, or collaboration workflow.
Write one minimal working example and one failure example; only knowing the happy path is usually not enough.
Record common misuses: edge cases, permission assumptions, performance assumptions, sync/async differences, or environment differences.
Connect the concept to a project experience so that an interview answer can be grounded in real tradeoffs.
End with one sentence about tradeoff: what it gives up and what it buys.

Self-Check Questions

What core problem does this topic solve?
What alternatives exist, and what are their costs?
Where are the most likely edge cases?
How would code, tests, or monitoring prove that it is reliable?

Applied Scenario

Use a code-to-production pipeline as the mental model. A developer pushes code, GitHub Actions installs dependencies, runs linting and tests, builds an image, and deploys it. Dockerfiles make runtime environments repeatable, docker-compose starts local dependencies, and shell scripts automate repeated commands. A good DevOps flow surfaces errors early and gives the team evidence for rollback and debugging.

Common Pitfalls:

Running only build in CI without tests or static checks.
Letting local and production environments drift too far apart.
Writing scripts that swallow failures instead of exiting clearly.

Table of Contents