Version Control

Git is a distributed version control system: it records snapshots of a project's files as commits, each with a parent, forming a history you can inspect, revert, and branch. It lets many people work in parallel on isolated branches and merge their changes, while keeping a full local copy of the repository so most operations need no server.

merge joins two branches with a new merge commit, preserving the real history as a non-linear graph. rebase replays your commits onto a new base, rewriting them with new hashes to produce a linear history. Avoid rebasing commits already pushed and shared — rewriting published history forces everyone else to recover, since their copies now disagree with yours.

All three move the branch HEAD to the target commit; they differ only in reach. --soft moves HEAD alone, so changes stay staged. --mixed (default) also resets the index, leaving changes unstaged. --hard resets HEAD, index, and working tree, dropping uncommitted work. Reset rewrites the branch pointer — a local history edit, never for shared commits.

Stage the missed file, then git commit --amend -m 'fixed message'. Amend replaces the last commit, folding in the staged config.yml and the fixed message — it does not add a second commit. But amend rewrites that commit with a new hash, so once pushed and shared it forces a push --force that breaks others; only amend unpublished commits.

A branching model is an agreed convention for which branches exist and how changes flow between them. git-flow uses long-lived main and develop plus short-lived feature, release, and hotfix branches. It solves coordination: the team knows where work starts, how it stabilizes for a release, and how urgent fixes reach production without disrupting in-progress development.

git cherry-pick <commit> applies one specific commit's changes onto your current branch as a new commit with a new hash. Use it to port a fix between branches without merging the whole source branch — e.g. backporting a hotfix. Conflicts can occur; -x appends the original hash for traceability.

fetch downloads new commits from the remote into your remote-tracking branches but leaves your working branch untouched, so you can review before integrating. pull is fetch followed by a merge (or rebase) into the current branch, updating it in one step. A submodule is a nested repository pinned to a specific commit, letting one repo embed another at a fixed version.

git rebase <base> replays your commits onto a new base one-by-one, giving each a new hash and a linear history without a merge commit. Conflicts resolve per replayed commit. Interactive rebase (-i) lets you reorder, squash, edit, drop, or reword commits before replay, cleaning up a messy branch.

Add an inverse commit with git revert a1b2c3d, then git push. revert records the reverse diff of the bad commit as a new commit, so the broken change is undone while published commits stay in place. You add history, not rewrite it, so teammates just git pull — no force-push. Use reset or push --force only on local commits.