home Explore Documentation & Help
Register Sign In

Navigation

Getting Started

User Guide

Team Collaboration

Advanced

FAQ & Help

Code Review

What is Code Review?

Code review is the process where team members review each other's code before it's merged. It helps maintain code quality, share knowledge, and catch bugs early.

Code Review Workflow

1. Create a Pull Request

# Create feature branch
git checkout -b feature/new-feature

# Make changes and commit
git add .
git commit -m "Add new feature"
git push origin feature/new-feature

Then create a pull request on gityar.

2. Request Review

In the pull request:

  1. Click "Reviewers" on the right sidebar
  2. Select team members
  3. Optionally add a comment explaining what to focus on

3. Review the Code

Reviewers should:

  • Read the code changes carefully
  • Understand the purpose and context
  • Check for bugs and edge cases
  • Verify code follows standards
  • Test the changes locally if needed

Review Features

Viewing Changes

Diff View:

  • See all changes side-by-side
  • Highlighted additions and deletions
  • Syntax highlighting
  • Split or unified diff

Commit History:

  • View all commits in the PR
  • See commit messages
  • Track changes over time

Inline Comments

Leave comments on specific lines:

  1. Hover over a line number
  2. Click the "+" icon
  3. Write your comment
  4. Click "Add single comment" or "Start a review"

Review States

Comment:

  • General feedback
  • No approval or rejection
  • Ask questions or suggest improvements

Approve:

  • Code is ready to merge
  • All concerns addressed
  • Meets quality standards

Request Changes:

  • Issues must be fixed before merging
  • Specific feedback provided
  • Author should address concerns

Best Practices

For Authors

Before Submitting:

  • ✅ Self-review your code first
  • ✅ Ensure code compiles and tests pass
  • ✅ Write clear PR description
  • ✅ Break large changes into smaller PRs
  • ✅ Add comments for complex logic
  • ✅ Include tests for new features

During Review:

  • ✅ Respond to all comments
  • ✅ Be respectful and professional
  • ✅ Explain your reasoning
  • ✅ Make requested changes promptly
  • ✅ Push updates to the same branch
  • ✅ Thank reviewers for their time

For Reviewers

Review Process:

  • ✅ Review promptly (within 24 hours)
  • ✅ Be constructive, not critical
  • ✅ Explain why, not just what
  • ✅ Suggest specific improvements
  • ✅ Acknowledge good practices
  • ✅ Test locally if changes are complex

Comment Types:

Questions:

"What happens if this receives an empty array?"

Suggestions:

"Consider using a map here for better performance"

Nitpicks:

"Nit: extra whitespace on line 42"

Blockers:

"This needs to handle the error case before we can merge"

Code Review Checklist

Functionality

  • Does the code do what it's supposed to do?
  • Are edge cases handled?
  • Is error handling adequate?
  • Are there any bugs?

Code Quality

  • Is the code readable and maintainable?
  • Does it follow project conventions?
  • Are variable names descriptive?
  • Is there unnecessary complexity?

Security

  • Are there security vulnerabilities?
  • Is user input validated?
  • Are secrets properly handled?
  • Is authentication/authorization correct?

Performance

  • Are there performance issues?
  • Is there unnecessary computation?
  • Are database queries efficient?
  • Is caching used appropriately?

Testing

  • Are tests included?
  • Do tests cover edge cases?
  • Do all tests pass?
  • Is test coverage adequate?

Documentation

  • Is code documented?
  • Are complex algorithms explained?
  • Is the PR description clear?
  • Are API changes documented?

Resolving Review Comments

Making Changes

# Make requested changes
# Edit files...

# Commit changes
git add .
git commit -m "Address review comments"

# Push to update PR
git push origin feature/new-feature

Marking as Resolved

  1. Address the comment in code or discussion
  2. Click "Resolve conversation" if you're the reviewer
  3. Ensure all requested changes are addressed

Follow-up Reviews

After changes are made:

  1. Reviewers re-review the updated code
  2. Approve if satisfied
  3. Request further changes if needed
  4. Merge when all concerns are addressed

Merging

When to Merge

  • ✅ All requested changes addressed
  • ✅ At least one approval (or required number)
  • ✅ All CI checks passing
  • ✅ No merge conflicts
  • ✅ Team agrees it's ready

Merge Methods

Merge Commit:

  • Preserves all commits
  • Creates a merge commit
  • Best for feature branches

Squash and Merge:

  • Combines all commits into one
  • Clean history
  • Best for small PRs

Rebase and Merge:

  • Rebases commits onto target branch
  • Linear history
  • Best for maintaining clean history

Next Steps