Handling PR feedback and updates in Git - Step-by-Step Execution

Process Flow - Handling PR feedback and updates

Create PR

↓

Review Feedback

↓

Make Changes Locally

↓

Commit Changes

↓

Push Updates to PR Branch

↓

PR Updates Reflect in Remote

↓

Repeat Review or Merge

This flow shows how a pull request (PR) is created, reviewed, updated with changes, and finally merged after feedback.

Execution Sample

Git

git checkout -b feature-branch
# make code changes
 git add .
 git commit -m "Fix feedback"
 git push origin feature-branch

This sequence creates a branch, commits changes after feedback, and pushes updates to the remote PR branch.

Process Table

Step	Action	Command	Result
1	Create and switch to new branch	git checkout -b feature-branch	New branch 'feature-branch' created and checked out
2	Make code changes	# edit files locally	Files modified locally
3	Stage changes	git add .	Changes staged for commit
4	Commit changes with message	git commit -m "Fix feedback"	New commit created with message 'Fix feedback'
5	Push branch to remote	git push origin feature-branch	Branch pushed; PR updates with new commit
6	Review updated PR	N/A	Reviewers see updated code in PR
7	Repeat if more feedback	Repeat steps 2-6	Cycle continues until approval
8	Merge PR after approval	git merge feature-branch	Changes merged into main branch

💡 Process stops when PR is approved and merged

Status Tracker

Variable	Start	After Step 1	After Step 4	After Step 5	Final
branch	main	feature-branch	feature-branch	feature-branch	feature-branch merged
commit	commitA	commitA	commitB (fix feedback)	commitB (fix feedback)	commitB merged
remote branch	feature-branch not pushed	feature-branch not pushed	feature-branch not pushed	feature-branch pushed	feature-branch merged

Key Moments - 3 Insights

Why do I need to commit changes before pushing?

You must commit changes locally first (see step 4 in execution_table) because git push only sends committed changes to the remote repository.

What happens if I push without switching to the PR branch?

If you push from the wrong branch, your updates won't appear in the PR (see step 1 and 5). Always confirm you are on the correct branch before pushing.

Can I push multiple commits for one PR update?

Yes, you can commit multiple times locally and push all commits together or separately; the PR will update with all pushed commits (see steps 4 and 5).

Visual Quiz - 3 Questions

Look at the execution_table, what command creates the new commit with feedback changes?

A git add .

B git commit -m "Fix feedback"

C git push origin feature-branch

D git checkout -b feature-branch

💡 Hint

Check step 4 in the execution_table where the commit is created.

At which step does the remote PR branch get updated with your changes?

A Step 3

B Step 4

C Step 5

D Step 6

💡 Hint

Look at the 'Result' column in step 5 for when the branch is pushed.

If you forget to switch to 'feature-branch' before pushing, what will happen?

A Your changes push to the wrong branch, PR not updated

B Git will automatically switch branches for you

C Your changes update the PR branch anyway

D Push will fail with an error

💡 Hint

Refer to key_moments about branch switching and step 1 in execution_table.

Concept Snapshot

Handling PR feedback:
1. Create and switch to a feature branch
2. Make and stage changes
3. Commit changes with clear message
4. Push branch to update PR
5. Repeat until approved
6. Merge PR to main branch

Full Transcript

This visual execution shows how to handle pull request feedback using git. First, you create a new branch for your feature or fix. Then you make changes locally and stage them with 'git add'. Next, you commit these changes with a message explaining the update. After that, you push the branch to the remote repository, which updates the pull request with your new commits. Reviewers can then see your changes and provide more feedback if needed. This cycle repeats until the PR is approved and merged into the main branch. Key points include always committing before pushing and ensuring you are on the correct branch to update the PR.

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