Git Merge Requests (MRs) play an integral role in DataOps. Therefore, we must have a profound (and keen) understanding of "everything" merge requests, including creating, reviewing, resolving conflicts, and merging the code in the MR's feature branch into the main/master branch.
Merge Requests Tips and Tricks
Here are some notes on what you can do with merge requests in DataOps (in no particular order):
Suggest Changes to a Merge Request
Merge request suggestions are a vital part of DataOps MR. They reduce the feature branch development and merge cycle time. Historically, suggestions could be given and applied, but the commit message was always a default message, resulting in the need to squash all the commits in the MR when merging with main/master. To retain an accurate commit history, developers and contributors would either have to go back and reword the commit messages after applying the changes or manually apply the suggestions locally.
This method has the potential to waste a lot of time. Now you can write a custom commit message when applying a suggestion, following best practices for your organization.
If a custom message is not specified, the suggestion is committed with a default commit message.
Notify Participants that a Merge Request is Marked Ready
DataOps includes the functionality of sending a notification to participants of the merge request when marking a merge request as ready. Alerting merge request participants that your merge request is prepared for review helps shorten cycle time and ensures that outstanding merge requests are merged faster.
Request a Follow-Up Review from a Reviewer
DataOps best practice recommends "two pairs of eyes on everything." This ensures "a manual check is completed before each pull request and code merge." For more information, see Pillar 5 on the #TrueDataOps website. This code review often generates feedback from the reviewer, resulting in the need for a re-review of the code.
You can request a re-review from your reviewer in the DataOps UI, triggering a To-Do item and email notification to alert your reviewer that you need a follow-up code review.
Mark Changes as Viewed in Merge Requests
Reviewing merge requests containing large numbers of files can be challenging. These reviews are often inefficient because you often end up reviewing work that has already been reviewed.
In DataOps, you can mark files as reviewed (see image below for details) to mark that the files have been reviewed, staying up to speed with what has already been reviewed and what still needs to be reviewed.
Lastly, as highlighted at the top of this doc, resolving merge conflicts are a relatively common part of merging feature branches into the main/master branch. For more information on this topic, navigate to the Resolve Merge Conflicts doc.