Current Articles | RSS Feed RSS Feed

Announcing Advanced Merge Requests for Git

Posted by Andy Singleton on Tue, Mar 27, 2012
  
  


Today we are announcing Advanced Merge Requests for Git.  You can find them in your Git/Source tool under the “Contribute code” and “Review code” sub-tabs.  As a contributor, you can use a merge request to submit a change from your branch or fork.  As a reviewer, you can use merge request view to pull and test changes, vote on them, discuss them, and merge them.

We enjoyed testing this feature.  It's exciting for me to see code contributions piling up in the merge request list from our own developers, ready to go into the daily releases.  Merge requests are an important part of a Scalable Agile process by allowing you to select and release what's ready rather than slogging through a pre-planned iteration.  It saves time, improves quality, and increases creativity.

A year ago, I talked about four ways to manage code and simplify projects.  Merge requests help you implement two of them, which I will call "fork" and "branch" because you can submit merge requests from a fork or a branch.

Fork

git pull

 

 Branch

gerrit resized 600

In the fork workfow, contributors post merge requests from cloned or "forked" repositories. "Maintainers" pull the changes, test them, and commit them.  This is the github workflow that revolutionized open source development.

Fork workflow is good for independent teams and for people who work independently and are ready to maintain their own clones.  It puts some load on the maintainer, which we spread around in our implementation with features like voting.

 

In the branch workflow, contributors  make temporary branches of the master version and submits them as "changes." A core group reviews changes and accepts them.  Our implementation is modeled after the Gerrit system that Google uses for Android contributions.

Branch workflow is good for full-time teams that work closely together and for products where the master branch is maintained to be releasable.

You can mix these ideas.  At Assembla we use branches from master for incremental development, and we have some independent that decided to work on their own forks and contribute bigger chunks, less frequently.

How To Use Merge Requests

To contribute with a branch, "git branch" locally to create a branch for your contribution, and push your changes.  Now you can go to "Contribute code" under the Source/Git tab and select "New Merge Request."  Search for your branch, and write a description of your contribution. Optionally  use #<ticket> to link it to a ticket.

Now the merge request shows up in this nice list for reviewers.

merge request list

The list is sorted with the most recently active on top, and it shows the current vote and comment counts.  You can see your requests by selecting "me" from the user filter.

Click on a merge request to review or respond.  You will see something like the screen below, where we provide instructions for each role.

Review: If you have rights to review and merge in the target repository, you will see a reviewer bar.  To get and test the code, select "Get changes" to see the Git commands, or just select the clipboard icon to grab them.  Then comment, vote, or merge.  You can vote just by selecting the red and green buttons.  Ultimately, the goal is to "merge and close," accepting the change, or "Ignore," discarding the change.

Contribute: If you have rights to contribute in the source repository, you will see a contributor bar where you can submit a new version, after changes are pushed to the source branch.  In the branch case you will usually have both contributor and reviewer rights.  Speedup tip - if you are a reviewer, you can often fix a change and add it as a new version.  It works great if you create pairs to review each other's code.

merge request review

The review panel is under the Version bar.  You can see the discussion thread and write your own comments.  My favorite feature is the "files affected" tab, where you can see all of the changes and pop them open in an AJAX panel to see the diff.

Merge request events such as posting a request, comments, and votes, show up in the activity stream as "code reviews" with this icon ico code reviews.  You can subscribe to email alerts by going to the Stream tab > email notifications subtab > and selecting "Code reviews."

Past and Future

We started thinking about improving merge reqeusts a year ago when we embedded Gerrit and started using it in the Assembla development team.  We eventually decided that we wanted to bring our customers something that would be simpler to use, integrated, and available in local languages.

Now, we believe that advanced merge requests are a core feature of our scalable agile process.  We are committed to upgrading the Git workflows and to implementing merge requests for our other repository types.

Tags: , , , ,

COMMENTS

Very cool. We fell back to Git (and our own Gerrit) from Assembla Gerrit due to some clunkiness with forcing the multitenant model onto Gerrit. This will be a nice alternative to try and I hope it can provide a gentle introduction to Gerrit-style code review for many. 
 
I guess I'll try and see, but does anybody happen to know how/if/when Assembla commit message ticket integration is handled when using this system? When someone commits a merge request with, e.g. "Test #123" in the commit message, I don't want the ticket updated until/unless we merge to master. Is that how it works?

