The pull request is where the rubber meets the road. One of the key points of the feature branch workflow is that the developer who wrote the code does not merge the code with
master until there has been a thorough peer review. After leveraging Github’s pull request features, once you have completed the feature branch and pushed it to the repo, there will be an option to review the diff and create a pull request.
In essence, a pull request is a notification of the new code in an experience that allows a peer developer to review the individual updates within the context of the update. For example, if the update was on line 18 of
header.html, then you will only see
header.html and a few lines before and after line 18.
This experience also allows the peer reviewer to place a comment, that will be communicated back to the editor of origin, on any line within the update. This review experience really allows everyone on the team to be actively involved in each update.
Once the reviewer has approved the editor’s updates, the next step is to merge the code. While this used to be preferred to merge locally and push to master, Git has really grown into this feature and I would argue that, today, it is mostly preferred to simply use the GUI tool in Github.
Now the question is, “how to merge?” Github has three options:
Creating a merge commit is ok, it will simply merge the new feature branch code into the
master branch, as long as there are no conflicts. Github will not allow you to merge if it knows there will be conflicts.
The squash and merge process is interesting as it compacts all the commits to this feature branch into a single commit to the
master branch. This may or may not be an issue depending on how your team wants to preserve history. If you are a user of the Angular commits, you may not want to use this feature.
Lastly, there is the rebase and merge. I am definitely a fan of this merge action since I have a preference for rebase. It will take all the commits of the feature branch and reset them to the latest head of the
master branch. If you did a rebase on the feature branch prior to creating a pull request, this process will be seamless and, in the end, the healthiest for the project’s history.
View all Courses