Git Notes

Hub Benefits of Git and GitHub - Why They Matter Git vs GitHub Version Control System What Is Git What Is GitHub Configure Git - User Identity and Settings Create GitHub Account - Sign Up Guide First Git Repository - Getting Started Install Git on Linux - Complete Setup Guide Install Git on macOS - Installation Guide Install Git on Windows - Step-by-Step Guide Git Add - Stage Changes Git Clone - Copy Remote Repositories Locally Git Commit - Save Changes Git Diff - Compare Changes in Your Repository Git Ignore - Exclude Files from Version Control Git Init - Initialize Repository Git Log - View Commit History Git Status - Check Repository State Git Fetch - Download Remote Changes Without Merging Git Pull - Fetch and Merge Remote Changes Git Push - Upload Local Commits to Remote Repository Git Remote - Manage Remote Repository Connections Local Repository - Understanding Your Git Working Environment Remote Repository - Collaborate Through Shared Repositories Sync Local and Remote - Keep Repositories in Harmony Amend Commit - Fix Last Commit Delete Branch - Clean Up Branches Git Reset - Move HEAD and Undo Commits Git Restore - Discard Changes Git Revert - Safely Undo Changes Recover Lost Commits - Reflog Guide Fork Repository GitHub Pages GitHub Profile Setup GitHub Repositories GitHub Stars and Watchers Repository Settings Code Reviews Git Clone Git Fetch Git Pull Git Push GitHub Issues Labels and Milestones Open Source Contributions GitHub Project Boards Pull Requests - Propose and Review Code Changes Team Collaboration with Git and GitHub Automated Testing with GitHub Actions CI/CD with GitHub Actions Deployment Automation with GitHub Actions Introduction to GitHub Actions GitHub Actions Runners GitHub Actions Workflows Enterprise Git Workflows - Scale Git for Large Organizations Feature Branch Workflow - Isolate Development Work GitFlow Workflow - Structured Release Management Monorepo Workflow - Manage Multiple Projects in One Repository Trunk-Based Development - Ship Code Fast and Safely Deployment Workflows GitHub Pages Deployment Netlify Deployment from GitHub Render Deployment from GitHub Vercel Deployment from GitHub Branch Protection Rules - Secure Your Git Branches Personal Access Tokens - Authenticate with GitHub Repository Security Best Practices Secret Scanning - Detect Leaked Credentials in Code Signed Commits - Verify Commit Authenticity with GPG SSH Keys - Secure Git Authentication Without Passwords Git Bisect - Find Bugs with Binary Search Git Cherry-Pick - Apply Specific Commits to Any Branch Git Hooks - Automate Workflows with Git Events Git Internals - Understanding How Git Works Under the Hood Git Stash - Temporarily Save Uncommitted Changes Git Submodules - Manage External Dependencies as Git Repos Git Tag - Mark Important Points in History Git Worktrees - Work on Multiple Branches Simultaneously Collaborative Web App Project Complete Team Workflow Project GitHub Actions Project - Build a CI/CD Pipeline Open Source Project Contribution - Guided Exercise Portfolio Project with Git - Showcase Your Skills Git Command Cheatsheet Git Interview Questions - Comprehensive Preparation Guide GitHub Interview Questions Scenario-Based Git Interview Questions Git Troubleshooting Guide Git Best Practices - Professional Development Habits Common Git Errors and Fixes - Quick Solutions Git Command Reference - Complete Command Guide Learning Resources - Continue Your Git & GitHub Education Branch Strategies - Choosing the Right Git Branching Model Create Branch in Git - Start New Development Lines Fast-Forward Merge in Git - Clean Linear History Git Branch Git Checkout Git Merge Git Rebase Merge Branches in Git - Combine Development Work Merge Conflicts - Resolve Git Conflicts Like a Pro Switch Branch in Git - Navigate Between Branches

Code Reviews

Code reviews are one of the most important practices in professional software development. They serve as a quality gate where team members examine each...

Code reviews are one of the most important practices in professional software development. They serve as a quality gate where team members examine each other's code before it gets merged into the main codebase. Beyond catching bugs, code reviews spread knowledge across the team, maintain coding standards, and mentor junior developers through practical feedback.

Why Code Reviews Matter

Consider this scenario: a developer writes a function that works perfectly in testing but has a subtle race condition that only appears under heavy load. Without a code review, this bug ships to production. With a review, a senior teammate who has dealt with concurrency issues spots the problem immediately. This is the power of having multiple eyes on every change.

Code reviews provide several concrete benefits:

Bug detection before code reaches production
Knowledge sharing across the team — everyone learns the codebase
Consistent code quality through enforced standards
Documentation through PR descriptions and review comments
Mentorship for junior developers receiving constructive feedback

The Code Review Process on GitHub

On GitHub, code reviews happen through Pull Requests. The typical workflow:

Developer creates a feature branch and pushes their work
Developer opens a Pull Request describing the changes
Reviewers are assigned (or self-assign)
Reviewers examine the code diff, leave comments, and request changes
Developer addresses feedback and pushes additional commits
Reviewers approve the changes
The PR is merged

