Version Control and Developer Tooling Questions

Direct answer

Git LFS (Large File Storage) fixes slow, binary-heavy CI builds by replacing large files in git's own history with small text pointer files, the actual file content lives in a separate LFS store, so every git clone or git fetch only ever moves the lightweight pointers through git itself, staying fast even though the repository "contains" gigabytes of binaries. Migrating files that are already committed requires rewriting history, the same disruptive, coordinate-with-the-team operation as any other history rewrite.

Structured elaboration

How it works day to day. git lfs track "*.psd" writes a rule into .gitattributes (*.psd filter=lfs diff=lfs merge=lfs -text). From that point forward, committing a matching file actually commits a tiny pointer file into git's normal history (a few lines of text: an LFS version marker, a content hash, and the file size), while the real bytes upload to the LFS server on push. On checkout, the LFS client transparently swaps the pointer back for the real file content in your working directory, so day-to-day usage looks identical to normal git.

Migrating files already in history. LFS tracking rules only apply going forward, files already committed as full blobs stay full blobs in every historic commit, the tracking rule doesn't retroactively touch them. git lfs migrate import --include="*.psd" --everything rewrites all commits, replacing matching blobs with LFS pointers retroactively. This changes every affected commit's hash from that point in history forward, exactly the same shared-history risk as any rebase or git filter-repo run.

Operational considerations for an active repo:

• Rewriting history means every existing clone or fork is now out of sync with the rewritten repo, requiring a coordinated cutover where every contributor re-clones or hard-resets to the new history rather than trying to merge the old and new.
• The LFS server has its own storage and bandwidth costs, on hosted platforms like GitHub, LFS storage and bandwidth are often billed or quota-limited separately from the git repository itself.
• CI runners need to actually pull LFS content (git lfs pull, or an LFS-aware clone step), otherwise they silently check out pointer files instead of real binaries and builds fail in a confusing way that doesn't look like an LFS problem at first glance.

Worked example

Adopting LFS going forward (illustrative):

git lfs install
git lfs track "*.psd"
git add .gitattributes
git add design/mockup.psd
git commit -m "add mockup via LFS"
git push origin main

Migrating files already in history (illustrative, always run on a disposable clone first):

git lfs migrate import --include="*.psd" --everything
git push --force origin main   # rewrites history, coordinate with the team before running this

Trade-offs and pitfalls

The clone-time win is real, but it shifts cost rather than eliminating it: checkout now depends on the LFS server being reachable and fast, a slow or down LFS endpoint blocks checkouts that would otherwise have succeeded from git's own storage. Migrating existing history is a one-time, disruptive, whole-team event, not something to run casually or repeatedly, every re-run with different flags produces yet another incompatible history. Forgetting the CI-side git lfs pull step is one of the most common LFS adoption mistakes, a build that "randomly" fails on a missing asset is often actually a checkout that only ever received pointer files.

Direct answer

git blame <file> (git annotate is essentially the same underlying operation, presented slightly differently) shows, for every line currently in a file, which commit last touched it, along with that commit's author and date, by walking the file's history backward line by line. It's how you answer "who wrote this and why" without opening the full commit log. Its main limitation is that it attributes a line to whichever commit last touched it, so history-rewriting operations like rebase, squash, or a repo-wide reformat can point blame at a commit that isn't the real, meaningful origin of that line.

Structured elaboration

How blame works: for each line in the current version of a file, git finds the most recent commit that changed it, and reports that commit's hash, author, date, and (with the right flags) the original line content.

Limitations under history rewriting:

• A rebase or squash that folds several small commits into one collapses each small commit's individual reasoning (its own message) into a single combined commit. Blame still points at a real, meaningful commit, but you lose the granular "why" that used to live in each separate step.
• A large mechanical commit, most commonly a repo-wide reformat or a bulk rename, makes blame point at that reformat commit for every line it touched, even though the actual logical author and reasoning is much older. This is the most disruptive case in practice, because it can bury real authorship under an unrelated, uninformative commit.
• Squashing before merge (a common practice for a clean history) means blame after the squash points at the merged commit rather than at whichever of the original WIP commits actually introduced a given line.

Strategies to maintain traceability:

