Understanding the GitHub Pull Request Workflow
GitHub allows developers around the world to streamline their development pipelines and maintain a solid history of their projects even while collaborating with many other individuals and teams. However, Git can only take a team so far; it’s a tool that can be used effectively or ineffectively, depending on the workflow you choose to abide by as your project matures.
To get the most out of Git, you need to know which workflow works best for your goals and team members. Among many variations is the GitHub flow approach: a workflow that centers on simplicity and branch creation for new features. This workflow pulls ideas from the "Gitflow" model to leverage the full power of branching, but it leaves out the "develop" branch to make things quite a bit simpler. To make this model work for your project, your team will need to know when to make pull requests and why. You will also need to stick to the basic steps to ensure your project's history remains consistent over time.
Steps in the GitHub pull request workflow
Unlike the similar Gitflow model, there is no need to separate hotfixes from the rest of your feature development branches. Instead of appearing directly on the main branch, these too are developed on feature branches to be merged in later after careful review and testing. The result is a flexible and adaptive system that sticks to the following key steps:
1. Local feature creation
This is where the branching begins. Unlike some other workflows, the GitHub flow model depends on your project's main branch being deployable at all times. This means that any and all features you intend to develop should be worked on in their own branches and later integrated back into the main when they’re ready.
There are multiple ways to generate new branches for your project's features in active development, but you will generally need to perform a
git branch operation with the desired name of your new branch, then manually switch to this newly created branch by using the
git checkout command with its name. You may also choose to simply create a new branch and switch to it immediately by using the checkout command with
-b followed by the name of your new branch.
2. Feature pushing
Once you have made a number of commits that you suspect are ready to be exposed to other developers working on your project, you can push them to your remote repository, where they can be seen by others interacting with your feature branch.
Pushing updates from your local branch to a remote repository is as easy as using the "git push" command with the local branch name and a remote name as well.
3. Pull request creation
With a completed feature, you’re ready to issue a pull request. This lets your project team know that your commits are ready for further review and (hopefully) merging. Besides alerting collaborators to the completion of your feature, a pull request also makes it easy to discuss details surrounding your proposed changes as well as modify those changes before they’re actually merged.
Pull requests can be activated on GitHub and managed there too. This is also the stage in which code is generally subjected to a formal review to ensure it fits the standards of the project and is safe to include in a given deployment. All manner of testing is typically handled at this point in the GitHub flow model, as opposed to how the Gitflow model would require features to be pushed first onto a development branch for further assessment.
This is the point where the repository collaborators discuss your code and make suggestions, or simply approve it. Expect to do some back and forth in order to comply with the continuous integration system automated testing and the opinion of others on your code.
5. Feature merging with main
Once all of the above steps have been completed, project administrators can take the final step and merge the completed feature code with the main.
Choosing a Git pull request workflow
There are multiple git pull request workflows to choose from in addition to the GitHub flow model described above, and each one offers unique advantages that might suit your team. However, at least one of these—the centralized workflow—can’t accommodate pull requests and should be avoided if you prefer to leverage such requests in your own project's history.
There are a few additional Git workflow models you might consider trying if you are planning on using pull requests, such as the afore-mentioned Gitflow model, the feature branch workflow model, and the forking workflow model. Each of these is great for certain applications and not so great for others. The forking model is particularly well-suited to open projects with many different collaborators, for instance, as repositories are neatly copied each time they’re forked.
Make pull requests more automatic with Mergify
The GitHub pull request workflow your team depends on can be made to function much more smoothly with the addition of Mergify's automation utilities. Manage merges, comments, review assigning, and more without mundane manual redundancies and wasted time. Find out how Mergify can make your development process a breeze today.