Writing Good Pull Request Descriptions

A well-written PR description makes reviewing significantly easier:

markdown example

## Summary
Add user authentication using JWT tokens

## Changes
- Implement login/register API endpoints
- Add JWT token generation and validation middleware
- Create user model with password hashing
- Add rate limiting to auth endpoints

## Testing
- Unit tests for token generation/validation
- Integration tests for login flow
- Manual testing with Postman (screenshots attached)

## Related Issues
Closes #142, #143

Conducting an Effective Review

When reviewing someone else's code, focus on these areas:

Logic and correctness: Does the code do what it claims to do? Are there edge cases not handled?

Security: Are there SQL injection risks? Is user input validated? Are secrets properly managed?

Performance: Are there unnecessary database queries in loops? Could data structures be more efficient?

Readability: Can you understand the code without the author explaining it? Are variable names descriptive?

Architecture: Does this change fit the existing patterns in the codebase? Will it be easy to modify later?

Leaving Constructive Comments

The way you phrase review comments significantly impacts team dynamics. Compare these approaches:

Example

❌ "This is wrong. Use a map instead." ✅ "Consider using a Map here instead of an object — it handles non-string keys better and has O(1) lookups. What do you think?"

Use GitHub's suggestion feature for specific code changes:

suggestion example

const users = new Map();
users.set(userId, userData);

Prefix comments to indicate severity:

nit: Minor style issues that are not blockers
question: Seeking to understand intent, not necessarily requesting changes
blocker: Must be fixed before merging
suggestion: Optional improvement that can be deferred

Review States on GitHub

GitHub provides three review states:

Comment — General feedback without explicit approval or rejection
Approve — You are satisfied the code is ready to merge
Request Changes — Issues must be addressed before merging

Teams typically require one or two approvals before merging is allowed. This is configured in branch protection rules.

Best Practices for Authors

Keep PRs small. A 50-line PR gets a thorough review. A 500-line PR gets a rubber stamp. Break large features into smaller, logical PRs that can be reviewed independently.

Self-review first. Before requesting reviews, look through your own diff. You will often catch issues yourself — leftover debug statements, missing comments, or unnecessary file changes.

Respond to every comment. Even if you disagree, acknowledge the feedback. If you choose not to implement a suggestion, explain your reasoning.

Do not take it personally. Review comments are about the code, not about you. Experienced developers have their code critiqued regularly — it is part of the craft.

Best Practices for Reviewers

Be timely. Aim to provide initial review within 24 hours. Blocked PRs slow the entire team.

Review the overall design first. If the fundamental approach needs to change, say so early rather than nitpicking details that will be rewritten anyway.

Test locally when needed. For complex changes, pull the branch and run the code. Reading a diff cannot catch everything.

Praise good work. If a solution is elegant or well-tested, say so. Positive feedback motivates and reinforces good practices.

Automated Code Review Tools

Modern teams supplement human reviews with automation:

Linters (ESLint, Pylint) catch style and potential bugs automatically
Formatters (Prettier, Black) eliminate style discussions entirely
CI/CD checks run tests before reviewers spend time
Code coverage tools flag untested code paths
Security scanners (Dependabot, Snyk) identify vulnerable dependencies

These tools handle mechanical checks so human reviewers can focus on logic, design, and intent.

Common Anti-Patterns

Rubber stamping: Approving without actually reading the code. This defeats the entire purpose of reviews.

Gatekeeping: Using reviews to block work over personal style preferences rather than genuine issues.

Review hoarding: One person reviewing everything, creating a bottleneck. Distribute review responsibilities across the team.

Key Takeaways

Code reviews are a team investment that pays dividends in code quality, shared knowledge, and reduced bugs. Write small, well-described PRs for easy review. As a reviewer, be constructive, timely, and focus on what matters most. Combine human judgment with automated tools for a thorough yet efficient review process that makes everyone on the team a better developer.

Exam Focus

Revise definitions, diagrams, examples, and short-answer points for Code Reviews.

Interview Use

Prepare one clear explanation, one practical example, and one common mistake for this Git & GitHub topic.

Search Terms

git-github, git & github, git, github, collaboration, code, reviews, code reviews

Related Git & GitHub Topics

Continue learning this concept

CollaborationGit CloneCloning is how you get an existing repository from a remote server onto your local machine. When you clone a repository, you get the complete project —...CollaborationGit FetchThe git fetch command downloads new data from a remote repository without modifying your working directory or current branch. Think of it as checking your...CollaborationGit PullThe git pull command is one of the most frequently used Git commands in collaborative development. It downloads changes from a remote repository and...CollaborationGit PushThe git push command uploads your local commits to a remote repository, making your work available to other team members. It is the counterpart to git pull...CollaborationGitHub IssuesGitHub Issues is the built-in project tracking system that comes with every GitHub repository. Issues serve as the central place to report bugs, request...CollaborationLabels and MilestonesLabels and milestones are GitHub\

PreviousRepository Settings NextGit Clone