A pull request (PR) — called a merge request (MR) on GitLab — is a proposal to merge one branch into another. It is the standard way teams review and discuss code changes before they become part of the main codebase.
Instead of merging your feature branch into main directly, you push your branch to the remote and open a PR. Your teammates review the diff, leave comments, suggest changes, and eventually approve the merge. This process catches bugs, improves code quality, and keeps the team aligned on what goes into production.
A pull request is not just a technical mechanism — it is a conversation. The diff shows what changed, and the discussion captures why it changed and whether it is the right approach.
The complete workflow
Opening your first PR follows a clear five-step workflow: clone, branch, commit, push, and create the PR. Here is each step in detail:
Use lowercase and hyphens to separate words. Avoid spaces, underscores, and capital letters.
Keep it short but descriptive. feature/add-search is better than feature/add-the-new-search-functionality-to-the-header.
Include an issue number if your team uses them: fix/42-login-redirect.
The prefix helps tools like Komitly group branches into folders. All feature/ branches appear under a single collapsible folder in the sidebar.
Komitly - Branch Sidebar
Branches (4)
●main
▸feature
●add-searchHEAD
●user-profile
▸fix
●nav-hover
Writing a good pull request
A PR is only as useful as its description. A good PR title and body help reviewers understand the change quickly, which means faster reviews and fewer back-and-forth questions.
The title
Keep it under 70 characters. It should describe the change in imperative mood, just like a commit message: "Add search functionality", not "Added search" or "Search feature PR".
The description
A good PR description answers three questions: what changed, why it changed, and how to test it. Here is a template you can reuse:
Pull request template
## Summary
Brief description of what this PR does and why.
## Changes
- Added `Search` component with debounced input (300ms)
- Added `SearchResults` component with keyword highlighting
- Created `useSearch` hook for search state management
- Added `highlight()` utility for matching text fragments
## How to test
1. Start the dev server with `npm run dev`
2. Click the search icon in the header
3. Type a query — results should appear after 300ms
4. Verify keywords are highlighted in the results
## Screenshots
(Attach before/after screenshots if the PR includes UI changes)
## Related issues
Closes #42
Tips for better PRs
Keep PRs small. A PR with 50 changed lines gets a thorough review. A PR with 500 lines gets a rubber stamp. If your feature is large, split it into smaller PRs.
One PR = one concern. Do not mix a bug fix with a refactor with a new feature. Separate changes make reviews faster and reverts cleaner.
Add screenshots for UI changes. A before/after screenshot saves reviewers the time of checking out your branch and running the app.
Link related issues. Use Closes #42 or Fixes #42 in the description to automatically close the issue when the PR is merged.
Self-review first. Before requesting reviewers, read through your own diff. You will often catch things you missed.
Pull requests in Komitly
Komitly integrates directly with GitHub, GitLab, Azure DevOps, and Bitbucket, so you can manage PRs without leaving the app.
Creating a PR
After pushing your branch, Komitly detects that it has no open PR and offers to create one. You fill in the title and description, select reviewers, and submit — all from a dialog inside the app. No need to open a browser.
Viewing PR status
The Pull Requests panel in the Activity Rail shows all open PRs for the current repository. Each PR displays its title, status (open, draft, merged, closed), and CI/CD check results. You can click a PR to view the full diff, comments, and review threads.
Branch Compare
Before opening a PR, use the Branch Compare feature (Ctrl+Shift+D) to preview exactly what will go into the PR:
Ahead tab — Commits on your branch that are not on the base branch. These are the commits the PR will include.
Behind tab — Commits on the base branch that your branch does not have yet. If this list is long, consider rebasing first.
Files tab — All files that differ between the two branches, with addition/deletion counts.
Reviewing changes before submitting
The staging panel and diff viewer let you review every change before pushing. Click any file to see the diff, toggle between unified and split views, and verify that nothing unexpected is included:
Komitly - Staging Panel
Staged (4)
Asrc/components/Search.tsx
Asrc/components/SearchResults.tsx
Asrc/hooks/useSearch.ts
Asrc/utils/highlight.ts
Changes (1)
Msrc/App.tsx
Add search component with debounced input
Commit
Komitly's CI/CD status display shows check results directly in the PR panel. Green checks mean your pipeline passed; red marks indicate failures that need fixing before the PR can be merged.
After the review
Addressing feedback
Reviewers will often request changes. The workflow is straightforward: make the changes, commit, and push. The PR updates automatically because it tracks your branch:
Terminal
# Make changes based on review feedback
$ git add src/hooks/useSearch.ts
$ git commit -m "Add error handling to useSearch hook"
[feature/add-search c3d4e5f] Add error handling to useSearch hook
1 file changed, 12 insertions(+), 3 deletions(-)
# Push the new commit — the PR updates automatically
Why --force-with-lease? After a rebase, your commit hashes change, so a regular push is rejected. The --force-with-lease flag overrides this, but only if no one else has pushed to the branch. It is the safe alternative to --force.
Merging and cleaning up
Once the PR is approved, it gets merged (usually by clicking a button on GitHub/GitLab). After that, switch back to main, pull the merged changes, and delete the feature branch:
Terminal
# After the PR is merged, clean up
$ git switch main
Switched to branch 'main'
$ git pull
From https://github.com/yourteam/webapp
f9e8d7c..7a8b9c0 main -> origin/main
Updating f9e8d7c..7a8b9c0
Fast-forward
$ git branch -d feature/add-search
Deleted branch feature/add-search (was c3d4e5f).
In Komitly, branch cleanup is even simpler. The branch sidebar shows a context menu on each branch with a Delete option. You can also use the Stale Branches panel to find and remove branches that have already been merged.
Summary
A pull request is the standard way to propose, review, and merge code changes in a team. Here is a quick recap of the complete workflow:
Branch — Create a descriptive branch from the latest main using a type/description convention.
Commit — Make small, focused commits that each represent one logical change.
Push — Upload your branch with git push -u origin branch-name.
Open the PR — Write a clear title and description, link related issues, and add screenshots for UI changes.
Address feedback — Commit fixes and push. The PR updates automatically.
Merge and clean up — After approval, merge the PR, pull main, and delete the feature branch.
In Komitly, create PRs from the app, compare branches with Ctrl+Shift+D, track CI/CD status, and manage branches visually — including automatic stale branch detection for cleanup.
With pull requests mastered, you know the full Git collaboration cycle. Next, learn how to keep secrets and junk out of your repository with .gitignore.