Ex 1:
3a: .git directory stores all the repo history, configs, and staging info.
6a: the file is in the staging area.
11b: because the changes are already staged. to see them we use git diff --staged.
14a: we can use as few as 4 characters of the commit id, as long as it’s unique.


Ex 3:
6b: the changes we made are discarded.
6c: yes, we could’ve used git restore instead of checkout.
8a: revert makes a new commit that undoes the changes, checkout just discards them.
8c: revert creates a new commit with the inverse changes.
10b: the commit was removed but the changes stayed staged.
10c: no, we don’t see the previous commit.
11a: the changes moved back to unstaged, commit gone.
11b: we used HEAD because we wanted to unstage the last commit’s changes, not move back.
11c: default scope is mixed (affects staging).
12a: both the working directory and commit history are reset to the chosen commit.
12b: git uses HEAD as default.
12c: it would’ve wiped out all the changes from step 9.


Ex 4:
1a: yes, we can do it in one command: git checkout -b feature-branch.
6a: rebase takes the commits from feature-branch and puts them on top of master; master is the base.
6c: the commits from feature-branch are replayed after master’s commits.
6d: merge keeps both histories with a merge commit, rebase rewrites the branch to look linear.
8e.i: the repo goes back to how it was before starting the rebase.
8e.ii: yes, we can repeat the rebase and finish it correctly.
9a: the graph is linear after the rebase.
9b: the changes from master are applied first, then our feature-branch commits on top.
9c: merge shows a branching structure, rebase looks like a straight line.