As part of any good release process, you must have tools that associate with your process demands. Recently we spoke about our Continuous Delivery Process, which is a wonderful process that moves QA from the unified test system to a distributed test environment. But now merging and forking becomes a much more important feature of the repository system. More times than I like to remember, I have spent hours unwinding git history and realizing that a repository has been rebased instead of merged or vice versa. Assembla has simplified this by offering Merge Requests.
Merge Requests are a way to submit a piece of code from a branch/fork/commit of one repository to another branch or fork of another or the same repository. The author of the Merge Request is typically the author of the code, and will submit the code for Review to the same repository or for Contribution to another repository. Review Code and Contribute Code are located in the subtab of your Assembla git tool. This is where you will create Merge Requests.
Creating Merge Requests
When you first select Review Code or Contribute Code, you can make a merge request by clicking on "New Merge Request" and entering the necessary information:
The "From" area is either a branch, tag, or commit from this space. The "To" area has two necessary pieces of information - a space/git repo, which will offer a dropdown if you have upstream git repositories, and a branch that you want to merge to in this space. The space/git repo may be another tool in this space or another space completely. To make your life and your developers life easier, you should consider renaming your git repos to a human readable format.
After you continue from here, you move onto the review screen of your Merge Request where you will give it a Summary and Description on the left panel. Just as in a commit message, you are able to change ticket status within the Merge Request Summary or Description, click the "Learn More" link under the description for more information. Just a note, you can affect more than 1 ticket by listing them out, including adding different statuses for each ticket or use #tickets to reference all the tickets at once. On the right panel, you can review the contents of the Merge Request, including the Changesets involved, the Files Affected, and the Tickets Affected (as long as they are referenced in the commit messages).
Reviewing Merge Requests
Once you have created a Merge Request, you will be able to review your Open, Merged, and Ignored requests. Inbound Merge Requests are available in Review Code whereas outboud are found in Contribute Code.
Why would you create a Merge Request within the same repository? Let's look at how Assembla uses this. We have teams of developers that work from tickets. Each developer works within their own branch per ticket, say I am working on ticket #14505, I create a branch from my team's master branch named ticket_14505. This easily identifies this branch and isolates the code changes from any other code. Once I am done with my fix for ticket #14505, I create a Merge Request within the same repository for Code Review by peer developers from my source branch (ticket_14505) to the destination branch of master (the team's master branch). Since I named my branch a convenient name, its easily identifiable as a fix for ticket #14505. (I should also have referenced the ticket number in my changesets so it was associated in Tickets Affected). The other developers will review the code, then merge it into the team master branch once it is approved. The will find my Merge Request on the Review Code screen:
Here you can see the various pending Merge Requests and current votes on the right. The Source and Destination are listed below the title. Having a standard branch/tag naming convention helps greatly when reviewing Merge Requests. The screen defaults to only showing your Open Merged Requests, to view the Merged or Ignored requests, click on the buttons to toggle them on/off. You can filter by requestor in the dropdown.
Viewing a Merge Request
To open a Merge Request, just click on the summary. You will see various information and details about the Merge Request, including Discussion, Changesets, Files Affected, Tickets Affected, votes, versions, getting changes instructions and actions of "Merge and Close"/"Ignore":
The four tabs are self-explanatory, however a tab worth mentioning is the Tickets-Affected tab. This tab allows you to know exactly what tickets are being affected by the changesets in this Merge Request. If this were a merge to your production branch, you will know exactly what is going out in the release and you can even write your release notes from this page. Assembla often uses this page to convey to support and others what is being released in the current deploy. Try it for yourself, your CEO will love this page, ours does.
Any ticket that is affected by a merge request will have a subtab ("Merge Requests"). This subtab is a place where your team members can easily follow the code that affects a specific ticket. They can see where, when and by whom the code was merged or ignored. They can see what is the current status of the code associated with the ticket, not just the ticket status.
This feature is only available in the new Ticket Layout - which is becoming default soon, otherwise you can turn it on in the Settings subtab of the tickets tool if you are an owner of the space:
Ready to get started with Git?