• git blame -w ignores whitespace-only changes when attributing a line.
• git blame --ignore-rev <hash>, or better, a repo-wide .git-blame-ignore-revs file (supported since Git 2.23) listing commit hashes that blame should skip over entirely when walking back, configured once with git config blame.ignoreRevsFile .git-blame-ignore-revs. This is the standard fix for the reformat-commit problem: list the reformat commit's hash, and blame walks straight past it to the real prior change.
• git log --follow <file> tracks a file's history across renames, useful alongside blame since blame alone doesn't always surface a rename boundary clearly.
• At the process level, even if individual "wip"/"fix typo" commits get squashed away, make sure the final squashed commit's message is itself informative (references the ticket/PR, explains the actual reasoning), so that even post-squash, blame at least points at a commit that tells you something real, rather than a generic "fixes."

Worked example

.git-blame-ignore-revs:

# Reformat entire codebase with the new formatter, 2026-03-01
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

git config blame.ignoreRevsFile .git-blame-ignore-revs

After this, git blame on a file that was touched by that reformat commit skips straight past it and attributes each line to whatever commit last meaningfully changed it before the reformat.

Trade-offs and pitfalls

.git-blame-ignore-revs only helps for tools and workflows that respect it (recent git, GitHub, GitLab all do; older tooling might not), so it's not a universal fix, more a convention worth adopting deliberately and documenting for the team. Relying purely on commit-message discipline to preserve traceability through squashes is fragile, it depends on every contributor actually writing a good final message, whereas --ignore-rev is a mechanical fix that works regardless of message quality. Neither technique restores information that was never captured in the first place, if the original small commits genuinely never explained their reasoning, squashing them just makes that gap more visible, it doesn't create the gap.

Direct answer

git merge combines two branches by creating (or fast-forwarding to) a commit with two parents, preserving the exact history of what actually happened, including when the branches diverged. git rebase rewrites your branch's commits one by one on top of a new base, producing a linear history as if you had started your work from the target branch's latest commit. Use merge for shared or public branches, and to preserve the true chronological record; use rebase to clean up your OWN not-yet-shared feature branch before it is reviewed or merged.

Structured elaboration

• Effects on commit history: merge adds a merge commit (an extra node with two parents) and leaves the branch's original commits untouched, so the history literally shows when and how two lines of work joined. Rebase replaces the branch's original commits with new ones (same content, new hashes and a new parent), producing a straight line, at the cost of that history no longer reflecting when the work actually diverged.
• Conflict resolution: merge resolves all accumulated conflicts once, in a single merge step. Rebase can require resolving the same conflict repeatedly, once per replayed commit, if several commits touch the same lines. That is more tedious on a long-diverged branch, but each individual conflict is scoped to a smaller, more understandable diff.
• Code review ergonomics: rebasing a branch that is already under review invalidates the diff reviewers were looking at (new commit hashes), and a force-push can silently disconnect review comments from the old commits on some tools. Teams commonly agree "no rebasing mid-review" for this reason, but DO rebase (or otherwise clean up) a branch BEFORE opening the pull request, so what reviewers see is already a clean, logical set of commits.
• Pitfalls: rebase requires a force-push (git push --force-with-lease, never a bare --force) to update a branch whose history you rewrote. That is dangerous on any branch someone else might also be working from, since it can strand or silently discard their local commits if they later force-push over yours. Never rebase a branch other people have already pulled and built work on top of, that is the one hard rule.

Worked example

This is a real, reproducible git session, run exactly as shown; your own commit hashes will differ every time you run it, since hashes are content- and timestamp-derived, but the shape of the history will match.

$ git init -q && git config user.email you@example.com && git config user.name You
$ echo line1 > file.txt && git add file.txt && git commit -qm "initial commit"
$ git checkout -qb feature/login
$ echo "login work 1" >> file.txt && git commit -qam "add login step 1"
$ echo "login work 2" >> file.txt && git commit -qam "add login step 2"
$ git checkout -q main
$ echo "main hotfix" >> readme.txt && git add readme.txt && git commit -qm "hotfix on main"

$ git log --all --oneline --graph
* f6a4e94 add login step 2
* 3f1b249 add login step 1
| * b203e9a hotfix on main
|/
* d00f83b initial commit

Merge:

