DEV Community

Cover image for Pull Requests, Code Reviews & Git Rebase
Md Mohiuddin
Md Mohiuddin

Posted on

Pull Requests, Code Reviews & Git Rebase

#github #git #beginners #devops

If you've already learned Git commits, branching, and merging, you've mastered the mechanics of version control. But knowing Git alone doesn't make you effective on a real engineering team.

In this article, we'll cover:

  • What Pull Requests (PRs) actually are
  • How professional code reviews work
  • Why .gitignore is essential
  • The dangers of committing secrets
  • When to use git merge vs git rebase

These are the practices that transform a personal project into a professional software project.

Why This Matters

Imagine you're building a feature for a production application.

You create a branch, write code, test it, and everything works.

Should you push directly to main?

In most professional teams, the answer is no.

Instead, your code goes through a review process where:

  • Other developers inspect your changes
  • Automated tests run
  • Discussions happen around implementation decisions
  • Quality checks prevent bugs from reaching production

That process starts with a Pull Request.

Understanding Pull Requests

A Pull Request (PR) is not a Git feature.

It is a feature provided by platforms like GitHub, GitLab, and Bitbucket.

A PR is essentially a request that says:

"I've completed work on this branch. Please review it and merge it into the target branch."

What a Pull Request Contains

A good PR provides much more than code.

The Diff

A visual representation of every change introduced by the branch.

You'll see:

  • Added lines
  • Removed lines
  • Modified files

This allows reviewers to inspect exactly what changed.

Description and Context

A PR should explain:

  • What changed
  • Why it changed
  • How it was tested

Remember:

The code shows what changed. The PR description explains why it changed.

Review Discussion

Reviewers can:

  • Comment on specific lines
  • Ask questions
  • Suggest improvements
  • Request changes

This creates a permanent record of engineering decisions.

Automated Checks

Most modern teams connect CI/CD pipelines to Pull Requests.

Common checks include:

  • Unit tests
  • Integration tests
  • Linting
  • Security scans
  • Build verification

If these checks fail, the PR usually cannot be merged.

Merge Controls

Once reviews are complete and checks pass, the PR can be merged.

Behind the scenes, the platform performs the merge operation for you.

Why Pull Requests Exist

Quality Control

Fresh eyes catch bugs.

Reviewers often identify:

  • Edge cases
  • Logic flaws
  • Performance concerns
  • Security issues

before users ever encounter them.

Knowledge Sharing

Code reviews help teams stay informed about:

  • New features
  • Architecture decisions
  • Business rules
  • Coding standards

Reviewing code is one of the fastest ways to learn a codebase.

Historical Context

Months later, someone may ask:

Why was this implemented this way?

The answer often lives in the PR discussion.

Automation Gateway

PRs provide a natural checkpoint for CI/CD pipelines.

Before code reaches production:

  • Tests run
  • Builds run
  • Security checks run

This reduces deployment risk significantly.

Creating a Pull Request

Step 1: Create a Feature Branch 

git switch -c feature/add-backup-script
Enter fullscreen mode Exit fullscreen mode

Step 2: Make Changes and Commit 

git add backup.sh

git commit -m "Add automated backup script with cron scheduling"
Enter fullscreen mode Exit fullscreen mode

Step 3: Push the Branch 

git push -u origin feature/add-backup-script
Enter fullscreen mode Exit fullscreen mode

The -u flag links your local branch to the remote branch so future pushes can simply use:

git push
Enter fullscreen mode Exit fullscreen mode

Step 4: Open the Pull Request

On GitHub:

  1. Click Compare & Pull Request
  2. Select the target branch (main)
  3. Select your feature branch
  4. Add a title
  5. Write a meaningful description
  6. Submit the PR

Writing Better PR Descriptions

A strong PR description answers four questions:

What changed?

Brief summary of the implementation.

Why was it needed?

Business or technical motivation.

How was it tested?

Evidence that the change works.

What should reviewers focus on?

Any area that may need extra attention.

Code Reviews: How Professionals Review Code

Code review is not about proving someone wrong.

It's about improving the software.

Focus on the Code, Not the Person

Avoid personal criticism.

Instead of:

You wrote this incorrectly.
Enter fullscreen mode Exit fullscreen mode

Prefer:

This function could be simplified by...
Enter fullscreen mode Exit fullscreen mode

Separate Requirements from Suggestions

Many teams use:

Nit:
Enter fullscreen mode Exit fullscreen mode

for non-blocking suggestions.

Ask Questions

Instead of making assumptions, ask:

What happens if this input is empty?

Questions encourage discussion and often reveal hidden edge cases.

Receiving Review Feedback

Every developer receives feedback.

Good engineers:

  • Respond to comments
  • Explain decisions
  • Make improvements
  • Discuss disagreements respectfully

Code review is a conversation, not a battle.

Understanding .gitignore

One of the most important files in any repository is:

.gitignore
Enter fullscreen mode Exit fullscreen mode

This file tells Git:

Never track these files.

Why .gitignore Matters

Without it, developers accidentally commit:

  • Secrets
  • Build artifacts
  • Dependency folders
  • Personal editor settings
  • Operating system files

Example .gitignore 

# Secrets
*.pem
*.key
.env
id_rsa
id_ed25519

# Logs
*.log
logs/

# Dependencies
node_modules/
__pycache__/
venv/

# IDE Files
.vscode/
.idea/

# Terraform
*.tfstate
*.tfstate.backup
.terraform/
Enter fullscreen mode Exit fullscreen mode

Never Commit Secrets

This is one of the most important rules in software engineering.

Why Deleting Later Doesn't Work

If a secret appears in Git history, it remains in history even after being removed from later commits.

Anyone with repository access can still retrieve it.

What Happens When Secrets Leak?

Automated bots constantly scan public repositories for:

  • API keys
  • Database credentials
  • AWS access keys
  • Tokens
  • Private keys

Often within minutes of a push.

Prevention Best Practices

  • Create .gitignore before starting a project
  • Use environment variables
  • Never hardcode credentials
  • Review changes before committing

Always run:

git status
Enter fullscreen mode Exit fullscreen mode

and ideally:

git diff --staged
Enter fullscreen mode Exit fullscreen mode

before every commit.

Git Rebase: An Alternative to Merge

Most developers learn merging first.

But Git also provides:

git rebase
Enter fullscreen mode Exit fullscreen mode

Example 

git switch feature/my-work

git rebase main
Enter fullscreen mode Exit fullscreen mode

This replays your commits on top of the latest version of main.

Before Rebase 

main:      A --- B --- C
                         \
feature:                  D --- E
Enter fullscreen mode Exit fullscreen mode

After Rebase 

main:      A --- B --- C
                         \
feature:                   D' --- E'
Enter fullscreen mode Exit fullscreen mode

Git creates entirely new commits with new hashes.

Merge vs Rebase

Merge Rebase
Preserves exact history Creates linear history
Adds merge commits Avoids merge commits
Safe for shared branches Rewrites history
Great for team collaboration Great for cleaning personal branches

The Golden Rule of Rebase

Never rebase a branch that other developers are already using.

A simple rule:

Rebase your own branches. Merge shared branches.

Final Thoughts

Learning Git commands is only the beginning.

Professional software development requires:

  • Pull Requests
  • Code Reviews
  • Secure Git practices
  • Proper .gitignore usage
  • Understanding when to merge and when to rebase

These skills help teams collaborate effectively, maintain quality, and deploy software with confidence.

Great developers don't just write code. They create systems that make collaboration, quality, and safety easier for everyone on the team.

Top comments (0)