Fork an exercise repository and open a pull request from it

kind: drill

Fork htl-leonding-example/jg03-syp-git-basics, clone your fork, add the upstream remote, make a small change on a branch and open a pull request against the original. Then check with git remote -v that the two remotes point where you think they do.

Solution 
gh repo fork htl-leonding-example/jg03-syp-git-basics --clone
cd jg03-syp-git-basics
git remote -v
# origin    git@github.com:<you>/jg03-syp-git-basics.git      (fetch/push)
# upstream  git@github.com:htl-leonding-example/jg03-syp-git-basics.git

git switch -c feature/exercise-3
git commit -am "docs(exercise-3): record the four states of a file"
git push -u origin feature/exercise-3
gh pr create --repo htl-leonding-example/jg03-syp-git-basics --fill

Two checks tell you it worked. git push succeeds — it went to your fork, which you own. And the pull request page shows htl-leonding-example:main ← <you>:feature/exercise-3: two different repositories, which is precisely what a fork-based pull request is.

If git push is rejected with a permission error, you cloned the original instead of your fork. Fix the URL of origin with git remote set-url origin git@github.com:<you>/… rather than starting over.

Bring your fork back in step

kind: drill

Have somebody push a commit to the original repository, then update your fork’s main and start a new branch from it.

Solution 
git fetch upstream
git switch main
git merge upstream/main      # fast-forward, since you never commit on main
git push                     # your fork's main is level with the original
git switch -c feature/next

The merge is a fast-forward exactly as long as you did not commit on your fork’s main — which is the reason for the rule not to. If it is not a fast-forward, you have commits on main that belong on a branch.

gh repo sync does the same thing in one command; knowing the four steps underneath is what lets you repair it when the sync refuses.

Open a pull request against a partner’s repository

kind: drill

Pair up. Each of you adds a small change to the other’s practice repository on a branch and opens a pull request with a description that answers the three questions.

Solution 
git switch -c fix/typo-readme
git commit -am "docs(readme): repair the broken setup link"
git push -u origin fix/typo-readme
gh pr create --fill

The description matters more than the change here. Compare the two pull requests afterwards: the one you could review without asking a question is the one that did its job.

Review two pull requests, once badly and once well

kind: drill

Review your partner’s pull request twice: first with comments like "looks fine", then with concrete, located comments. Compare what the author can do with each.

Solution

The first review produces no action and no information. The second names a line, a condition and a suggested fix, so the author can act without a conversation. A review that cannot be acted on without a follow-up question is an unfinished review.

Split an oversized change

kind: drill

Take a branch that contains a rename plus a behaviour change and split it into two branches with one pull request each.

Solution

Create a new branch from main, cherry-pick or redo only the rename, open that pull request first; then rebase the behaviour change on top once the rename is merged. The point is visible in the diff: the second pull request now contains only lines that change what the program does.

Set up review in your team

kind: project

Enable branch protection on your project repository so main requires a pull request and a passing CI run.