Pull request process in Git - Step-by-Step Execution

Process Flow - Pull request process

Developer creates feature branch

↓

Developer makes changes and commits

↓

Developer pushes branch to remote

↓

Developer opens Pull Request (PR)

↓

Team reviews PR

↓

Approve

↓

Merge PR

↓

Feature merged into main branch

This flow shows how a developer creates a branch, makes changes, pushes it, opens a pull request, gets review feedback, and finally merges the changes.

Execution Sample

Git

git checkout -b feature-branch
# make changes
git add .
git commit -m "Add new feature"
git push origin feature-branch
# open PR on GitHub
# after approval:
# merge PR on GitHub
git checkout main
git pull

This sequence shows the main git commands used during the pull request process.

Process Table

Step	Action	Command/Operation	Result/State Change
1	Create new branch	git checkout -b feature-branch	New branch 'feature-branch' created and switched to
2	Make code changes	edit files	Working directory updated with new changes
3	Stage changes	git add .	Changes staged for commit
4	Commit changes	git commit -m "Add new feature"	New commit created on 'feature-branch'
5	Push branch	git push origin feature-branch	Branch pushed to remote repository
6	Open Pull Request	Open PR on GitHub	PR created for 'feature-branch' to merge into 'main'
7	Review PR	Team reviews code	PR approved or changes requested
8	If changes requested	Developer updates branch	New commits added to 'feature-branch'
9	Merge PR	Merge PR on GitHub	Changes merged into 'main' branch
10	Update local main	git checkout main && git pull	Local 'main' updated with merged changes
11	Exit	Process complete	Feature integrated into main branch

💡 Process stops after PR is merged and local main branch is updated

Status Tracker

Variable	Start	After Step 1	After Step 4	After Step 5	After Step 9	Final
branch	main	feature-branch	feature-branch	feature-branch (remote)	feature-branch	main
commit history	main commits only	main commits + new commits on feature-branch	same	same	main + feature commits merged	main + feature commits merged
PR status	none	none	none	none	merged	merged

Key Moments - 3 Insights

Why do we create a new branch instead of working directly on main?

Creating a new branch isolates your changes so the main branch stays stable. Execution table step 1 shows branch creation before changes.

What happens if the team requests changes during review?

You update your branch with new commits (step 8), then the PR updates automatically for re-review.

Why do we pull the main branch after merging the PR?

To update your local main branch with the merged changes from remote, as shown in step 10.

Visual Quiz - 3 Questions

Look at the execution table, what is the state of the 'branch' variable after step 5?

A feature-branch deleted

B main branch active locally

C feature-branch pushed to remote

D main branch merged

💡 Hint

Check variable_tracker column 'After Step 5' for 'branch'

At which step does the pull request get merged into the main branch?

A Step 9

B Step 7

C Step 10

D Step 11

💡 Hint

Look at execution_table row with 'Merge PR' action

If the developer skips pushing the branch (step 5), what will happen when opening the PR (step 6)?

A PR opens normally with local branch

B PR cannot be created because remote branch does not exist

C PR merges automatically

D PR is created but cannot be reviewed

💡 Hint

Refer to execution_table step 5 and 6 relationship

Concept Snapshot

Pull Request Process Cheat Sheet:
- Create a feature branch: git checkout -b feature-branch
- Make changes, stage and commit: git add . && git commit -m "msg"
- Push branch to remote: git push origin feature-branch
- Open PR on remote platform (GitHub/GitLab)
- Team reviews and approves or requests changes
- Merge PR after approval
- Update local main branch: git checkout main && git pull

Full Transcript

The pull request process starts with creating a new branch to keep changes separate from the main code. Developers make changes and commit them on this branch. Then they push the branch to the remote repository. Next, they open a pull request on a platform like GitHub to ask the team to review the changes. The team reviews and either approves or requests changes. If changes are requested, the developer updates the branch with new commits. Once approved, the pull request is merged into the main branch. Finally, the developer updates their local main branch to include the merged changes. This process helps keep the main code stable and allows team collaboration.

Practice

