Git is a versatile revisioning tool, allowing many different kind of manipulations. This versatility however also leads to the fact that you can achieve the same goal in different ways. An example of this is my previous blog post: Branch/Merge Strategies. In this blog post I will discuss something similar, yet different… the usage of the master branch.
When working with different branches it is easy to do pull requests before merging changes into the master branch. The most common usage of this is to be able to do code review prior to the merge. There is however a lot more possible to assist your daily development process and achieve higher quality software.
In general you should do as much as you can before merging because up until that point it is straightforward as to what caused any problem, as you are only dealing with those changes. Another approach that needs to be taken is to automate as much as possible.
While the list of things you could do on a pull request is infinite, I explain the most common to do and what the benefits are.
Whenever you use a versioning system such as Git, you have many possible ways of organising everything. The Goal of such a versioning system is to keep track of changes, but how easy it is to find a specific change mostly depends on how you use it. That is why in this blog post I will discuss the way I like to write commit messages to guarantee a clear, readable and easy to track history.