posted @ Tuesday, March 27, 2012 11:13 AM by Rob Heittman


In the "branch workflow", how can I prevent people from merging the code into master themselves? 
 
Assembla is missing per-branch permissions for git repositories, i. e. something like: 
- Every member can create branches (topic and personal branches) 
- Only some members can push to certain branches (for instance, "master", "version-2.1-stabilization", "version-2.1-releases", etc) 
- Every member can send a merge request 

posted @ Wednesday, March 28, 2012 4:06 AM by Pau Garcia i Quiles


It is a good idea. Now that we implemented the merge request workflow, we will add branch permission options so that users can design and enforce the branch workflow that they want. 
 
In the past, we did not enforce permissions on branches, because we think it is important to share code with all team members. There are three workarounds. 
* On most teams, you can ask people to agree not to push changes to a master branch. 
* With rollback capabilities, the repository is like a wiki where anyone can edit, but you can roll back changes that you do not like 
* You can make forks that have different permissions. You can even fork inside one space. 
 

posted @ Wednesday, March 28, 2012 8:31 AM by Andy Singleton


Andy, 
 
Currently we are using the "ask people not to push to master" strategy and it usually works. 
 
Also, I'm not sure "advanced merge request with branch workflow" is the best name. In KDE, we achieve that by using ReviewBoard can ask people to "please use ReviewBoard": https://git.reviewboard.kde.org/r/ 
 

posted @ Wednesday, March 28, 2012 8:50 AM by Pau Garcia i Quiles


Sadly, the programming language and structure that is used at the place I work at right now cannot use assembla...  
 
I was able to find a vendor that allows "workflow" based push and merge so that we could implement a QA process that allowed QA to "accept code change for testing", apply the change to the QA base, do a test and either pass or fail the change,. if it passes qa can "merge code with main", if it fails qa, it goes back to dev.. I should probably draw out a full workflow diagram that we implemented and I wouldnt be surprised if its very close to whats posted here... I think the problem that we will face, will be a QA bottle neck + check in dependencies, where two code corrections, a, b have been checked in, but a critical issue has been found and fixed, check c, that needs to be tested and pushed to main so that you can deliver a build to the customer.... or maybe its just a situation that's unique to us, as in our case., when you end up with a critical fix (c), the customer wants just that fix and not a,b as they dont have time to test a and b..... .. the wonderful world of healthcare software.

posted @ Sunday, April 01, 2012 4:43 PM by Zee


Any chance of seeing this feature for Mercurial?

posted @ Monday, April 02, 2012 11:14 AM by Eric


Yes, we will implement Mercurial merge requests.

posted @ Monday, April 02, 2012 11:15 AM by Andy Singleton


Hello Andy, 
 
any target when the branch permissions will be implemented ? 
 
Thanks 

posted @ Wednesday, April 04, 2012 8:23 AM by MarcJ


Great, that would be very helpful in our little development team! Unfortunatelly, I seem to don't get it completelly. What can be the problem when the subitems "Review code" and "Contribute code" are the same, that is, I can't really review and accept code (seems I don't have the permissions ...). But I don't find the permissions. 
May be it's some stupid mistake ...?! Thanks for any hints!

posted @ Tuesday, April 10, 2012 7:36 AM by Stefax


Hello Stefax, 
 
Merge request users general permissions that you have for the git tool merge request is issued to and from (see permissions in admin / security. If permissions are OK, can you open a support ticket for it with space name, we'll take a look? Here is a link: https://assembla-inc.assembla.com/spaces/AssemblaSupport/support/tickets/new

posted @ Tuesday, April 10, 2012 8:38 AM by Titas


Hi Titas, thanks. It was no bug! Probably I was just irritated by the fact that the items review and contribute look just the same. And I simply didn't get it that you can click on the headline, thereby opening the merge request for review.

posted @ Tuesday, April 10, 2012 10:45 AM by Stefax


We've been looking for something like this to setup and easy way to connect to Git

posted @ Thursday, May 31, 2012 4:48 PM by matt


Comments have been closed for this article.

Follow Assembla

twitter facebook youtube linkedin googleplus

Get Started

blog CTA button

Subscribe by Email

Your email: