All Common Questions

Because pull solves only one part of the problem: fetching and integrating an upstream branch. It does not guarantee that you are on the branch you think you are on, that the upstream relationship is configured the way you assume, or that the resulting history shape matches your expectation. A steadier debugging path is to inspect `git branch -vv`, then `git log --oneline --graph --decorate --all`, and only then decide whether the mismatch is really about sync or about branch context.

The usual reason is that the remote branch already contains commits that your local branch does not. Git blocks a direct update because it would overwrite history from your point of view. The safe response is usually not to force-push immediately, but to fetch first, inspect divergence, and decide whether you need merge, rebase, or whether you are on the wrong branch entirely. Force push on a shared branch is almost never the right first move.

`--ff-only` is useful when you want one strict rule: only fast-forward this branch, and fail if real integration would be required. That makes it valuable on stable shared branches, release lines, or anywhere you want sync operations to stay explicit and unsurprising. Instead of silently creating a merge commit or taking another integration path, it stops and forces you to make the next decision consciously.

Because fetch separates observation from integration. You get to update your view of upstream without mutating the current branch yet. That pause gives you room to inspect whether the branch diverged, whether main moved, and whether merge, rebase, or ff-only is the right next step. For both beginners and teams, that separation usually lowers sync risk and reduces accidental history changes.

Often yes. The official `git reset` documentation explicitly points to `ORIG_HEAD` and related recovery flows after reset, merge, and pull. As long as the underlying objects have not been cleaned up yet, reflog is usually the first place to look before you decide whether to create a new branch or move a ref back.

A practical rule is that `revert` creates a new commit that cancels an earlier one, while `reset` moves a branch ref itself. That usually makes revert the safer tool for history that has already been shared, and reset the better tool for local cleanup, rollback, or branch reshaping before others depend on it. The real risk comes from using reset to rewrite history that other people have already pulled.

Reflog records ref movement history, not every action you ever took. When HEAD or a branch moves because of reset, rebase, merge, checkout-style actions, or similar operations, reflog often retains the previous positions for a while. That is why it can be so valuable: even if you moved a branch away from a commit, Git may still remember where that ref used to point, giving you a path back.

Because reflog entries and unreachable objects are not permanent storage. Once no ref keeps an object reachable and enough time passes for cleanup and garbage collection, Git may eventually remove it. That is why recovery is usually time-sensitive. If you suspect you lost something important, stop reshaping the repository and inspect reflog and ref state first instead of continuing with more destructive actions.

Not necessarily. The official `git switch` docs describe detached HEAD as a valid state for inspecting a commit or doing temporary experiments, where HEAD points to a commit instead of a branch name. If the work you do there is worth keeping, create a branch right away so those commits have a stable name.

The Pro Git book treats both as normal integration tools: merge preserves the branching structure, while rebase rewrites your commits onto a new base for a cleaner linear history. The important warning from the official book is not to rebase commits that have already left your repository and may be the basis of someone else’s work. A practical rule is rebase for local cleanup, merge for already-shared history.

The official `git switch` docs say Git aborts the operation if switching would lead to the loss of local changes. That is a safety feature, not an error condition. The usual safe options are to commit, stash, or only use `--discard-changes` when you intentionally want to throw those local changes away.

If the change is short-lived and not ready to become a named part of history, stash is often the lightest option. If the change already has a clear boundary and you want to preserve context, a normal commit is usually clearer. If the work may live longer, needs a name, or could turn into a real line of work, a temporary branch is often easier to track than a growing stash stack. The real decision is not command preference but whether the work deserves a durable name and place in history.