Git & Version Control Best Practices and Troubleshooting Syllabus

How can you recover a branch you accidentally deleted in Git?

Find the branch tip's commit hash using 'git reflog', then recreate the branch with 'git branch <name> <hash>' (or 'git checkout -b <name> <hash>').

What is the Git reflog, and why is it key to recovery?

The reflog is a local log recording every update to branch tips and HEAD; it lets you find and restore commits or branches that are no longer referenced by any branch, before garbage collection removes them.

How long does Git typically retain unreachable objects before garbage collection, by default?

Reachable-from-reflog entries expire after about 90 days, and unreachable objects after about 30 days (gc.reflogExpire and gc.pruneExpire defaults).

How do you recover a specific deleted commit whose hash you found in the reflog?

Reset or cherry-pick it: 'git reset --hard <hash>' to move the current branch back to it, or 'git cherry-pick <hash>' to reapply it onto the current branch.

What is a 'detached HEAD' state in Git?

A state where HEAD points directly at a specific commit rather than at a branch reference, so new commits are not attached to any branch and can be lost if you switch away.

How do you typically enter a detached HEAD state?

By checking out a specific commit, tag, or remote-tracking ref directly, e.g., 'git checkout <commit-hash>' or 'git checkout v1.0'.

How do you preserve work made in a detached HEAD state?

Create a branch pointing to the current commit before switching away: 'git switch -c <new-branch>' (or 'git branch <name>' followed by checkout).

How do you leave a detached HEAD without keeping any new commits?

Simply check out an existing branch, e.g., 'git switch main' (or 'git checkout main'); the detached commits become unreferenced.

How do you undo a merge that has NOT yet been pushed or shared?

Use 'git reset --hard ORIG_HEAD' (or the pre-merge commit hash) to move the branch back to its state before the merge.

How do you safely undo a bad merge that has already been pushed to a shared branch?

Use 'git revert -m 1 <merge-commit-hash>', which creates a new commit reversing the merge while preserving history; '-m 1' selects the mainline parent.

Why does reverting a merge commit require the '-m' (mainline) option?

Because a merge commit has two parents, Git cannot infer which parent's state to revert to, so '-m <parent-number>' specifies which parent line to keep as the mainline.

How do you abort a rebase that is in progress and running into conflicts?

Run 'git rebase --abort', which restores the branch to its original state before the rebase started.

How can you undo a rebase that has already completed, returning to the pre-rebase state?

Use the reflog to find the pre-rebase tip and reset to it: 'git reset --hard HEAD@{n}' (or the specific hash shown before the rebase).

What does it mean for two branches to have 'diverged'?

Both the local and remote (or two) branches have unique commits the other lacks since their common ancestor, so neither can be fast-forwarded to the other.

What are the two main strategies to reconcile a diverged local and remote branch during a pull?

Merge ('git pull --no-rebase', creating a merge commit) or rebase ('git pull --rebase', replaying local commits on top of the remote tip).

After branches diverge, why can a 'git push' be rejected, and what is the safe fix?

The push is rejected because the remote has commits you lack (non-fast-forward). The safe fix is to integrate remote changes first via 'git pull --rebase' (or merge), then push—avoid blind force-push.

What is the safer alternative to 'git push --force' when updating a rewritten branch, and why?

'git push --force-with-lease', which refuses to overwrite the remote if it has been updated since you last fetched, protecting against clobbering others' commits.

Describe a typical solo developer Git workflow.

Often a single main branch (or short-lived feature branches) with direct commits, frequent local commits, optional rebasing to keep history clean, and pushing to a single remote for backup—minimal ceremony since there is no review process.

Describe the core of a small team Git workflow (feature branch / GitHub Flow).

Each feature is developed on a short-lived branch off main, opened as a pull request for review and CI, then merged back to a always-deployable main; releases come directly from main.

What is Git Flow, and what long-lived branches does it define?

A branching model for scheduled releases using two permanent branches—'main' (production) and 'develop' (integration)—plus supporting 'feature/', 'release/', and 'hotfix/' branches.

Compare trunk-based development with Git Flow for enterprise scale.

Trunk-based development keeps all developers committing to a single main trunk with very short-lived branches and feature flags, favoring continuous integration; Git Flow uses multiple long-lived branches suited to versioned, scheduled releases but adds merge overhead.

What is the 'forking workflow' commonly used in large open-source/enterprise projects?

Each contributor forks the central repository into their own copy, pushes to their fork, and submits pull requests to the upstream; maintainers review and merge, keeping the canonical repo protected from direct pushes.

What are protected branches and branch protection rules in enterprise workflows?

Rules on key branches (e.g., main) that enforce policies like required reviews, passing status checks, up-to-date branches, signed commits, and disallowing force-pushes or deletions before merging.

Which tool is the standard bidirectional bridge for migrating from SVN to Git?

'git svn', which can clone an SVN repository into Git and sync commits in both directions.

What does 'git svn clone -s <url>' do, and what does the '-s' flag assume?

It clones an SVN repository into a Git repo; '-s' (--stdlayout) assumes the standard SVN layout of trunk/, branches/, and tags/ directories.

Why is an authors mapping file important when migrating from SVN to Git?

SVN records only usernames, so an authors file maps each SVN username to a proper Git 'Name <email>' identity, ensuring correct attribution in the migrated history.

How do you create a portable bundle of a repository for import/export or transfer without a network remote?

Use 'git bundle create <file.bundle> <refs>' to package commits into a single file, then clone or fetch from it with 'git clone <file.bundle>' or 'git fetch <file.bundle>'.

What is the difference between a normal 'git clone' and 'git clone --mirror'?

A normal clone copies the default branch and sets up a working tree; '--mirror' creates a bare repository copying all refs (branches, tags, remotes) exactly and configures it to mirror the source for backups.

How do you keep a mirror backup repository up to date with its source?

In the bare mirror clone, run 'git remote update' (or 'git fetch --all') periodically; combined with 'git push --mirror' you can also propagate to another remote.

What is the difference between a bare and a non-bare Git repository, and where is each used?

A bare repository (created with 'git init --bare') has no working directory and stores only the Git data; it is used as a shared/central remote and for mirrors/backups, whereas a non-bare repo has a checked-out working tree for development.