Current Articles | RSS Feed RSS Feed

Git Review and Merge like a Boss

Posted by Michael Chletsos on Tue, Sep 11, 2012
  
  

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

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.

Merge request  Merge  origin master  to  repos master

 

Ticket Perspective

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:

Tags: , ,

COMMENTS

is this essentially the same as a pull request in github?

posted @ Wednesday, September 12, 2012 5:58 AM by Daniel


The functionality of merging on a website for git is similar to github's functionality of merging two git repositories. However, Assembla's Merge Request are tied closely to the Ticketing system and will enhance the overall Code Development and Release processes. Assembla is after all team collaboration tools, not just a glorified interface into git.

posted @ Wednesday, September 12, 2012 12:10 PM by Michael Chletsos


The "like a Boss" part is a problem, in fact. 
 
In an enterprise environment, we need to be able to "protect" some branches (e. g. stabilization branches) so that only reviewed code goes in. 
 
AFAIK, there is no way to prevent this in a reasonable way, i. e. not asking everybody to create a new space and not asking everybody to have its own Source/Git tab, which does not scale when you've got 60 developers. 
 
Or maybe there is a solution I don't know about? 

posted @ Friday, September 14, 2012 8:10 AM by Pau Garcia i Quiles


@Pau 
The easiest way to protect some branches is to have two repos. This creates clear division of permissions. RepoA is for Development, developers can create branches and merge around in there at their will. RepoB is protected. RepoA has Edit permissions for all team members. RepoB has Edit permissions only for Owners of the space. Developers can make merge requests from RepoA to RepoB without any problems. But only Owners can Merge into RepoB.  
 
This is the way you are able to protect your stable branches. This can be treated almost exactly the same as 1 repository if you setup remotes locally.

posted @ Friday, September 14, 2012 11:13 AM by Michael Chletsos


@Michael, 
 
That's too cumbersome. 
 
That means developers pull from RepoA but push to RepoB, and someone has to keep those two repos synchronized. 
 
Furthermore, it means it's the whole repository what is "protected". That's not what we want. What we want is to have a few "protected" branches, and the rest of the branches are "open" for all developers. 

posted @ Friday, September 14, 2012 7:30 PM by Pau Garcia i Quiles


@Pau - the idea behind having a protected branch is so that someone is in charge of it. The repos will be in sync the same exact way branches are in sync if you have protected branches, with a merge request. There is little difference between a branch and a forked git repository. Particularly if you setup remotes in your repository: 
so I have 2 remotes: 
origin 
team 
origin is the protected master repository. 
in my local repository, I have two remote setups, one for origin and one for team, then I create 2 local branches that track these branches upstream (git checkout -b team-master --track team/master): 
master 
team-master 
I can then treat them just like branches locally.  
 
However, after having said all this and stating that it functionally is the same, we have considered making certain branches protected. This would just be a setting that one could set, no promises - we have just discussed it.

posted @ Friday, September 14, 2012 7:41 PM by Michael Chletsos


@Michael, 
 
The two remotes are locally. But it's still two repositories (two separated Source/Git tools) in Assembla, and someone has to maintain those two repositories synchronized manually upstream so that people can pull and push locally. 
 
Compare this to what we do in KDE, for instance, where we use a code review tool (Review Board) and people submit code to review. It works more or less like this: when the reviewer/approver says it's OK, they click the "Ship it!" button and then the original author can commit that to the branch. 

posted @ Saturday, September 15, 2012 6:24 PM by Pau Garcia i Quiles


@Pau, 
 
What is the difference between branch maintenance and repo maintenance? Aren't they exactly the same?

posted @ Monday, September 17, 2012 8:57 AM by Michael Chletsos


http://feedback.assembla.com/forums/5433-feature-requests/suggestions/3048706-abilitity-to-add-comments-to-lines-of-code-inside-

posted @ Wednesday, November 14, 2012 6:19 AM by Konrad Podg├│rski


Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: