Git and Code Review: Complete Process and Guidelines for Pull Requests

In team collaboration development, the “flow” and “quality” of code are crucial. Imagine if you and your teammates write code separately and then suddenly combine all files for submission—this is prone to issues. That’s where Git and Pull Requests (PRs) come in as powerful tools to solve this problem. Today, we’ll start with the basics and gradually explore how Git helps manage code and how PRs serve as the “bridge” for team collaboration.

一、Git Basics: Why It’s the Core of Collaboration¶

Before diving into PRs, let’s review some core Git operations that form the foundation of understanding PR workflows:

1. Branch: The “Stage” for Parallel Development¶

Branches act like separate “stages.” Each developer can work on their own branch without interfering with others. For example, to develop a new feature, create a branch (e.g., feature/user-login) from the main branch (usually main or master).
Command:

  # Create a new branch from the main branch
  git checkout main  # Switch to the main branch first
  git pull origin main  # Pull the latest code from the main branch
  git checkout -b feature/user-login  # Create and switch to the new branch

2. Commit: A “Snapshot” of Your Code¶

Commit saves a “snapshot” of your code changes in Git. Always write a clear commit message (e.g., “fix: Fix login button styling issue”) to help yourself and teammates track history.
Command:

  # After modifying code, commit changes to the local branch
  git add .  # Add all modified files to the staging area
  git commit -m "fix: Fix login button unclickable issue"  # Commit to the local branch

3. Push: Send Code to the Remote Repository¶

After writing code in a local branch, push it to the team’s shared remote repository (e.g., GitHub, GitLab) so others can access it.
Command:

  git push origin feature/user-login  # Push to the corresponding branch in the remote repo

二、Code Review and Pull Requests (PRs): Collaboration “Traffic Lights”¶

1. Why Code Review Matters¶

Bug Detection: Teammates catch bugs, logical flaws, or performance issues earlier.
Quality Assurance: Avoid “self-reliant fixes” and ensure code robustness through collective review.
Knowledge Sharing: New members quickly understand project architecture, while senior members learn new implementation ideas.

2. What is a Pull Request (PR)?¶

A PR is a developer’s “request” to submit code to the team repository. In short: After completing a feature or fix, you use a PR to tell the team, “I’ve finished—can you merge this into the main branch?”

The essence of a PR is a “collaboration bridge”:
You submit the PR → Team members review → Team discusses → Merge to the main branch after approval.

三、Complete PR Workflow: A “Guide” from Code to Merge¶

Using platforms like GitHub or GitLab, the PR workflow typically follows these 6 steps:

Step 1: Preparation—Ensure Clean and Updated Code¶

Before submitting a PR, do two things:
- Pull the latest main branch: Avoid conflicts with the main branch.

  git checkout main  # Switch to the main branch
  git pull origin main  # Pull the latest code
  git checkout feature/user-login  # Return to your branch
  git merge main  # Merge main branch updates (or use rebase to avoid duplicate commits)

Standardize commit messages: Use clear, descriptive messages. For example:
✅ Good: fix: Login page loading slow issue
❌ Bad: fixed a bug (no context)
Follow the Conventional Commits standard: type: short description, where types include fix (bug fix), feat (new feature), docs (documentation), etc.

Step 2: Push Your Branch to the Remote Repository¶

After writing and testing code, push your local branch to the remote repo:

git push origin feature/user-login  # Push your branch to the remote repo

Step 3: Create a PR on the Platform¶

On your code hosting platform (e.g., GitHub):
1. Go to “Pull requests” → “New pull request”.
2. Set:
- Base branch: Target branch (usually main or develop).
- Compare branch: Your newly pushed branch (e.g., feature/user-login).
3. Click “Create pull request” to open the PR page.

Step 4: Fill in PR Details—Help Reviewers Understand¶

The PR description is your “communication window.” Include:

Example PR Template:¶

## 🔍 Why this change?  
(Example: Fix user login captcha issue or add user registration feature)  

## 🚀 Implemented Features/Fixed Issues  
- Added "Remember Me" option (30-day cookie-free login)  
- Fixed captcha image refresh failure bug  

## 🧪 Testing Results  
- Local tests: Verified on Chrome/Firefox  
- Edge cases: 10 consecutive login attempts without crashes  
- Screenshots: [Optional, add feature screenshots]  

## 🚨 Notes  
- API Dependencies: Coordinated with backend to confirm API format  
- Potential Risks: No obvious risks (add if applicable)

Key Points:¶

Purpose: Clearly state “Why you’re submitting this PR” in one sentence.
Testing Results: Prove your code is verifiable and functional.
Issue Tracking: Link to issues (e.g., #123) if using Jira/GitHub Issues for traceability.

Step 5: Wait for Code Review¶

After submission, the platform assigns reviewers (e.g., team leads or senior devs). Reviewers check:
- Functionality: Does it meet requirements?
- Code Quality: Redundancy, naming clarity, logical flow?
- Risks: Performance issues, security vulnerabilities (e.g., SQL injection)?

Common Reviewer Feedback:¶

✅ Approved: Code is fine—ready to merge.
🚧 Request changes: Revise details (e.g., “Rename variable for clarity”).
❌ Comment: Reject if critical (e.g., architectural flaws require redesign).

How to Respond to Feedback:¶

Make changes locally, commit new commits, and push to the remote repo. The PR updates automatically, and reviewers recheck until approval.

Step 6: Merge and Clean Up¶

Once approved, merge the PR. Two common methods:
- Squash and merge: Compress multiple commits into one (recommended for beginners).
- Rebase and merge: Rebase your commits on top of the main branch (advanced, linear history).

After merging:
- Delete the remote branch: Check “Delete branch after merge” on the platform to avoid clutter.
- Clean up locally: Delete the merged branch:

  git checkout main && git pull && git branch -d feature/user-login

四、PR Best Practices: “Unwritten Rules” for Efficiency¶

1. Small, Frequent PRs (Avoid “Monster PRs”)¶

Large PRs (e.g., 500+ lines) are hard to review.
Small PRs (single feature/fix) are easier to approve and merge quickly.

2. “Human-Friendly” Commit Messages¶

Each commit should be a “teammate-friendly instruction”:
- ✅ fix: Change login button text color to blue
- ❌ changed button color (no context)

3. Communicate Proactively¶

After submitting a PR, @ reviewers in team chat to prompt review.
If no response after 2 days, follow up politely to avoid delays.

4. Respect Reviewer Feedback¶

Code review is constructive, not critical. Even if feedback differs from your approach:
- Respond: “I’ll try simplifying with a loop instead of nested logic—thanks!”

五、FAQ¶

Q: How to resolve merge conflicts?¶

A: If the main branch is updated, update and merge locally:

git checkout main
git pull origin main
git checkout feature/user-login
git merge main  # Resolve conflicts in files marked with <<<<<<< HEAD
git add .
git commit -m "merge: Resolve main branch conflicts"
git push origin feature/user-login

Q: PR was rejected—how to fix?¶

A: Address specific feedback (e.g., “Optimize algorithm with a hash table”), make changes, commit, and push again.

Conclusion¶

Git and PRs are the “toolkit” for collaborative development: Git manages code versions/branches, while PRs bridge team communication. Follow these norms: small commits, clear descriptions, and open dialogue. Mastering this will help your team build reliable, efficient code together!

Remember: Code review is about improving code quality, not criticism. The best code is polished collectively!