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

Pull Requests - Propose and Review Code Changes

Master GitHub Pull Requests for proposing changes, requesting reviews, managing feedback, and merging code. Learn PR best practices and workflows.

Pull Requests (PRs) are GitHub's mechanism for proposing changes and requesting code review before merging into a target branch. They are central to collaborative development workflows.

Creating a Pull Request

From the Command Line

bash example

# Create and push a feature branch
git checkout -b feature/add-search
# ... make changes ...
git add .
git commit -m "feat: add search functionality"
git push origin feature/add-search

Output

remote: Create a pull request for 'feature/add-search' on GitHub by visiting:
remote:   https://github.com/user/repo/pull/new/feature/add-search

On GitHub

Go to your repository
Click "Pull requests" → "New pull request"
Select base branch (e.g., main) and compare branch (e.g., feature/add-search)
Fill in title and description
Click "Create pull request"

PR Description Template

Example

## Summary Add full-text search to the product catalog using Elasticsearch. ## Changes Made - Set up Elasticsearch client connection - Add search endpoint `/api/search` - Create search index for products - Add debounced search input component - Add unit and integration tests ## Screenshots [If UI changes, add before/after screenshots] ## Testing - [x] Unit tests pass - [x] Integration tests pass - [x] Manual testing on staging ## Related Issues Closes #78 Related to #65 ## Checklist - [x] Code follows project style guidelines - [x] Self-reviewed my code - [x] Added tests for new functionality - [x] Documentation updated - [x] No breaking changes

PR States and Actions

State	Meaning
Open	Awaiting review or discussion
Draft	Work in progress, not ready for review
Review Required	Waiting for reviewer approval
Changes Requested	Reviewer asked for modifications
Approved	Reviewer approved the changes
Merged	Changes integrated into target branch
Closed	PR rejected or abandoned

Draft Pull Requests

Open a PR early to get feedback on approach:

bash example

# Push your WIP branch
git push origin feature/new-approach

# On GitHub: Create PR → click "Create draft pull request"

Convert to ready when done: "Ready for review" button.

Merge Options

Merge Commit (Default)

Example

main: [A]──[B]──[M] (merge commit) \ / feature: [C]──[D]

Squash and Merge

Combines all PR commits into one:

Example

main: [A]──[B]──[CD] (single squashed commit)

Rebase and Merge

Replays commits on top of base:

Example

main: [A]──[B]──[C']──[D'] (individual commits, new SHAs)

Best Practices

Keep PRs small — Under 400 lines of changes ideally
One concern per PR — Don't mix features with refactoring
Write descriptive titles — "feat: add user search with Elasticsearch" not "update code"
Use draft PRs for WIP — Get early feedback on direction
Respond to reviews promptly — Keep the feedback loop short
Test before requesting review — Don't waste reviewers' time

Interview Questions

What is a Pull Request?

A Pull Request is a proposal to merge changes from one branch into another. It provides a forum for code review, discussion, CI checks, and approval before changes are integrated.

What is the difference between the three merge options (merge, squash, rebase)?

Merge creates a merge commit preserving all history. Squash combines all PR commits into one clean commit. Rebase replays each commit on top of the base branch without a merge commit.

When would you use a draft Pull Request?

When your work is in progress and you want early feedback on your approach, architectural decisions, or implementation direction without signaling that the code is ready for final review.

How do you link a PR to an issue?

Use keywords in the PR description: "Closes #123", "Fixes #456", or "Resolves #789". When the PR is merged, the referenced issues are automatically closed.

What makes a PR easy to review?

Small size (under 400 lines), clear description, focused scope (one feature/fix), tests included, screenshots for UI changes, and self-reviewed before requesting others.

Common Pull Request Mistakes to Avoid

Even experienced developers make PR mistakes that slow down the review process. Here are common pitfalls and how to avoid them:

1. Giant PRs (1000+ lines) Large PRs are exhausting to review and often get rubber-stamped without careful examination. Break large features into logical, independently mergeable chunks. A feature flag can hide incomplete functionality while allowing incremental merges.

2. No context in the description Reviewers shouldn't need to read the issue, Slack conversation, and design doc to understand your PR. Include the "why" in the description — what problem does this solve, what approach did you take, and what alternatives did you consider?

3. Mixing unrelated changes A PR that adds a feature AND refactors the database layer AND updates dependencies is three PRs disguised as one. Each concern should be a separate PR for clean history and easier review.

4. Not self-reviewing before requesting review Always review your own diff before adding reviewers. You'll catch typos, debug logs, commented-out code, and formatting issues that waste reviewers' time.

Pull Request Etiquette for Reviewers

Being a good reviewer is as important as writing good PRs:

Be constructive: "Consider using a map here for O(1) lookup" is better than "This is slow"
Distinguish blockers from suggestions: Use prefixes like "nit:", "suggestion:", or "blocking:" to clarify severity
Approve with comments: If your feedback is minor (typos, style preferences), approve the PR with comments rather than requesting changes
Review promptly: Aim to review within 24 hours. Stale PRs lead to merge conflicts and context loss
Ask questions: "What happens if this list is empty?" is a gentle way to surface a potential bug

Automation and CI/CD Integration

Modern PR workflows integrate with CI/CD pipelines. When a PR is opened, automated checks typically include:

