Read Anthropic’s case study about Graphite Reviewer

Understanding the difference between a fork and a pull request in GitHub

Sara Verdi
Sara Verdi
Graphite software engineer
Try Graphite


Note

This guide explains this concept in vanilla Git. For Graphite documentation, see our CLI docs.


Forks and pull requests are a fundamental part of collaborating on GitHub, but they serve very different purposes in the development workflow. This guide will clarify these differences and discuss the fork and pull request workflow to help you better understand how to use these tools in your projects.

A fork is a personal copy of another user's repository that resides under your account. It allows you to freely experiment with changes without affecting the original project. You can fork a project with the intention of merging those changes back into the original, or with the intention of splitting off and becoming independent in order to take the project in another direction. Let's say you find an open source project on GitHub called ExampleProject that you want to contribute to, but you don’t have write access to the repository. You can fork this project, which creates a repository called YourUsername/ExampleProject on your GitHub profile. You can clone this fork to your local machine, make your changes, and push them back to your fork on GitHub. From here you can open a pull request into the original project, or just continuing developing on your own.

A pull request (PR) is how you propose changes from your repository or branch to another repository or branch. It's a way to ask the original repository maintainers to review your changes and merge them into their project. Pull requests show diffs, or differences, of the content from both branches. The changes, additions, and subtractions are shown in green and red. As soon as you open a pull request, GitHub provides a review interface where maintainers can provide feedback, request additional changes, or approve the changes and merge them.

screenshot of a new PR

When you work directly within the main repository and have write access, you can create feature branches. This is often simpler because it keeps all work within the same repository, which is easier for continuous integration tools and other systems that monitor the repository. However, for external contributors who don't have write access, forking is necessary. They make their changes in a separate copy of the repository and use pull requests to integrate those changes back into the original project.

  1. Fork: Clone the project to your account, allowing for independent development without impacting the original.
  2. Branch: Typically used within the original repository by those who have write access.
  3. Pull Request: Used to merge changes from either forks or branches back to the main project.

Graphite's PR inbox can enhance this process by acting like an email client for your PRs, helping you stay organized and view which PRs need your attention. For instance, if you manage multiple repositories, Graphite lets you select default repositories to display PRs from, simplifying how you track contributions across different projects, especially useful in a fork and pull request workflow.

screenshot of a new PR

By understanding and utilizing forks and pull requests correctly, you can improve your collaborative development efforts and contribute more effectively to projects.

Git inspired
Graphite's CLI and VS Code extension make working with Git effortless.
Learn more

Built for the world's fastest engineering teams, now available for everyone