Git and GitHub

How This Fits Our End-to-End Pipeline

Git and GitHub is documented here as part of one connected build, not as an isolated tutorial. The goal is to explain how code moved from a developer laptop into a monitored Kubernetes service.

Developer laptop
  | git add / commit / push
  v
GitHub repository
  | pull request + branch rules
  v
GitHub Actions workflow
  | test -> docker build -> tag -> push
  v
Docker Hub image registry
  | immutable image tag
  v
GitOps manifests repository/path
  | ArgoCD watches desired state
  v
Kubernetes cluster
  | app pods + services + ingress
  v
Prometheus scrapes metrics -> Grafana dashboards

Theory

Git is the local version-control engine that records snapshots of the project. GitHub is the collaboration platform that hosts the repository, pull requests, branch protection, Actions workflows, issues, and release history.

In our pipeline, Git was not only a place to save code. It became the audit log for delivery. Every Docker image, Kubernetes manifest change, and ArgoCD sync starts with a commit that explains why the system changed.

Architecture Diagram

Working tree -> Staging area -> Local repository -> GitHub remote
    edit          git add        git commit        git push
      ^              |               |                |
      |              v               v                v
    diff        selected files   immutable ID      PR / Actions / ArgoCD

Step-by-step Implementation

1. Initialize the repository and make the first commit with a small, working application.
2. Add a .gitignore so dependency folders, local secrets, and generated files do not enter history.
3. Create a feature branch before adding Docker, Kubernetes, or CI changes.
4. Open a pull request and let GitHub Actions prove the project still builds.
5. Merge into main only after the commit history tells a useful story.

Commands

Start a repository

git init
git status

Creates local Git metadata and shows what is tracked, modified, or untracked.

Stage and commit

git add .
git commit -m "Add initial app scaffold"

Stages selected files and records a snapshot.

Connect GitHub

git remote add origin https://github.com/<user>/<repo>.git
git branch -M main
git push -u origin main

Connects local work to GitHub and publishes the main branch.

Create a feature branch

git switch -c feature/dockerize-app

Keeps Docker work isolated until it is reviewed.

Inspect history

git log --oneline --decorate --graph --all

Shows the shape of branches and merges, which is useful during release debugging.

Undo safely

git restore app.py
git restore --staged app.py

Discards working-tree changes or removes a file from staging without rewriting shared history.

Tag a release

git tag v1.0.0
git push origin v1.0.0

Creates a release marker that can match a Docker image tag.

GitHub Setup

• Create a private or public GitHub repository depending on the sensitivity of the project.
• Add branch protection for main: require pull requests, require passing checks, and restrict force pushes.
• Store credentials as repository or organization secrets, never in files committed to Git.
• Use GitHub Environments for staging and production when approvals are needed.

Lab Notes From The Pipeline

• Commit small changes before switching tools.
• Write messages that explain intent, not only files changed.
• Prefer revert commits over history rewriting after code is shared.
• Use pull requests as quality gates even when working solo, because the habit transfers to teams.

Interview Notes

• Explain Git as a distributed content-addressed database, not just a command-line tool.
• Know the difference between merge and rebase: merge preserves branch history; rebase rewrites local commits onto a new base.
• A pull request is a collaboration workflow in GitHub, not a Git primitive.
• Never rewrite public history unless the team has explicitly agreed, because other developers may have based work on it.
• Branch protection and required status checks are part of delivery safety, not bureaucracy.

FAQs

Why do we commit Kubernetes YAML?

Because ArgoCD needs Git to describe the desired cluster state. If it is not in Git, it is hard to audit, review, or reproduce.

Should Docker image tags be committed?

For GitOps, yes. Updating the image tag in a manifest is the handoff from CI to CD.

Should secrets be committed if they are base64 encoded?

No. Kubernetes Secret values are encoded, not encrypted. Use sealed secrets, external secrets, or a managed secret store.

What is the safest rollback?

Revert the commit that changed the manifest or image tag, then let ArgoCD sync the previous desired state.

Memorize vs Look-up

Mini Checklist

• Repository has a clear README.
• .gitignore is present.
• Main branch is protected.
• CI checks run on pull requests.
• Release tags match deployable image versions.

Project Implementation Journal

Baseline

We first made sure the application or configuration worked before introducing Git. A broken baseline makes every later automation failure harder to understand.

Local proof

We validated the Git workflow locally where possible, because local feedback is faster than waiting for CI or a cluster reconciliation loop.