Unit tests: Verify existing functionality isn't broken
Linting: Enforce code style consistency
Type checking: Catch type errors early
Security scanning: Detect vulnerable dependencies
Coverage reports: Ensure new code has adequate tests
Preview deployments: Generate a live preview URL for UI changes

These automated checks reduce reviewer burden and catch mechanical issues before human review begins.

Exam Focus

Revise definitions, diagrams, examples, and short-answer points for Pull Requests - Propose and Review Code Changes.

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, pull, requests, pull requests - propose and review code changes

Related Git & GitHub Topics

Continue learning this concept

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...CollaborationCode ReviewsCode reviews are one of the most important practices in professional software development. They serve as a quality gate where team members examine each...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 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...

PreviousGitHub Project Boards NextTeam Collaboration with Git and GitHub

Git Notes

Pull Requests - Propose and Review Code Changes

Master GitHub Pull Requests for proposing changes, requesting reviews, managing feedback, and merging code. Learn PR best practices and workflows.

Pull Requests (PRs) are GitHub's mechanism for proposing changes and requesting code review before merging into a target branch. They are central to collaborative development workflows.

Creating a Pull Request

From the Command Line

bash example

# Create and push a feature branch
git checkout -b feature/add-search
# ... make changes ...
git add .
git commit -m "feat: add search functionality"
git push origin feature/add-search

Output

remote: Create a pull request for 'feature/add-search' on GitHub by visiting:
remote:   https://github.com/user/repo/pull/new/feature/add-search

On GitHub

Go to your repository
Click "Pull requests" → "New pull request"
Select base branch (e.g., main) and compare branch (e.g., feature/add-search)
Fill in title and description
Click "Create pull request"

PR Description Template

Example

PR States and Actions

State	Meaning
Open	Awaiting review or discussion
Draft	Work in progress, not ready for review
Review Required	Waiting for reviewer approval
Changes Requested	Reviewer asked for modifications
Approved	Reviewer approved the changes
Merged	Changes integrated into target branch
Closed	PR rejected or abandoned

Draft Pull Requests

Open a PR early to get feedback on approach:

bash example

# Push your WIP branch
git push origin feature/new-approach

# On GitHub: Create PR → click "Create draft pull request"

Convert to ready when done: "Ready for review" button.

Merge Options

Merge Commit (Default)

Example

main: [A]──[B]──[M] (merge commit) \ / feature: [C]──[D]

Squash and Merge

Combines all PR commits into one:

Example

main: [A]──[B]──[CD] (single squashed commit)

Rebase and Merge

Replays commits on top of base:

Example

main: [A]──[B]──[C']──[D'] (individual commits, new SHAs)

Best Practices

Keep PRs small — Under 400 lines of changes ideally
One concern per PR — Don't mix features with refactoring
Write descriptive titles — "feat: add user search with Elasticsearch" not "update code"
Use draft PRs for WIP — Get early feedback on direction
Respond to reviews promptly — Keep the feedback loop short
Test before requesting review — Don't waste reviewers' time

Interview Questions

What is a Pull Request?

A Pull Request is a proposal to merge changes from one branch into another. It provides a forum for code review, discussion, CI checks, and approval before changes are integrated.

What is the difference between the three merge options (merge, squash, rebase)?

Merge creates a merge commit preserving all history. Squash combines all PR commits into one clean commit. Rebase replays each commit on top of the base branch without a merge commit.

When would you use a draft Pull Request?

When your work is in progress and you want early feedback on your approach, architectural decisions, or implementation direction without signaling that the code is ready for final review.

How do you link a PR to an issue?

Use keywords in the PR description: "Closes #123", "Fixes #456", or "Resolves #789". When the PR is merged, the referenced issues are automatically closed.

What makes a PR easy to review?

Small size (under 400 lines), clear description, focused scope (one feature/fix), tests included, screenshots for UI changes, and self-reviewed before requesting others.

Common Pull Request Mistakes to Avoid

Even experienced developers make PR mistakes that slow down the review process. Here are common pitfalls and how to avoid them:

Pull Request Etiquette for Reviewers

Being a good reviewer is as important as writing good PRs:

Be constructive: "Consider using a map here for O(1) lookup" is better than "This is slow"
Distinguish blockers from suggestions: Use prefixes like "nit:", "suggestion:", or "blocking:" to clarify severity
Approve with comments: If your feedback is minor (typos, style preferences), approve the PR with comments rather than requesting changes
Review promptly: Aim to review within 24 hours. Stale PRs lead to merge conflicts and context loss
Ask questions: "What happens if this list is empty?" is a gentle way to surface a potential bug

Automation and CI/CD Integration

Modern PR workflows integrate with CI/CD pipelines. When a PR is opened, automated checks typically include:

Unit tests: Verify existing functionality isn't broken
Linting: Enforce code style consistency
Type checking: Catch type errors early
Security scanning: Detect vulnerable dependencies
Coverage reports: Ensure new code has adequate tests
Preview deployments: Generate a live preview URL for UI changes

These automated checks reduce reviewer burden and catch mechanical issues before human review begins.

Exam Focus

Revise definitions, diagrams, examples, and short-answer points for Pull Requests - Propose and Review Code Changes.

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, pull, requests, pull requests - propose and review code changes

Related Git & GitHub Topics

Continue learning this concept

PreviousGitHub Project Boards NextTeam Collaboration with Git and GitHub