With CollabNet TeamForge it is now possible to use feature branch workflow in addition to standard gerrit workflow to work on your changes. In this presentation you will learn how it works, why we have decided to implement it, how was it implemented and what were the choices we have made and challenges along the way.
Founded in 1999, CollabNet is truly one of the founding fathers of the open-source movement
Today thousands of customers rely upon on our solutions to develop high quality software at speed
We maintain a global presence with offices in SF, Houston, London, Berlin, Chennai, Tokyo
We have customers who are leaders across the industries and verticals they represent.
From Financials, Technology, Government, Service Providers and Other key industries like manufacturing, healthcare and department stores.
The patches I mention here are those that did not get its way into vanilla Gerrit. We want to give back to the community and are not interested in maintaining our own Gerrit version. Our extra patches are rebased over each version of Gerrit. So I think it is fair to say that we don’t have a fork. So what features do we deliver?
Here you can see the main features that we provide on top of Gerrit. We have TeamForge sync plugin with let us to maintain users and their access rights to Gerrit via TF Role Based Access Conrol model. We have notification plugin that delivers email notifications to users that use Gerrit as Git server. And we have our history protection plugin that assures that no branch will be deleted or rewritten by accident. Those have been presented on Gerrit User Summit in 2014. Last year I’ve presented Quality Gates wizard, a way to define your own submit rules without prolog. We also have Replication feature, which is based on Gerrit replication plugin, but allows managing and controlling of the replication from TeamForge. And this year features are Git LFS (which is based on the plugin available in Gerrit core) and the PullRequest. So let’s talk about pull request.
What is a pull request? Let’s start with a workflow. For a developer working on pull request it starts in similar way as in Gerrit.
One create a feature branch and create some commits. But instead of pushing it for review, the branch is pushed to the remote. We call it a feature branch. Once we have a feature branch on the server one can create a pull request. A request to pull the changes from the feature branch and merge it onto destination branch, which needs to be specified as well. Creating a pull request is equivalent to publishing changes for review. Then the changes are being reviewed, can be reworked, and after they are approved the pull request get merged into the destination branch. Then the feature branch usually gets deleted. So comes the question: how this can be mapped onto Gerrit?
The answer is quite obvious, if you think about it: Pull Request is a merge commit pushed for review. So everyone can do that in Gerrit. Prior to the version 2.13 the drawback was, that there was no way to review the changes of merge commit as those were not visible in Gerrit (unless there was a conflict that got automatically resolved). Fortunately David Grzegorczyk, a developer from Poland proposed a change, that enables a diff of merge commit against any parent. So, my colleagues were working on this change and with help of community, the change got merged. So now everyone can use pull request in Gerrit. Right? Well, not really. I would say that the pull request feature is available in Gerrit to people, who do not actually need/want it. Let me show you why.
Let’s have a look at the feature from a perspective of a Pull Request user that starts his adventure with Gerrit.
He will be able to create his branch with changes and push it to remote but that’s about it.
Why?
There is no user interface that follows the model that the Pull Request user is familiar with.
So he cannot leverage what he has learned while using other tools.
So for him Pull Request still does not exists. And that’s where our feature comes in.