Git/GitHub Flashcards

(76 cards)

1
Q

What are the 4 main Git states/areas in a typical workflow?

A

Working directory (your files), Staging area/Index (what will be committed), Local repository (your commit history), Remote repository (shared repo, e.g., origin on GitHub).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is a commit in Git (conceptually)?

A

A commit is a snapshot of the project state (the staged content) plus metadata (author, message, parent commit(s)).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is a branch in Git (conceptually)?

A

A branch is a movable pointer (reference) to a commit; it represents a line of development.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What is HEAD in Git?

A

HEAD points to the currently checked-out commit/branch—your current position in history.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Why is constructor injection preferred over field injection in many codebases (Git collaboration angle)?

A

Constructor injection makes dependencies explicit and encourages small, testable units—this leads to smaller, clearer changes and PRs that are easier to review.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

What is a Pull Request (PR) in GitHub?

A

A request to merge changes from one branch into another, with discussion, review, and automated checks (CI) before integration.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What makes a PR ‘good’ and easy to review?

A

Small scope, clear description (what/why/how), tests included, minimal unrelated formatting changes, notes on edge cases and risks.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What should you focus on during code review?

A

Correctness, readability, maintainability, edge cases, performance hotspots, security concerns, and meaningful tests.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

What is ‘branch protection’ in GitHub?

A

Rules that protect important branches (e.g., main): requiring PRs, passing CI checks, approvals, preventing force pushes, etc.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

What is the difference between merge and rebase (high level)?

A

Merge combines histories (often creating a merge commit). Rebase rewrites commits to apply them on top of another base, producing a linear history.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

When is merge a good choice?

A

When you want to preserve the context of how features were integrated, or when team policy prefers merge commits.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

When is rebase a good choice?

A

Before opening/updating a PR to keep a clean linear history and resolve conflicts early—especially for local feature branches.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Why is rebasing shared branches risky?

A

Rebase rewrites commit history; teammates who pulled the old history will have conflicts and confusion unless coordinated.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What is a fast-forward merge?

A

A merge where the target branch pointer simply moves forward because it’s an ancestor of the source—no merge commit needed.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

What is ‘squash merge’?

A

Merging a PR by combining all its commits into a single commit on the target branch, keeping main history clean.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Squash merge: pros and cons?

A

Pros: clean history, one commit per PR. Cons: loses intermediate commit details; harder to trace granular steps.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Merge commit: pros and cons?

A

Pros: preserves exact branch history and context. Cons: can make main history noisy.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Rebase-merge in GitHub: what is it?

A

GitHub can rebase the PR commits onto the target branch and then fast-forward, producing a linear history without a merge commit.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

What is the difference between git fetch and git pull?

A

fetch downloads remote refs/commits without merging. pull = fetch + integrate (merge or rebase depending on configuration).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

What does git pull --rebase do?

A

Fetches remote changes then rebases your local commits on top of the updated upstream branch to keep history linear.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

What does git status tell you?

A

Current branch, staged changes, unstaged changes, untracked files, and next actions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

What does git diff show?

A

Line-by-line changes between working directory and index (or between other refs depending on flags).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Why is git add -p useful?

A

It lets you stage changes interactively (hunk-by-hunk), enabling focused commits and cleaner PRs.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

What is a ‘clean commit’?

A

