Handling PR feedback and updates in Git - Deep Dive

Overview - Handling PR feedback and updates

What is it?

Handling PR feedback and updates means managing the comments and change requests you get after submitting your code for review in a Pull Request (PR). It involves reading feedback, making changes to your code, and updating the PR so others can see your improvements. This process helps teams collaborate smoothly and keep code quality high.

Why it matters

Without handling PR feedback properly, code reviews become confusing and slow. Changes might get lost, or reviewers might not see your updates, causing delays and frustration. Good feedback handling keeps the project moving forward, improves code quality, and builds trust among team members.

Where it fits

Before this, you should know how to create and submit a Pull Request using git and a platform like GitHub or GitLab. After mastering feedback handling, you can learn advanced git workflows like rebasing, squashing commits, and automating PR checks.

Mental Model

Core Idea

Handling PR feedback is a cycle of receiving comments, updating your code, and sharing those updates clearly so the team can approve your changes.

Think of it like...

It's like submitting a homework assignment to a teacher, getting notes on what to fix, making those fixes, and then handing in the improved version for final approval.

┌───────────────┐
│ Submit PR    │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Receive       │
│ Feedback      │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Make Changes  │
│ Locally       │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Update PR     │
│ (push commits)│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Reviewers See │
│ Updates       │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

What is a Pull Request

Concept: Understanding what a Pull Request (PR) is and its role in collaboration.

A Pull Request is a way to ask your team to review and merge your code changes into the main project. It shows your code, lets others comment, and helps keep the project organized.

Result

You know that a PR is the starting point for feedback and collaboration on code changes.

Understanding the PR concept is essential because feedback and updates revolve around this shared workspace for code review.

2

Foundation

How to Submit a PR

Concept: Learning the basic git commands and platform steps to create a PR.

You create a branch, make changes, commit them, push the branch to the remote, and then open a PR on platforms like GitHub. Example commands: $ git checkout -b feature-branch $ git add . $ git commit -m "Add feature" $ git push origin feature-branch Then open a PR on GitHub comparing your branch to main.

Result

You can submit your code for review and start the feedback process.

Knowing how to submit a PR sets the stage for receiving and handling feedback effectively.

3

Intermediate

Reading and Understanding Feedback

🤔Before reading on: do you think all feedback comments require code changes? Commit to your answer.

Concept: Learning to interpret reviewer comments and decide what needs action.

Feedback can be suggestions, questions, or requests for changes. Not all comments require code edits; some may be clarifications or approvals. Read carefully and ask questions if unclear.

Result

You can distinguish between actionable feedback and general comments.

Understanding feedback types helps you respond appropriately and avoid unnecessary changes.

4

Intermediate

Making Code Changes Locally

🤔Before reading on: do you think you should edit code directly on the PR page or locally on your machine? Commit to your answer.

Concept: Knowing how to update your code on your computer before pushing changes.

You make changes in your local branch using your editor or IDE. After editing, you stage and commit the changes with git commands: $ git add changed_file $ git commit -m "Address feedback" This keeps your history clear and organized.

Result

You have updated code ready to be shared with reviewers.

Making changes locally ensures you can test and review your fixes before sharing.

5

Intermediate

Updating the PR with New Commits

🤔Before reading on: do you think pushing new commits to your branch updates the existing PR automatically? Commit to your answer.

Concept: How pushing commits to the same branch updates the open PR.

When you push new commits to the branch linked to your PR, the PR updates automatically. Use: $ git push origin feature-branch Reviewers will see your new changes in the PR interface.

Result

Your PR reflects the latest code changes and feedback responses.

Knowing that PRs update automatically with pushes avoids confusion and duplicate PRs.

6

Advanced

Using Interactive Rebase to Clean History

🤔Before reading on: do you think rewriting commit history after feedback is a good practice? Commit to your answer.

Concept: Learning to tidy commits before final merge using git rebase -i.

Interactive rebase lets you combine, edit, or reorder commits to make your history clean and meaningful: $ git rebase -i HEAD~3 You can squash minor fix commits into main ones, making the PR easier to review and the project history cleaner.

Result

Your commit history is clear, making it easier for others to understand your changes.

Cleaning commit history improves project maintainability and reviewer experience.

7

Expert

Handling Conflicts and Force Pushes

🤔Before reading on: do you think force pushing is safe anytime you update your PR? Commit to your answer.

Concept: Managing merge conflicts and safely updating PRs with force push when rewriting history.

If your branch conflicts with the main branch, you must resolve conflicts locally. After rebasing or amending commits, you need to force push: $ git push --force-with-lease origin feature-branch Force pushing overwrites the remote branch but can disrupt others if not done carefully. Use --force-with-lease to avoid overwriting others' work.

Result

Your PR branch is updated with resolved conflicts and clean history without breaking collaboration.

Knowing when and how to force push prevents lost work and keeps the team in sync.

Under the Hood

