Pull Requests and Collaboration

A pull request (PR) — sometimes called a merge request on GitLab — is a formal proposal to merge one branch into another. It is the primary mechanism for code review and collaboration on platforms like GitHub. Pull requests allow teammates to discuss changes, suggest improvements, and approve work before it is merged into the main branch.

The Pull Request Workflow

The typical team workflow using pull requests is:

1. Create a feature branch from main
2. Make commits on the feature branch
3. Push the branch to the remote repository
4. Open a pull request on GitHub
5. Request review from teammates
6. Address feedback by pushing additional commits
7. A reviewer approves the PR
8. Merge the PR into main
9. Delete the feature branch

git switch -c feature/user-profile
# ... make changes and commits ...
git push -u origin feature/user-profile

Then navigate to GitHub and click Compare & pull request.

Writing a Good Pull Request Description

A clear PR description speeds up review. Include:

• What: A summary of the changes
• Why: The motivation or problem being solved
• How to test: Steps a reviewer can follow to verify the change works

Reviewing a Pull Request

Reviewers can leave inline comments on specific lines of code, approve the PR, or request changes. As the author, you respond to feedback by:

# Make the requested changes locally
git add updated-file.js
git commit -m "Address review: use consistent variable naming"
git push

The new commits automatically appear in the open PR.

Keeping Your Branch Up to Date

While your PR is open, main may receive other merges. Keep your branch current to avoid conflicts:

git switch main
git pull origin main
git switch feature/user-profile
git merge main
git push

Merge Strategies on GitHub

GitHub offers three merge strategies:

• Create a merge commit: Preserves full branch history with a merge commit
• Squash and merge: Combines all PR commits into a single commit on main — keeps history tidy
• Rebase and merge: Replays commits on top of main, producing a linear history

Protecting the Main Branch

Teams typically configure branch protection rules on GitHub to enforce that: