Search
5 results for “version-control”
Search results
Git Fundamentals
How the working directory, staging area, and commit history actually relate to each other, and why understanding that three-stage model makes branching, rebasing, and undoing changes stop feeling arbitrary.
What is the difference between the working directory, the staging area, and a commit in Git?
The working directory is the actual files on disk, whatever state you've left them in. The staging area (the "index") is a snapshot of exactly what will go into the next commit; `git add` copies changes from the working directory into it, one file or hunk at a time, which is why you can commit only part of what you've changed. A commit is a permanent, immutable snapshot of the staging area at the moment you ran `git commit`, plus a pointer to its parent commit, which is what forms the project's history graph. Understanding that staging is a separate, explicit step - not just "what's changed" - explains why `git status` shows both staged and unstaged changes for the same file.
What is the practical difference between `git merge` and `git rebase`?
Both bring one branch's commits into another, but they produce different history shapes. `git merge` creates a new merge commit with two parents, preserving exactly how the branches diverged and came back together; nothing is rewritten, which is why merge is safe on shared/public branches. `git rebase` replays your branch's commits one by one on top of the target branch's tip, producing a linear history with no merge commit, but every replayed commit gets a new hash. That rewriting is why rebase should be avoided on branches other people have already pulled; their history and yours will diverge as soon as they fetch the rewritten commits.
What is the difference between `git reset` and `git revert`, and when should you use each?
git reset moves the current branch pointer (and optionally the staging area and working directory) to a different commit, effectively rewriting history as if the reset-past commits never happened on this branch - fine for commits that only exist locally and haven't been pushed. git revert creates a brand new commit that applies the inverse of a previous commit's changes, leaving history intact and additive. Because it doesn't rewrite anything, revert is the safe choice for undoing a commit that's already been pushed and pulled by others; reset --hard on shared history causes exactly the same divergence problem as a rebase on a shared branch.
What is the Filesystem Hierarchy Standard, and why does it matter that /etc, /var, and /usr are separate directories rather than one flat structure?
The FHS is a specification for where files belong on a Unix-like system, so that any compliant distribution places configuration, variable data, and installed software in predictable locations regardless of vendor. Separating them matters operationally: /etc holds host-specific configuration that should be backed up and version-controlled, /var holds logs, caches, and other data that grows and changes constantly and often lives on its own disk or partition for capacity/IO reasons, and /usr holds installed programs and libraries that are typically read-only at runtime and can be shared or mounted the same way across many machines. Collapsing them into one flat structure would make it much harder to back up only what matters, mount storage with the right characteristics per use case, or reason about what's safe to wipe and reinstall.