Pull Requests in SCM-Manager
The general Idea
In software development the four-eyes principle is best practise. There are different ways to achieve this. If you do not have the possibility for pair programming, another way to gather feedback are peer reviews. Depending on your personal preferences, these can be done one-on-one in a direct conversation, in a complete asynchronous process where nobody meets another, or in all gradation between these extremes. However you decide, there should be a place where you can keep track of your review process. An established way are so-called “feature branches”. The changes are developed on a separated branch and will be merged into the main development only after the review. This has several advantages, among others:
- The changes are separated from the “production” code, so in the first place no harm can be done.
- It is easy to extract the changes. A simple diff is sufficient.
- In a team, multiple feature branches can be actively developed at the same time without interference.
- There is no need for fear to break anything as long as you are on your separated branch.
How to do it in SCM-Manager
In SCM-Manager, the developer of such a feature branch can create a “pull request” whenever he deems that his work is done. The word “pull” is chosen to imply that it’s not the developer of the feature who actively pushes his changes, but the changes are pulled from the other side into the main branch. This principle is widely known from open source development.
To create a pull request, the developer selects “his” feature branch (called “source branch”), the branch, where the changes should be merged to (called “target branch”), and creates a title and an (optional) description of his changes. SCM-Manager determines the changes between the branches. In different tabs you can see the commits that are present only on the source branch and the diff of the changes made on the source branch.
The main idea now is, that a peer of the developer can take a close look at these changes and make
comments. These comments can can be related to
- the pull request as a whole,
- a single changed file, or
- a concrete line in the diff.
Furthermore, you can create a task instead of a simple comment. Tasks are handled somewhat differently: They are tagged specially, can be marked as “done”, and you can configure workflows.
In bigger teams, not everyone might be able to review each feature, for example depending on technical skills. The creator of a pull request can therefore suggest reviewers in his pull request. Reviews themselves can set flags, whenever they approve a change.
The final step is either the merge or the rejection of a pull request. The merge can be done in different ways (simple branch merge, fast forward, rebase or squash). If you want to keep your repository tidy, use the opportunity to delete the feature branch at this point.
Examples
You can take a look at a simple demo repository with several pull requests in different states:
- A merged pull request,
- a rejected pull request,
- an open pull request, that is in progress
- and finally a conversation example where the Secure Code Warrior Plugin provided some lessons to the mentioned security issue.
Do you have any questions or feature requests regarding pull requests in SCM-Manager? Feel free to ask right below this topic.