1. What is the main purpose of a pull request in Git?

easy

A. To ask your team to review and merge your code changes

B. To delete a branch from the repository

C. To create a new branch locally

D. To clone a repository to your computer

Solution

1. Step 1: Understand the role of a pull request

   A pull request is a request to merge code changes and get feedback from the team.

2. Step 2: Identify the correct purpose

   Options B, C, and D describe other Git actions unrelated to pull requests.

3. Final Answer:

   To ask your team to review and merge your code changes -> Option A

4. Quick Check:

   Pull request = code review request [OK]

Hint: Pull request means asking for code review and merge [OK]

Common Mistakes:

• Confusing pull request with branch creation
• Thinking pull request deletes branches
• Mixing pull request with cloning repositories

2. Which Git command is used to upload your local branch to the remote repository before creating a pull request?

easy

A. git clone origin branch-name

B. git pull origin branch-name

C. git push origin branch-name

D. git fetch origin branch-name

Solution

1. Step 1: Identify the command to upload local changes

   The git push command sends local commits to the remote repository.

2. Step 2: Match the correct syntax

   git push origin branch-name uploads the specified branch to the remote named origin.

3. Final Answer:

   git push origin branch-name -> Option C

4. Quick Check:

   Push = upload branch to remote [OK]

Hint: Push uploads your branch to remote before pull request [OK]

Common Mistakes:

• Using git clone instead of git push
• Confusing git pull with git push
• Using git fetch which only downloads data

3. After pushing your branch and creating a pull request, what is the expected output when you run git status on your local branch?

medium

A. On branch feature-xyz
nothing to commit, working tree clean

B. On branch feature-xyz
your branch is ahead of 'origin/feature-xyz' by 1 commit

C. On branch main
nothing to commit, working tree clean

D. On branch feature-xyz
You have unmerged paths.

Solution

1. Step 1: Understand the state after pushing and creating pull request

   After pushing, local and remote branches are synced, so no new commits locally.

2. Step 2: Interpret git status output

   "nothing to commit, working tree clean" means no changes locally; branch is up to date.

3. Final Answer:

   On branch feature-xyz nothing to commit, working tree clean -> Option A

4. Quick Check:

   Clean status means local branch matches remote [OK]

Hint: Clean git status means branch is synced after push [OK]

Common Mistakes:

• Thinking branch is ahead after push
• Confusing branch names
• Expecting unmerged paths without conflicts

4. You created a pull request but forgot to push your latest commit. What error will you most likely see when trying to create the pull request?

medium

A. Pull request created successfully with all commits

B. Error: No commits found on branch to compare

C. Merge conflict detected automatically

D. Remote branch does not exist

Solution

1. Step 1: Understand the pull request creation process

   A pull request compares your remote branch with the base branch.

2. Step 2: Identify the error when branch is not pushed

   If you forget to push, the remote branch does not exist, causing an error.

3. Final Answer:

   Remote branch does not exist -> Option D

4. Quick Check:

   Pull request needs remote branch [OK]

Hint: Push branch first or remote branch won't exist [OK]

Common Mistakes:

• Assuming pull request works without pushing
• Expecting merge conflict before push
• Ignoring remote branch creation step

5. You want to ensure your pull request is merged only after at least two team members approve it. Which GitHub feature should you configure?

hard

A. Enable auto-merge without reviews

B. Branch protection rules with required reviews set to 2

C. Use git rebase to combine commits

D. Create a new branch for each reviewer

Solution

1. Step 1: Identify how to enforce review requirements

   GitHub branch protection rules allow setting required number of reviewers before merge.

2. Step 2: Match the feature to the requirement

   Setting required reviews to 2 ensures at least two approvals before merging.

3. Final Answer:

   Branch protection rules with required reviews set to 2 -> Option B

4. Quick Check:

   Branch protection = enforce review count [OK]

Hint: Use branch protection rules to require reviews [OK]

Common Mistakes:

• Confusing auto-merge with review enforcement
• Thinking git rebase controls reviews
• Creating branches per reviewer is unnecessary