$ git checkout -qb merge-demo main && git merge --no-edit feature/login
$ git log --oneline --graph
*   8d0f96b Merge branch 'feature/login' into merge-demo
|\
| * f6a4e94 add login step 2
| * 3f1b249 add login step 1
* | b203e9a hotfix on main
|/
* d00f83b initial commit

Rebase, from a fresh branch off feature/login:

$ git checkout -qb rebase-demo feature/login && git rebase main
$ git log --oneline --graph
* 80d6191 add login step 2
* 229c32c add login step 1
* b203e9a hotfix on main
* d00f83b initial commit

The merge history keeps both lines of development visible with a two-parent commit; the rebase history is a single straight line as though "login step 1" and "login step 2" were written after the hotfix.

Trade-offs & pitfalls

"Lost commits" after a rebase usually means a teammate had local commits based on the OLD (pre-rebase) branch tip, and either force-pushed over the new history or kept building on a branch tip that no longer exists remotely. --force-with-lease (which refuses to push if the remote moved since you last fetched) is a safeguard against silently clobbering that, not a substitute for the underlying rule: do not rebase a branch others have already pulled.

Direct answer

git reflog is a local, per-repository log of every place HEAD and branch tips have pointed, kept for a limited time as a personal safety net; it is not shared or pushed to the remote. It lets you find the commit hash the deleted branch used to point at, as long as some local clone had that branch checked out or fetched recently. From there, recreating the branch and pushing it restores the remote.

Structured elaboration and worked example

1. Find the commit hash locally:

git reflog show feature-x

This lists recent positions of feature-x's tip on this machine, most recent first, each with a commit hash. If the branch was never checked out or fetched on your machine, your local reflog won't have it; check whether a teammate's clone or your CI system's checkout does.

2. If no local reflog has it, check whether the remote's own ref list or CI logs retained the commit hash (git's short-form identifier for a commit, sometimes called a SHA) even after the branch pointer itself was deleted:

git ls-remote origin | grep feature-x

This only helps if the ref still resolves; once it's truly deleted it won't show up here, which is why the reflog approach is usually the real answer.

3. Confirm you have the right commit before recreating anything:

git show abc1234

4. Recreate the branch locally at that commit and push it back to the remote:

git branch feature-x abc1234
git push origin feature-x

Trade-offs and pitfalls

The reflog only exists locally and only for a limited retention window; git periodically expires old reflog entries, and git gc can prune commits that are no longer reachable from anything, including an expired reflog entry. The longer it's been since the branch was deleted, the less likely this recovery path works. If the branch had already been merged before deletion, its commits are also still reachable from whatever branch it was merged into, which is a second, often easier recovery path worth checking first. Recreating and pushing is safe as described, but if the remote branch somehow still exists and has diverged, pushing over it needs --force-with-lease, not a bare --force, to avoid clobbering someone else's newer work.

Direct answer

The three strategies differ in what the resulting commit history looks like, which in turn affects how bisectable it is (usable by git bisect, git's binary-search tool for finding which commit introduced a bug) and how useful git blame (git's per-line "who last touched this and in which commit" tool) is on it afterward.

Structured elaboration

A fast-forward merge is only possible when the target branch's tip is a direct ancestor of the branch being merged in, so git can simply move the pointer instead of creating a new commit. git merge --no-ff forces a merge commit even when a fast-forward would have been possible, specifically to preserve that visible boundary. A squash merge (git merge --squash feature) stages the branch's combined diff without creating a commit at all; you then run git commit yourself once, to create the single new commit.

Worked example

Say a feature branch has three commits: add validation, fix typo, wip.

• With a merge commit, main gets a new commit with two parents, and all three original commits remain individually visible in git log --graph.
• With a squash merge, main gets exactly one new commit containing the combined diff of all three; fix typo and wip never appear in main's history at all.
• With a fast-forward, all three commits appear individually (assuming main hadn't moved since the branch was created), but with no merge commit marking where the branch started or ended.

Trade-offs and pitfalls

Using --no-ff on every merge can make history noisy on a fast-moving, trunk-based repository with many small branches. Squashing means git bisect lands on one commit that "did everything", so if that commit is large, bisect narrows the failure down to a whole feature rather than a specific line, and you still have to read the diff by hand from there. Teams that squash routinely tend to lean on descriptive pull request titles and descriptions to make up for losing the individual commit messages.