Version Control and Git

Version control records the history of changes so you can return to any version; Git is a distributed VCS — every clone holds the full history; GitHub is just a host for Git repos.

Version control records changes to files over time so you know who changed what and when, and can return to an older version.

Type	How it works	Weakness
Local VCS	A version database on one machine	No collaboration; lose the machine, lose everything
Centralized (SVN)	One server holds history; clients check out from it	The server is a single point of failure; no commits offline
Distributed (Git)	Every client clones the whole repo with history	Very large repos clone slowly (shallow clones help)

flowchart LR
  subgraph C["Centralized"]
    S[("Server<br/>full history")] --- c1["Client"]
    S --- c2["Client"]
  end
  subgraph D["Distributed"]
    R[("GitHub<br/>origin")] --- d1[("Full clone")]
    R --- d2[("Full clone")]
    d1 -. "can push/pull directly" .- d2
  end

Git: a distributed, free, open-source and fast VCS for projects from tiny to huge. Committing, viewing logs and branching all work offline; every clone is a full backup.

Git ≠ GitHub: Git is the tool on your machine; GitHub (or GitLab, Bitbucket, Azure Repos) is a hosting platform for Git repos that adds pull requests, issues and CI. Git works fine without GitHub.

Three ways to start a repo: - git clone URL — fetch an existing repo (with its history); creates the origin remote. - git init -b main — create a new repo whose first branch is main (Git 2.28+). - git remote add origin URL — link a local repo to an empty repo on GitHub.

Traps: thinking a clone only downloads the latest version (it downloads the whole history); confusing Git with GitHub.

Command	Meaning
`git clone https://github.com/example-org/my-app.git`	Clone a repo
`git init -b main`	New repo with a `main` branch
`git remote add origin https://github.com/example-org/my-app.git`	Add a remote
`git remote -v`	Show remotes

Inside the `.git` folder

Everything Git knows lives in the hidden .git directory at the repository root: the object database (commits, trees, file contents), branches and tags under refs/, the staging index, and the configuration in .git/config. Deleting .git turns the folder back into plain files with no history. Never edit it by hand.

Setting up Git once

git config --global user.name "An Nguyen"
git config --global user.email an.nguyen@example.com
git config --global init.defaultBranch main
git config --global core.editor "code --wait"
git config --list --show-origin

Settings exist at three levels: --system, --global (your user), and --local (one repository), with the most specific winning.

Connecting to a remote: HTTPS or SSH

	HTTPS	SSH
URL	`https://github.com/example-org/my-app.git`	`git@github.com:example-org/my-app.git`
Authentication	Personal access token or credential manager (passwords are no longer accepted on GitHub)	SSH key pair, public key added to your account
Typical use	Corporate networks, quick start	Developers working daily

Create a key with ssh-keygen -t ed25519 -C "an.nguyen@example.com", add the .pub file to GitHub, and test with ssh -T git@github.com.

Large and sensitive files

Git keeps every version forever, so committing a 500 MB video or a password is hard to undo: even after deleting the file, it remains in history. Keep secrets out with .gitignore and secret scanning, and use Git LFS for large binary files such as design assets. A shallow clone (git clone --depth 1) downloads only the latest commit, which CI pipelines use to save time.

Where Git fits in DevOps

Git is the source of truth for the whole pipeline: application code, Dockerfiles, Kubernetes manifests, Terraform, and pipeline definitions all live in repositories. Every change is reviewed, traceable to an author, and reversible, which is what makes automation safe.