Repository proof

We committed the Git change as a reviewable unit so the reason for the pipeline change was visible in Git history.

Automation handoff

We connected Git to the next tool in the chain instead of treating it as a standalone exercise.

Failure check

We intentionally inspected the common failure signals for Git: logs, status output, permissions, names, tags, and configuration paths.

Rollback thinking

We asked how to return to the previous working state if the Git change caused a bad deployment.

Interview compression

We reduced Git into a few sentences that explain purpose, implementation, and failure modes clearly.

Operations note

We documented what someone should check the day after the deployment, not only what to run during setup.

Decision Records

• Keep Git configuration in Git where it can be reviewed.
• Prefer explicit names over clever names: repository, image, namespace, workflow, and application names should be searchable.
• Use immutable versions for anything that can be deployed or rolled back.
• Put secrets in the platform secret store, not in code, documentation screenshots, or shell history.
• Automate only after the manual path is understood.
• Make the happy path visible, then document the first five things to check when it fails.
• Separate staging and production concerns before the project becomes too large.
• Choose boring defaults unless there is a real operational reason to customize.
• Write commands so they can be pasted into a terminal after replacing obvious placeholders.
• Treat dashboards, manifests, and workflow files as production code once people rely on them.

Failure Modes We Learned To Recognize

Wrong name

The most ordinary failures came from mismatched names: image repository, namespace, service selector, branch, workflow file, or dashboard variable.

Wrong permission

Automation failed when a token could read but not write, push but not pull, or access staging but not production.

Wrong version

A deployment looked successful while the cluster still ran an old image tag or an image tag that had been overwritten.

Wrong assumption

A command that worked locally failed in CI because the runner had a different shell, path, network, or credential context.

Missing feedback

Without logs, status commands, metrics, or dashboards, the system gave no quick answer about what changed.

Manual drift

Manual cluster edits solved a momentary problem but made the GitOps source of truth inaccurate.

Interview Drill Questions

• What problem does Git solve in this pipeline?
• What artifact or state does Git produce?
• Which tool consumes the output of Git next?
• What is the most likely beginner mistake with Git?
• How would you prove Git worked without guessing?
• How would you roll back a bad change involving Git?
• What should be memorized versus looked up for Git?
• Which security boundary matters most for Git?
• How would you explain Git to someone who only knows basic Linux?
• What metric, log, status, or command would you check first during an incident?

Glossary For This Stage

Artifact

A build output or configuration object that can be handed to another stage.

Desired state

The state declared in Git or YAML that controllers try to make real.

Reconciliation

The loop where a tool compares desired state with actual state and fixes differences.

Immutable version

A version reference that should never change meaning after publication.

Rollback

A controlled return to a previously known working state.

Drift

A difference between what Git says should exist and what is actually running.

Health

A status signal that says whether the service is ready and operating correctly.

Traceability

The ability to connect a running system back to a commit, workflow run, image, and manifest change.

Practical Runbook

Confirm source

Identify the exact repository, branch, commit, file path, or dashboard connected to Git.

Confirm identity

Check the account, token, kube context, registry namespace, or runner label before assuming the tool is broken.

Confirm version

Write down the version or tag you expected and compare it with the version the platform reports.

Confirm status

Use the native status command or UI first; it usually tells you whether the failure is configuration, permission, or runtime.

Confirm logs

Logs explain what happened after the tool accepted the configuration but the process still failed.

Confirm network

Many CI/CD failures are actually DNS, registry, cluster, firewall, or service discovery failures.

Confirm ownership

Know whether the application team, platform team, security team, or repository owner controls the failing setting.

Confirm rollback

Before changing more things, decide whether the quickest safe move is to revert, resync, rebuild, or redeploy.

Confirm documentation

After fixing the issue, add the command, symptom, and fix to the project notes so the next run is faster.

Confirm automation

If the Git step is repeated manually more than twice, turn it into a workflow, manifest, script, or checklist.

Verification Checklist

• Can I point to the exact Git commit connected to this Git change?
• Can I explain what changed in one sentence?
• Can I prove the change worked with a command or status screen?
• Can I identify the next tool that consumes this output?
• Can I identify the secret, token, or permission that would break this step?
• Can I roll back without manually editing production state?
• Can I tell whether the failure is build-time, deploy-time, or runtime?
• Can I show the relevant logs or metrics?
• Can I repeat the setup on a fresh machine or cluster?
• Can I teach this stage without reading every command from the page?