Current Articles | RSS Feed RSS Feed

Calling All Hackers - Automate Git and SVN Workflows, Get Assembla For Free!

Posted by Michael Chletsos and Titas Norkunas on Fri, Jun 28, 2013

A Contest for Hackers

Recently we released an exciting feature, Server Side Hooks for our hosted Git and Subversion repositories. Today we present to you our first Community Contest - write Server Side Hooks to get Assembla for free.

What can You do with Server Side Hooks?

Anything. Automate your workflow - reject commits that you don’t like (no commit message? tests do not pass? does not comply with a coding standard?), trigger events on external services, rename branches... You know, it's software, anything is possible.

People have submitted two hooks so far:

  • A Subversion hook that validates php syntax. Install it and never see anyone committing non-working code again. Thanks Jakub!

  • A Git hook that validates the commit message based on a regex and rejects if it matches. It defaults to looking for “wip” in the message - any commit message containing text “wip” will not be accepted to the repository. Thanks Ido!

This is just the tip of an iceberg of what is possible. Go crazy!

How to participate

  1. Submit a server side hook for Git or Subversion via Merge Request to our hoook repository.
  2. Tweet it out - don’t forget to include @assembla and #serversidehooks
  3. When your hook is accepted and merged by our team, you win 25 Assembla subscription dollars, and your entered to win amazon gift cards that will be given out at random to participants.
  4. Submit as many hooks as you want.
  5. The Subversion and Git hook that is most installed in Commercial spaces at the end of the contest wins an additional 250 Assembla subscription dollars.

As more people submit hooks, we will unlock more prizes.

Submission and Review

Get submissions in by July 31, 2013 to be considered for the contest. We will make our final determination of winners on August 31, 2013. 

Read more about submitting hooks (and our review policy) on the hoook wiki. Refer to this list to see all the participants.

Have fun and good luck automating your workflows!

Need help?

Have questions? Contact us on our dev group.

5 Comments Click here to read comments

Space Manager: Many projects, one team; One project, many teams

Posted by Jon Friedman on Thu, May 30, 2013

How do you see the forest but keep teams focused on their own trees? With Space Manager.

Assembla recently introduced the Space Manager feature to help service providers and companies with large projects handle two use cases:

  • Many client projects being serviced by one or a small number of development teams.

  • One complex project being developed by several development teams.

Space Manager, along with the new Tag feature, can help these companies manage their backlog better, let teams focus on their own work, and give clients and customers a restricted view of their own ticket lists but nobody else’s. It helps managers manage the “big picture” while making teams more efficient.

Use Case #1: Many projects served by one team

What if you are a service provider or custom development firm creating software apps for multiple clients? Or part of a corporate web site or application group serving multiple internal customers?

Then you want to maintain a master backlog of tasks, but also keep track of which tasks belong to which clients. You may also want to let your clients submit requests directly to the master backlog, and later view the progress of those tickets, but not be able to see tickets submitted by anyone else.

With Space Manager, you can set up a “Master Space” for the entire development team, then a series of “Child Spaces,” one for each client. The process will then work as shown in the diagram below.

As clients submit tickets, the tickets are tagged with the child space name of each client (in the diagram, “C1,” “C2” and “C3).


The space owner and designated tech leads have visibility into a master backlog of all submitted tickets. They validate and refine the tickets, then sort them in order of priority, taking account of the importance of the individual tickets and the need to balance the demands of the clients.

They then select the most important tasks to go into the “Current” milestone (or the current Scrum sprint, or the Kanban process).

The development team can see all of the tickets in the Milestone, Planner and Cardwall views, sorted by priority, and tagged by the client.

If you want to give clients visibility into their tickets you can do so, but they are restricted to the tickets in their own child space - they can’t see tickets (or messages, or repositories) from any other child space. 

Use Case #2: One project developed by many teams

What if you are working on a large project that is being created by many teams - perhaps an architecture team, a UI team, and a backend team?

Then you want to maintain a master backlog of tasks, but let each team keep track of its own tickets, documents and code, without having to sort through the work of the other teams.

With Space Manager, you can set up a “Master Space” for the complete project, then a series of “Child Spaces,” one for each development team. The process will then work as shown in the diagram below.

The product owner submits tickets to the backlog. The space owner and designated tech leads validate and refine the tickets, sort them in order of priority, and assign them to individual teams (in the diagram, “T1,” “T2” and “T3). They then select the most important tasks to go into the “Current” milestone (or the current Scrum sprint, or the Kanban process).


Each development team can see ts own tickets in the Milestone, Planner and Cardwall views, sorted by priority. They also see only their own messages, documents and repositories.

The space owners and tech leads can always see the “big picture” and communicate with all of the individual teams, while the team members can focus on their own artifacts, without needing to filter out work from the other teams.

There are several variations on this use case. For example, tasks can be assigned to Git forks or Subversion branches, and each fork or branch can be managed in a child space. 

Use Case #3: Many projects supported by many teams

 What if you need to support multiple clients with multiple development teams? Space Manager and Tags can help you there too.

You can set up a “Master Space” for the entire organizations, “Child Spaces” for each client, and child spaces for each development team.

Now tickets are tagged by the source (client, product owner, etc.) and by the assigned team. Managers can maintain the master backlog and see the global view at all times. Teams can focus on their own tasks and code. And clients can be given a limited view of their own tasks. 

How to use Space Manager


0 Comments Click here to read comments

Mandatory Code Review for Protected Branches

Posted by Sergiy Golub on Tue, Apr 09, 2013

Assembla Merge Requests adds a great value to code development process. Now it’s time to bring some more automation to the Code Review process. And here comes a new version of Protected Branches for GIT.

Old Flow

Previously, a feature development or a bugfix looked like:

  • Create a new feature branch based on current production master
  • Do some development and push code to new feature branch
  • Go to Merge Requests Tab and create a Merge Request from new feature branch to master branch

New Flow

Now, we have  Protected Branches, where ‘master’ branch is protected by your Tech Leads, it looks as follows:

  • No need to create a new feature branch, do development on master.
  • Push code to origin master

What is going to happen behind the scenes when you push:

  • A new temporary remote branch with ‘assembla-’ prefix will be created and your commits will be pushed to that branch, remote master will stay the same.
describe the image
  • A new merge request from this temporary branch to master will be created, you will see URL to MR in command line
merge request index resized 600

This occurs in 2 cases:

  • When you are a developer without write permission to ‘master’.
  • When ‘Mandatory review’ checkbox is checked for ‘master’. In this case, all pushed code will go through review process, no matter if pusher has write permission or not.
protection settings resized 600

To continue development on new automatic branch:

$ git fetch origin
$ git checkout assembla_1e65051188
$ echo “Hey, Merge Request Boss!” > WeContinueDevelopment # modify some file
$ git commit -a -m “We continue development to create new MR version”
$ git push origin assembla_1e65051188

We hope, you will enjoy the New Flow. To learn more about Assembla features or Sign Up for a Trial, click here.

1 Comments Click here to read comments

Develop Faster: Set Up Your Git Fork and Merge Network

Posted by Michael Chletsos on Mon, Mar 25, 2013

A Complete Guide to Setting Up and Working with a Git Forked Network

fork merge smI have spoken often about the Assembla process that we have been working in and how well it works for us, but how can you get the same benefits for your project? Well, there is no secret, its just a matter of setting up a development fork and merge network. The basic idea is to isolate development work from stable work. By isolating, all development work from stable work you have a clear path from developer to production. Although this process is not specific to Assembla, lets see how this will would work utilizing Assembla. One could tailor this process to work in any system, and it would be just as powerful, though not as convenient as with the tools Assembla provides.

  • Setup Development Space

First we need to setup a new space. You can do this from your Assembla start page by clicking the 'Create New Space' button. Depending on your account and plan, you might want to setup a public or private space. It does not matter which type of space you setup.

Create Space


  • Setup Origin Git Tool

Great, we now have a place to work within. We need to have a Git Tool, if your space configuration did not have a Git Tool, please add it from Admin tab and then the Tools Heading.

git description

Whether you just created a tool, or it came pre-configured, I highly suggest renaming the Git Tool by going to the Setting subtab. Here you can rename the repository to “origin” and set an extension if you like, for the origin repo, I do not like adding an extension – I like the origin named “project.git”. I like calling it “origin” since this is standard git terminology for the original point of the code.



  • Initial Commit to Origin

Now we have a Git Tool renamed to “origin” but no code in it. At this point, we can push code up to this remote repository and utilize it like we would normally utilize a git repo. Just to ensure everything is working, let's make sure we can read and write to the repo. Before you proceed ensure that you have added your public ssh key to your profile (found in the upper-right dropdown menu->Edit Profile->SSH Keys). Once your key is added, follow these instructions (replacing project.git with you appropriate project name) on your localhost to create a local repository that you will sync to the remote repository:

 $ git clone # will complain that you cloned 
an empty repo
$ cd project
$ echo “Project Readme File” > Readme
$ git add Readme # add Readme file to git tracking
$ git commit -m “Initial commit of Readme file” Readme
$ git push origin master # create a master branch in “origin” repo


We have just made our first commit to origin/master. If you prefer you could use the http(s) method to interact with your git repo. Https is particularly useful behind a firewall that does not have port 22 open for ssh (many corporate firewalls are setup this way), while still encrypting your data. Http(s) will have more overhead and therefore slower than the ssh protocol. It does not update your localhost with information as often as the ssh protocol (sometimes it looks like it is hanging when it is working) because it waits between actions before responding to your client.

first commit

You can view this file that was just created in your code browser by navigating back to your Git Tool in Assembla and using the Browse Code subtab. To see the actual commit, take a look at the Commits subtab.

Hint: When committing add status updates such as fixed #123 or re #123 to reference the ticket in your commit message and to post a link and commit message on the ticket.


  • Our First Developer Fork

Theory: One could just work in the origin repository. You can branch and commit to origin like you would any other repository, however, this can cause bottlenecks and problems for your development process. Say that developerA commits bad code to origin/master – they discover this through QA, UAT or CI, and developerB needs to perform a critical hotfix to Production. If all are committing to origin/master and deploying this to Production, then we have a bottleneck caused by developerA's bad commit. This commit must be reverted or possibly you could branch before the commit add developerB's commit to this branch, then deploy out to Production this branch. Ugh, that is dirty.

Another model may use release branches to help solve this. Release branches rely on the fact that no-one alters them between releases but takes overhead to cut them, coordinate developers and manage them. This becomes very hard to maintain across many, many developers and does not allow a free-flow of code from developer to Production, instead you must commit to several branches to ensure that you keep your Development branches and Release branches in sync. Often release branches become divergent from Development branches and you cannot patch them easily as there are different codebases and the merge results in conflicts or there is logic missing that is expected.

Instead, we introduce the Developer Fork. The Developer Fork is a repository that is based on origin, but allows the developer to maintain their own repository including branches, tags and commits. It also has one other nice advantage that is a little hard to see at first, but if managed properly, you will not run into strange merge problems with new work – all new work is applied on top of branches that are consistent with your current work. In other words, you will not get any of those annoying, you must merge before you can push errors.

To create the developer fork, go to your origin's Git Tool and then the Fork Network subtab, from here you can choose to fork your project. It does not matter if you do it to another space or within the same space. The considerations made to whether you will fork in the same space or to another space have to do with whether this is a new project being branched, if the developers will work off the same list of tickets, and if you have creation permissions in the space to create this fork amongst many other considerations. For our purposes and the purposes of most teams working on the same list of tickets, it is best to keep this fork in the same space – so that you can reference the tickets in the commits easily.

fork subtab

Once you have forked the repository go to the new Git Tool and rename it and give it an extension that matches the name in the Settings subtab. This will make it easier to talk about and remember where you are pushing code or merging to/from. For our purposes we will call it “fork”.

Advanced: Anytime you clone a repo, you are in fact creating a fork. You can then push this cloned repository to any remote repository. You may also connect any existing repository to any remote allowing you to maintain several remote repositories in a forked network in one local repo, you do not need to create a new tool or new space. If you already have two Git Tools in your Assembla space, you can add a “fork” from one repository to the other repository. Branches in git do not have to have a common ancestor nor do they even have to be related to each other; you can store completely different information in the same repository in different branches for git. So taking our origin/master setup in our space and a new Git Tool called “fork” and with the “fork” extension, we can clone this repository and then push a fork from origin back up to it. There are at least two ways to do it, each with different advantages:

 # Using “origin” repository as your remote origin for your local repository – 
typical for people who have read/write to origin/master
$ git clone # should have Readme file from before
$ cd project
$ git remote add project_fork # add remote
for “fork”
$ git push project_fork master # create a master branch in the “fork” repo

# Using your “fork” repository as your remote origin for your local repository –
typical for developer setup
$ git clone # will complain of cloning
an empty repo
$ cd project.fork
$ git remote add project_origin # add remote for
$ git checkout -b orig_master –track project_origin/master # switch to local
branch “orig_master” and track the origin/master remote repo
$ git push origin master # push the orig_master branch to the “fork” remote
(origin of this repo)

  • Other Developer Forks

You can repeat the process above as many times as you like. I prefer to do this on a per developer basis. But you can easily setup a team that works in branches and has a common fork/master. This is the fork per team methodology. The advantage here is you have a single point of control for batching releases per team. However this same advantage is also a disadvantage where you have a bottleneck if a developer has committed code that is not clean or is waiting on other code.

Theory: The advantage of the fork per developer is that each developer is responsible for their own fork/master, and if they commit bad code or are waiting on other code, they do not block any other developer. This allows releases to occur more often on a per developer basis. If you are not in an environment that can sustain many releases very often, then you would arrange the fork network a little differently. Instead of developers working in the fork of origin, they will work in a fork of the fork – yes a fork of the fork. Just make the fork from the fork of origin, and you will have a repository that can merge easily back to the first level fork (use the fork network for this and just fork from the team fork to create a developers fork that will merge back into the team fork).


  • Branching in Forks

Theory: In general it is good to create a new branch for all isolated work, i.e. each ticket that you work on should be in its own branch. This allows a developer to start and stop work, or wait while work is reviewed or QA'ed, but still moving forward with other work.

When working on ticket branches, which I like to call ticket_X where X is the ticket number, are disposable branches. Assembla has created a convenient way of maintaining disposable branches, in your Git Tool Settings subtab, you will see a section that allows you to denote the pattern for naming disposable branches.


Then when you Merge or Ignore a Merge Request that is based on this branch, the branch is automatically deleted from the repository – truly helps with keeping a clean Development Fork. It is important to understand that even if a branch is deleted, no code is lost, that is the beauty of git, all commits are still present and the branch can be recovered if necessary. Typically, the developer will also have these branches locally still and can push them back up.

delete disposable


  • Merging

Theory: The general rule of merging is that you only want to merge from where you branched or to where you branched. If you jump across branches, the merging will work, but it might have seemingly strange results or may affect files that you did not mean to affect. So merge from your fork/branch to your fork/master and from your fork/master to your origin/master but not from your fork/branch to origin/master. That is a simplistic view – I am assuming that fork/branch is always coming from fork/master – but this does not have to be true. And moreover, it will not be true when hotfixes are done.

When merging from a fork upstream to your origin or from a 2nd level fork upstream to the 1st level fork (fork per team), you can create a Merge Request from the Submit Code tab, choosing your fork/branch as the Source (“From”) and the fork/master as your Target (“To”).

merge create


  • Code Review

Theory: All code going into your fork/master should be Production-ready code. To ensure this, most teams will need a code review process. The Code Review process in Assembla can be accomplished in the Changeset view, which you can find from the Commits subtab where a reviewer can add comments directly in-line with the code, but more appropriate it can be done from the Merge Request subtab where you will submit a Merge Request from your branch to your master. You will choose your fork/ticket_X branch as the source and fork/master as your target. Then you will set a title and description and have the opportunity to review the new code that is potentially being merged to your fork/master. This is a good time to review that the code is as you expect it, this will prevent any gotchas later.

Hint: Add ticket status updates in your description with the same format that you can use when committing to your repo, i.e. fixed #123 or fixed #tickets to affect all associated tickets, to apply this status update once your Merge Request is Merged. 

Once the Merge Request is created from your fork/branch to your fork/master you will have an interface where the team can have a discussion, including the ability to leave @mentions to alert others to help with code review, a list of the changesets that will be merged, diffs on the files that are changed, and a list of tickets (based on commit messages that include #ticket_num) that are being affected by this Merge Request, in-line code commenting, and of course a place to vote on the Merge Request. If you give it a -1 vote, the system does require you to submit a comment, this is because it is typically not beneficial to just leave a -1 without any comment – whereas a +1 speaks for itself (I highly suggest leaving comments on what is proper in the code with a +1).   

merge request

Hint: Setup your CI server to automatically submit votes to your merge requests utilizing the API and/or JAMRb to run Jenkins builds off of your Merge Request. Authenticate with the Assembla Jenkins Auth Plugin.

If the Merge Request is merged via the “Merge and Close” button, the system will automatically merge to the target repository and the disposable branch will be deleted (if applicable). If Ignored, the disposable branch will be deleted and the Merge Request will be archived.


  • Deploying

Deploys should always run from origin/master unless you are doing some creative deploying where you want to test out branches in Production before merging them into origin/master (this is a highly advanced workflow and typically needs a level of coordination and architecture that most projects do not have nor can sustain as they grow). This means that origin/master should always be deployable and developers can trust that if they fork/branch or merge from origin/master it has good, Production-ready code.


  • Hotfixes

I mentioned that hotfixes are a bit different from regular merging workflow, well it can be true if you need to make a critical patch immediately. In this case its best to work from a branch of origin/master, even if you only have read access from origin/master this can be accomplished, since it is guaranteed to be in sync with your current Production if you always deploy origin/master. Once you have your fix in your local branch, you can push it up to your fork as a branch and create a Merge Request from fork/hotfix_X to origin/master; since you branched from origin/master you should merge directly back to it. To see how this would work in a developer fork with a remote of origin/master called orig_project and a local branch of orig_master tracking origin/master:

 $ git checkout orig_master # checkout the origin/master tracking branch on a 
remote called orig_project (not the origin of the local repository)
$ git pull # make sure it is up to date
$ git branch hotfix_ticketNum # create new branch locally
$ git push origin hotfix_ticketNum # push hotfix_ticketNum branch up to fork
remote (called origin locally)


Now you can create a Merge Request from fork/hotfix_ticketNum to origin/master and have Code Review before merging and then deploy to Production.


  • Conclusion

So that is basically how you set up a fork network in git for developers to be able to isolate their work and merge back to origin/master and from origin/master to their development fork.

To Learn more about other workflows, click here.

2 Comments Click here to read comments

Put Down Your Forks - Introducing Protected Branches

Posted by Titas Norkunas on Thu, Mar 21, 2013
Lets talk about forks. They are so awesome for open source. Why?
  • A fork is a natural way to give external contributors a place to work
  • Really, that is the main reason to fork
Look at the open source projects more closely. Only the external contributors - who are not part of the core team - work in forks. The core team members work with the main repository in branches.

A company does allow their developers to commit to the repository. A company does not want everyone to be able to merge to a release or master branch, using a fork for this is an over-complicated workaround:
  • Developers need to maintain forks
  • Additional setup to CI is required
  • Whenever a change to the repository configuration is made, it needs to be made in all forks (for instance installing a webhook)

Does it have to be so difficult? Not at all. Here is where Protected Branches are awesome and a clean solution to this problem.

A Protected Branch is a branch with limited write access. Specify members (or groups) of your team that will be able to submit code to a branch:

Protected Branches

Now, only these people will be able to push to the Master branch. Everyone else will have to contribute code through merge requests. They will be able to push to any other branch in the repo, but not Master.

Protected Branch

Protected Branches enable various common techniques - mandatory review from a senior developer, release manager that maintains release branches, feature freeze a release candidate. We have no doubt you will find even more use for it.

Sometimes you just have to leave that Social Coding aside and get some work done.

5 Comments Click here to read comments

The QA Conundrum - How Can We Move Faster?

Posted by Michael Chletsos on Mon, Oct 01, 2012

How can we get more quality out of QA and move faster?  Stop dumping your problems on them and put the responsibility on the appriopriate parties - the developers.


People regard QA as the defenders of Production. In an ideal world they prevent bugs from being released, but reality shows us otherwise. We find bugs in software even after QA is done, so what is QA preventing? They are preventing developers from taking responsibility for their code.

When working in accelerating projects, the development process and feature sets overrun QA with more and more work. Often the solution is to get more QA, but this does not improve the product nor improve efficiency.   

It's a complicated and long process to go back and forth between developer and QA. I would rather ask a developer, along with the person who defined the scope of work, to ensure a feature is working properly. After all, they are the ones who know the work and can fix the issues immediately.

Making developers responsible for fixing any issues in a release or development process, gives them the means and the motivation to be responsible for quality, something that is not available to the QA team. Let's give developers the authority to say this is ready to go to Production, not QA - after all developers working with Product Managers know when something is completed. 

In the future, we will explore how to change the QA role to be more effective in the modern environment of faster release processes. For more information on the development process, take a look at our other articles.

0 Comments Click here to read comments

Control Your Alerts with Notifications For Each Event

Posted by Michael Chletsos on Mon, Oct 01, 2012

You can now select the frequency of email alerts for each type of event.  You can have an Hourly Summary for your Ticket Events while having your Messages sent immediately and a Daily Summary for Team Code Reviews.  

In the past, I could only select one event frequency.  I like this feature  for myself because our teams have many updates on tickets, which would flood my inbox, so I want a summary for this, but I want to receive my messages alerts immediately and separately from this hourly summary of the tickets. 

events stream individual frequencies

We have copied over the frequencies from your previous settings for the Events you are notified on and maintained the frequency of "Never" for events that you were not subscribed to before.

Thank you Vitalie Danu for updating this feature and allowing us all to control our email once again.  I find this an extremely valuable addition to Assembla.

2 Comments Click here to read comments

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. 

1Review Code resized 600

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:

2new merge request resized 600

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).

