Handling PR feedback and updates in Git - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a Pull Request (PR) in Git?

A Pull Request is a way to ask team members to review and merge your code changes into the main project branch. It helps keep code organized and reviewed before adding it.

beginner

How do you update your PR branch after receiving feedback?

You make changes locally, commit them, and then push the updates to the same branch. The PR will automatically update with your new commits.

intermediate

What command do you use to fetch the latest changes from the main branch before updating your PR branch?

Use `git fetch origin` to get the latest changes, then `git rebase origin/main` to apply your changes on top of the updated main branch.

intermediate

Why is it important to rebase your PR branch before merging?

Rebasing keeps your branch up to date with the main branch and creates a clean, linear history. This makes it easier to review and avoids merge conflicts.

beginner

How do you respond to feedback that requires multiple changes?

Make each change in your local branch, commit them with clear messages, and push all commits to the PR branch. This keeps feedback organized and easy to track.

What happens when you push new commits to a branch with an open PR?

A The PR closes automatically.

B You must create a new PR for the new commits.

C The new commits are ignored.

D The PR updates automatically with the new commits.

When you push new commits to the branch linked to a PR, the PR updates automatically to include those commits.

Which command updates your local branch with the latest changes from the main branch?

A git rebase origin/main

B git push origin main

C git clone main

D git commit --amend

The command 'git rebase origin/main' applies your changes on top of the latest main branch, updating your branch.

Why should you keep commit messages clear when updating a PR?

A To make the commit history confusing.

B To help reviewers understand what changed.

C To avoid pushing changes.

D To delete previous commits.

Clear commit messages help reviewers quickly understand the purpose of each change.

What is the best practice if your PR branch has conflicts with the main branch?

A Push your branch without resolving conflicts.

B Delete your branch and start over.

C Rebase your branch onto the main branch and resolve conflicts.

D Ignore the conflicts and merge anyway.

Rebasing and resolving conflicts ensures your branch is compatible with the main branch before merging.

How do you handle multiple rounds of feedback on a PR?

A Make changes, commit, and push updates to the same PR branch.

B Close the PR and open a new one for each change.

C Ignore the feedback.

D Delete your branch after each change.

You update the same PR branch with new commits for each round of feedback to keep the review process smooth.

Explain the steps to update your PR branch after receiving feedback.

Think about how you work on your computer and share changes with your team.

Describe why rebasing your PR branch before merging is helpful.

Imagine organizing papers in a neat stack before handing them over.

Practice

1. When you receive feedback on a pull request (PR), what is the first step to update your code accordingly?

easy

A. Check out the feature branch locally to make changes

B. Merge the main branch into your feature branch without changes

C. Close the PR and create a new one

D. Delete the feature branch and start over

Solution

1. Step 1: Switch to the feature branch

   You need to work on the branch where the PR was created to apply feedback changes.

2. Step 2: Make the necessary code updates

   After switching, edit the code to address the feedback.

3. Final Answer:

   Check out the feature branch locally to make changes -> Option A

4. Quick Check:

   Update code on feature branch = A [OK]

Hint: Always update code on the feature branch first [OK]

Common Mistakes:

• Trying to update main branch instead of feature branch
• Closing PR unnecessarily
• Starting a new branch without reason

2. Which git command correctly stages all changed files before committing updates for a PR?

easy

A. git commit -a -m "Update code"

B. git checkout -b update-branch

C. git push origin main

D. git add .

Solution

1. Step 1: Stage all changes

   The command git add . stages all modified and new files in the current directory.

2. Step 2: Commit the staged changes

   After staging, you use git commit -m "message" to save changes locally.

3. Final Answer:

   git add . -> Option D

4. Quick Check:

   Stage all changes = git add . [OK]

Hint: Use 'git add .' to stage all changes before commit [OK]

Common Mistakes:

• Using git commit -a without staging new files
• Pushing before committing
• Creating new branches unnecessarily

3. Given the following commands run in sequence on a feature branch:

git add file.txt
git commit -m "Fix typo"
git push origin feature-branch

What happens to the existing pull request linked to feature-branch?

medium

A. A new pull request is created

B. The pull request updates automatically with the new commit

C. The pull request is closed

D. Nothing changes until you merge manually

Solution

1. Step 1: Push updates to the feature branch

   Pushing commits to the branch linked to the PR updates the PR automatically.

2. Step 2: PR reflects new commits

   The PR shows the new changes for reviewers to see and re-review.

3. Final Answer:

   The pull request updates automatically with the new commit -> Option B

4. Quick Check:

   Push to feature branch updates PR = A [OK]

Hint: Push changes to update existing PR automatically [OK]

Common Mistakes:

• Thinking a new PR is needed for each update
• Believing PR closes on push
• Assuming manual merge needed to update PR

4. You tried to push updates to your feature branch but got this error:
! [rejected] feature-branch -> feature-branch (non-fast-forward)
What is the best way to fix this?

medium

A. Pull latest changes from remote and rebase before pushing

B. Delete the remote branch and push again

C. Force push with git push --force

D. Create a new branch and push there

Solution

1. Step 1: Fetch and rebase remote changes

   Run git pull --rebase origin feature-branch to update your local branch with remote changes without merge commits.

2. Step 2: Push the rebased branch

   After rebasing, push your changes normally with git push origin feature-branch.

3. Final Answer:

   Pull latest changes from remote and rebase before pushing -> Option A

4. Quick Check:

   Fix non-fast-forward by rebasing and pushing = C [OK]

Hint: Rebase remote changes before pushing to avoid errors [OK]

Common Mistakes:

• Using force push without caution
• Deleting remote branch unnecessarily
• Creating new branches instead of syncing

5. You have multiple commits in your feature branch but want to combine them into one clean commit before updating the PR. Which sequence of commands achieves this?

hard

A. git merge main; git commit -m "Clean update"; git push

B. git rebase -i main; edit commits; git push

C. git reset --soft HEAD~3; git commit -m "Clean update"; git push --force

D. git checkout main; git cherry-pick feature-branch; git push

Solution

1. Step 1: Soft reset last 3 commits

   git reset --soft HEAD~3 moves HEAD back but keeps changes staged, allowing to combine commits.

2. Step 2: Create a single new commit and force push

   Commit staged changes with a new message, then force push to update PR with one clean commit.

3. Final Answer:

   git reset --soft HEAD~3; git commit -m "Clean update"; git push --force -> Option C

4. Quick Check:

   Combine commits by soft reset and force push = B [OK]

Hint: Use soft reset and force push to squash commits [OK]

Common Mistakes:

• Using merge instead of squash
• Forgetting to force push after rewriting history
• Incorrectly rebasing without editing commits