A Pull Request is a reference to a branch in a git repository. When you push commits to that branch, the PR updates automatically because it tracks the branch pointer. Feedback comments are stored on the hosting platform and linked to specific commits or lines. When you rebase or amend commits, the commit hashes change, so force pushing updates the remote branch to match your local history.

Why designed this way?

Git was designed as a distributed version control system with immutable commits identified by hashes. PRs leverage this by tracking branches, not individual commits, allowing continuous updates. Force pushing exists because rewriting history locally is common for clean commits, but it requires care to avoid overwriting others' work. Platforms like GitHub added PRs to simplify collaboration and code review workflows.

Local Repo                 Remote Repo (GitHub)
┌─────────────┐            ┌─────────────┐
│ feature-branch ├─push───▶│ feature-branch │
│ commits      │            │ commits      │
└─────┬───────┘            └─────┬───────┘
      │                           │
      │ edit & commit             │ PR tracks branch
      ▼                           ▼
┌─────────────┐            ┌─────────────┐
│ git rebase  │            │ PR interface│
│ force push  │◀───────────┤ updates     │
└─────────────┘            └─────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does pushing new commits to your branch create a new PR automatically? Commit yes or no.

Common Belief: Pushing new commits creates a new Pull Request every time.

Reality: Pushing commits to the same branch updates the existing PR automatically; no new PR is created.

Why it matters: Believing this causes confusion and duplicate PRs, cluttering the review process.

Quick: Is it safe to force push anytime you want without checking? Commit yes or no.

Common Belief: Force pushing is always safe and can be done anytime to update PRs.

Reality: Force pushing rewrites history and can overwrite others' work if not done carefully; use --force-with-lease and communicate with your team.

Why it matters: Misusing force push can cause lost commits and disrupt collaboration.

Quick: Do all feedback comments require code changes? Commit yes or no.

Common Belief: Every comment on a PR means you must change your code.

Reality: Some comments are suggestions, questions, or approvals that don't require changes.

Why it matters: Misunderstanding this leads to unnecessary work and delays.

Quick: Does rebasing your branch always make your PR harder to review? Commit yes or no.

Common Belief: Rebasing always confuses reviewers and should be avoided.

Reality: When done properly, rebasing cleans history and can make PRs easier to understand.

Why it matters: Avoiding rebasing due to fear can lead to messy commit histories and harder maintenance.

Expert Zone

1

Reviewers often look at the diff between the latest commit and the base branch, so small fixup commits can clutter the review unless squashed.

2

Force pushing with --force-with-lease is safer than plain --force because it checks if the remote branch changed before overwriting.

3

Some teams prefer rebasing to keep a linear history, while others prefer merge commits; knowing your team's policy is crucial.

When NOT to use

Avoid force pushing on shared branches where others also push; use merge commits instead. If your team prefers a merge-based workflow, do not rebase PR branches. For very large or complex PRs, consider breaking feedback into smaller chunks rather than updating all at once.

Production Patterns

In professional teams, developers often create feature branches, submit PRs, and iterate with feedback by pushing fixup commits. Before merging, they rebase interactively to clean history and then force push. Automated CI checks run on each update. Teams use draft PRs to gather early feedback without final review.

Connections

Version Control Systems

Builds-on

Understanding how git tracks changes and branches helps grasp why PR updates work by pushing commits to branches.

Code Review Process

Same pattern

Handling PR feedback is a practical application of the broader code review process, emphasizing communication and iteration.

Iterative Design in Product Development

Similar pattern

Just like product design improves through cycles of feedback and updates, PR handling is a technical version of iterative improvement.

Common Pitfalls

#1 Ignoring feedback comments or not responding to them.

Wrong approach:

No changes made after feedback; PR stays the same.

$ git push origin feature-branch
// No new commits addressing feedback

Correct approach:

$ git add updated_file
$ git commit -m "Fix issues from review"
$ git push origin feature-branch

Root cause:

Misunderstanding that feedback requires action or fear of making changes.

#2 Force pushing without --force-with-lease or warning the team.

Wrong approach:

$ git push --force origin feature-branch

Correct approach:

$ git push --force-with-lease origin feature-branch

Root cause:

Lack of awareness about safer force push options and team communication.

#3 Creating a new PR for every update instead of updating the existing one.

Wrong approach:

After feedback, push changes to a new branch and open a new PR each time.

Correct approach:

Push changes to the same branch linked to the original PR to update it.

Root cause:

Not understanding that PRs track branches, not individual commits.

Key Takeaways

A Pull Request is a living document that updates automatically when you push new commits to its branch.

Handling PR feedback well means reading comments carefully, making clear code changes locally, and pushing updates to the same branch.

Using interactive rebase and force push carefully helps keep commit history clean and collaboration smooth.

Misusing force push or misunderstanding feedback types can cause lost work and slow down the team.

Good PR feedback handling is like an iterative conversation that improves code quality and team trust.

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