How to do a GitHub pull request

Collaborating on software projects can feel like navigating a complex maze. But with the right tools and processes, it can be a smooth, efficient journey. One such tool, pivotal to modern software development, is GitHub and its powerful pull request (PR) feature. Mastering the art of the GitHub pull request is essential for anyone working in a collaborative coding environment, from seasoned developers to those just starting their coding adventure. This post will guide you through the process of creating and managing pull requests effectively, empowering you to contribute to projects and enhance your collaboration skills.

Forking the Repository

The first step in the pull request workflow is forking the repository you want to contribute to. Forking creates a personal copy of the project on your GitHub account, allowing you to make changes without affecting the original project. This safeguards the original codebase while giving you a dedicated space to experiment and implement your contributions. Locate the “Fork” button in the upper right corner of the repository page and click it. This action initiates the forking process, copying the entire repository to your GitHub account.

Once forked, you’ll have your own version of the repository. This is your sandbox, where you can freely modify the code without impacting the original project. Now you’re ready to make your mark.

Cloning the Repository

After forking, clone the repository to your local machine. Cloning downloads the project files, enabling you to work on them using your preferred code editor and development environment. This allows for a more integrated and efficient workflow. To clone, navigate to your forked repository on GitHub and copy the repository URL. Then, open your terminal or command prompt and use the git clone command followed by the copied URL.

This command creates a local copy of the repository, enabling you to work on the project files directly. Ensure you’re in the correct directory where you want to store the project before executing the clone command.

Making Changes and Committing

Now that you have a local copy, you can make your desired changes to the project files. Whether it’s bug fixes, new features, or documentation updates, this is where you bring your contributions to life. After making your changes, use git add to stage the modified files, then git commit to save your changes with a descriptive commit message. Clear and concise commit messages are essential for tracking changes and understanding the evolution of the project.

For example, a good commit message would be “Fix: Resolved issue 123 by updating the login function.” This provides context for future collaborators and helps maintain a clean project history. Consider following a conventional commit message format for better organization and automation.

Pushing Changes to Your Fork

Once your changes are committed, push them to your forked repository on GitHub. This uploads your local commits, making them available online. Use the git push command to upload your commits to the remote repository. This synchronizes your local changes with the online version, enabling others to view and review your contributions.

Regularly pushing your changes is crucial, especially when collaborating with others. This ensures that everyone is working with the latest version of the code and helps prevent conflicts. This also serves as a backup of your work.

Creating the Pull Request

Finally, you’re ready to create the pull request. Navigate to the original repository on GitHub and click the “New pull request” button. Select your forked repository and the branch you’ve been working on. Provide a clear and concise title and description for your pull request, outlining the changes you’ve made and their purpose. This is your opportunity to explain the value of your contribution to the project maintainers.

The pull request description should include context, the problem you’re addressing, your solution, and any relevant testing details. This helps reviewers understand your changes and accelerates the review process. Here’s an infographic illustrating the workflow: [Infographic Placeholder].

Ensure your code follows the project’s coding style guidelines.
Thoroughly test your changes before submitting the pull request.

Fork the repository.
Clone the repository.
Make your changes and commit.
Push your changes.
Create the pull request.

For more in-depth information on Git, visit the official Git website. To explore best practices for collaboration on GitHub, check out their collaboration guide. Also, consider following some open source project for real life example from here.

Featured Snippet: A GitHub pull request is a mechanism for proposing changes to a project. It allows developers to discuss and review code changes before merging them into the main branch.

FAQ

Q: What if there are conflicts between my changes and the main branch?

A: You’ll need to resolve the conflicts by merging the changes from the main branch into your branch and fixing any discrepancies. Then, push your updated branch to your fork and the pull request will be updated automatically.

Mastering GitHub pull requests is a valuable skill for any developer. By following these steps, you can confidently contribute to projects, collaborate with others, and improve your overall coding workflow. This process fosters collaborative development, enhances code quality, and streamlines the integration of new features and bug fixes. Start contributing today and become an active member of the open-source community or your team’s development process. Explore other collaborative coding practices, like code reviews and branching strategies, to further enhance your development skills and contribute effectively to software projects. Atlassian’s tutorial on pull requests is a great resource for further learning.

Question & Answer :
How do I create and/or send a pull request to another repository hosted on GitHub?

(In addition to the official “GitHub Help ‘Using pull requests’ page”,
see also “Forking vs. Branching in GitHub”, “What is the difference between origin and upstream in GitHub”)

Couple tips on pull-requests:

Assuming that you have first forked a repo, here is what you should do in that fork that you own:

create a branch: isolate your modifications in a branch. Don’t create a pull request from master, where you could be tempted to accumulate and mix several modifications at once.
rebase that branch: even if you already did a pull request from that branch, rebasing it on top of origin/master (making sure your patch is still working) will update the pull request automagically (no need to click on anything)
update that branch: if your pull request is rejected, you simply can add new commits, and/or redo your history completely: it will activate your existing pull request again.
“focus” that branch: i.e., make its topic “tight”, don’t modify thousands of class and the all app, only add or fix a well-defined feature, keeping the changes small.
delete that branch: once accepted, you can safely delete that branch on your fork (and git remote prune origin). The GitHub GUI will propose for you to delete your branch in your pull-request page.

Note: to write the Pull-Request itself, see “How to write the perfect pull request” (January 2015, GitHub)

March 2016: New PR merge button option: see “Github squash commits from web interface on pull request after review comments?”.

The maintainer of the repo can choose to merge --squash those PR commits.

After a Pull Request

Regarding the last point, since April, 10th 2013, “Redesigned merge button”, the branch is deleted for you:

new merge button

Deleting branches after you merge has also been simplified.
Instead of confirming the delete with an extra step, we immediately remove the branch when you delete it and provide a convenient link to restore the branch in the event you need it again.

That confirms the best practice of deleting the branch after merging a pull request.

pull-request vs. request-pull

pull request isn’t an official “git” term.
Git uses the request-pull(!) command to build a request for merging:
It “summarizes the changes between two commits to the standard output, and includes the given URL in the generated summary.”
Github launches its own version on day one (February 2008), but redesigned that feature in May 2010, stating that:
```
Pull Request = Compare View + Issues + Commit comments 
```

e-notes for “reposotory” (sic)

<humour>

That (pull request) isn’t even defined properly by GitHub!

Fortunately, a true business news organization would know, and there is an e-note in order to replace pull-replace by ’e-note’:

So if your reposotory needs a e-note… ask Fox Business. They are in the know.

</humour>