A commit that contains one logical change, with a clear message and minimal unrelated edits.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
What’s a good commit message structure (simple)?
Imperative, short summary + optional body explaining why and any constraints. Example: 'Fix null handling in user lookup'.
26
What is the difference between `git reset` and `git revert` (most important)?
`reset` moves branch pointer (can rewrite history). `revert` creates a new commit that undoes a previous commit (safe for shared history).
27
When should you prefer `git revert`?
When the commit is already pushed/shared (especially on main). It preserves history and is safer for teams.
28
When is `git reset` appropriate?
For local commits that haven’t been shared yet, to edit/squash/reorder history before pushing.
29
Explain `git reset --soft`.
Moves HEAD to another commit but keeps changes staged (in the index). Useful to recombine commits.
30
Explain `git reset --mixed` (default).
Moves HEAD and keeps changes in working directory but unstaged.
31
Explain `git reset --hard`.
Moves HEAD and discards staged + working directory changes. Dangerous; use carefully.
32
What is `git restore` used for?
To discard changes in the working directory or to unstage changes (restore from index/commit).
33
What is `git stash` used for?
Temporarily saves uncommitted changes so you can switch branches or pull/rebase cleanly, then reapply later.
34
Common pitfall with `git stash`?
Forgetting what you stashed or losing context; use messages (`git stash push -m ...`) and list (`git stash list`).
35
What is a merge conflict?
A situation where Git cannot automatically combine changes because two branches modified overlapping lines/regions.
36
Basic steps to resolve a merge conflict safely?
1) Pull/rebase latest main, 2) open conflict markers, 3) choose/merge intent, 4) run tests, 5) commit resolution.
37
How can you reduce merge conflicts?
Keep PRs small, rebase/merge frequently, avoid long-lived branches, coordinate changes to same files.
38
What is `git cherry-pick`?
Applies a specific commit (or range) from one branch onto another.
39
When is cherry-pick commonly used?
Backporting a hotfix to a release branch or pulling a small fix without merging an entire feature branch.
40
Downside of cherry-picking?
Can duplicate commits across branches and complicate future merges if not tracked carefully.
41
What is `git log --oneline --graph --decorate` useful for?
Visualizing branch structure quickly: compact commit list, graph, and branch/tag pointers.
42
What is `git blame` used for?
Shows which commit/author last changed each line—useful for understanding context and intent.
43
How should you use `git blame` responsibly?
As a debugging/context tool, not for blaming people; follow up by reading the commit message/PR discussion.
44
What is `git bisect`?
A binary search tool to find the commit that introduced a bug/regression by marking commits good/bad.
45
Basic `git bisect` workflow?
Start bisect, mark current as bad, mark a known-good commit, then test each checked-out midpoint commit and mark good/bad until culprit is found.
46
Why is `git bisect` valuable in production debugging?
It can quickly identify the exact change that introduced a regression, saving time when the diff range is large.
47
What is a ‘hotfix’ branch strategy?
Branch off main/release, apply minimal fix, PR + fast review, merge/deploy, then backport as needed.
48
What does “don’t rewrite shared history” mean?
Avoid rebasing or force-pushing branches others depend on (e.g., main) because it changes commit IDs and breaks collaborators’ clones.
49
What is a ‘force push’ and why is it risky?
`git push --force` overwrites remote branch history; it can delete others’ commits or cause confusion.
50
When is force push acceptable (if ever)?
Sometimes on your own feature branch if team allows and you coordinate, never on protected branches like main.
51
What is the difference between `origin` and `upstream` remotes?
`origin` is typically your fork/primary remote. `upstream` often refers to the original repository you forked from.
52
What does `git remote -v` show?
The configured remotes and their fetch/push URLs.
53
What is a ‘detached HEAD’ state?
You checked out a commit directly (not a branch). Commits made here can be lost unless you create a branch.
54
How do you recover from detached HEAD after making commits?
Create a branch pointing to your current commit: `git switch -c my-branch` (or `git checkout -b my-branch`).
55
What is the difference between tags and branches?
Tags are usually fixed pointers (often for releases). Branches move as new commits are added.
56
Why do teams enforce CI checks on PRs?
To prevent merging failing builds/tests, catch regressions early, and maintain quality gates.
57
What should run in CI vs CD (basic)?
CI: build + unit tests + lint + security scans. CD: deploy to environments, run smoke/integration tests, promote/rollback.
58
What is an ‘immutable build artifact’ concept?
Build once, deploy the same artifact across environments (dev→staging→prod) to reduce ‘works in staging’ mismatches.
59
How do you handle a bad commit already merged into main?
Revert it (new commit that undoes it), then follow with a corrected PR if needed.
60
What’s a sensible approach to keep main branch stable?
Small PRs, mandatory reviews, CI checks, feature flags when needed, quick revert/rollback capability.
61
What is ‘trunk-based development’ (basic)?
A workflow where developers integrate small changes frequently into main (or short-lived branches) to reduce merge pain.
62
What is GitFlow (basic)?
A branching model with long-lived branches like develop/release/hotfix; more process-heavy than trunk-based.
63
Which is better: trunk-based or GitFlow?
Depends on team/release process; trunk-based reduces merge conflicts, GitFlow can fit strict release cycles but adds overhead.
64
What is a PR template and why is it useful?
A standard PR form (description, testing, screenshots, risk) that improves review quality and consistency.
65
What is CODEOWNERS in GitHub?
A file that assigns ownership of paths; owners can be automatically requested for review.
66
How do you write a strong PR description?
Explain the problem, the solution approach, how to test, and any risks/rollout notes.
67
What is a ‘rollback’ vs a ‘revert’?
Rollback usually refers to undoing a deployment to a previous build/version. Revert is a Git commit that undoes changes in code history.
68
Why keep commits/PRs small?
Easier review, fewer conflicts, simpler debugging, faster feedback, less risk per change.
69
Common Git command to see where a commit exists across branches?
`git branch --contains ` shows which branches contain the commit.
70
What’s a practical strategy for resolving conflicts during rebase?
Resolve one conflict at a time, run tests often, and use `git rebase --continue`. If it’s messy, abort and reconsider approach.
71
How to abort a rebase safely?
`git rebase --abort` returns you to the state before the rebase started.
72
How to abort a merge safely (before commit)?
`git merge --abort` (or reset to previous state if needed).
73
What is `git reflog` used for?
A local log of where HEAD and branches pointed—useful to recover lost commits after reset/rebase mistakes.
74
How do you recover a commit after an accidental hard reset?
Use `git reflog` to find the commit hash, then create a branch or reset back to it.
75
What’s a safe default rule for novices: revert vs reset?
If it’s shared/pushed: revert. If it’s local/unpushed: reset (carefully).
76
How does good Git hygiene help debugging?
Clean commits and PRs make `git bisect`, `git blame`, and history reviews more effective and faster.