3new merge request resized 600

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:

4review code resized 600

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":

5show mr2 resized 600

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.

6Merge request  Merge  origin master resized 600


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.

7tickets mrs resized 600

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:

8Settings  Default Views resized 600

9 Comments Click here to read comments

@mentions Popup Search - Hot Way to Get Attention

Posted by Michael Chletsos on Thu, Jul 12, 2012

Getting mentioned on Assembla just became a whole lot easier.  A couple of weeks ago, we released a feature that allows you to send @mentions to other team members (@mentions blog posting).  Want to mention someone now?  Just start typing @<name>

You will see a dropdown search

mentions dropdown

This will work in a ticket description, message, standup, etc.  You can search the username, firstname, lastname, or email address of the team member.

We hope you find this as useful as we do.  We have found it to help with our workflows on a daily basis.  I get thousands of emails a day and its hard for me to keep track of every ticket, I like to use @mentions to ask questions or know that someone else wants to get my opinion on a ticket or message, though it was not assigned to me.  It has made my life so much better and our process has less hiccups now.  You should try it yourself and see how easy it is to get someone elses attention.

Thanks Vlad Gurdiga and the rest of the team in developing another great tool that is easy to use and very powerful.

0 Comments Click here to read comments

All Posts

Follow Assembla

twitter facebook youtube linkedin googleplus

Get Started

blog CTA button

Subscribe by Email

Your email: