Last month, we launched the DevOps Dojo – a website sharing our thoughts on the cultural and technical aspects of adopting the DevOps way of developing software. We’re far from having it all figured out. And in many cases, we know what we should be doing, but are only starting to actually do it. (Probably sounds familiar, no?) But since transparency is both a big part of our company culture and a big part of DevOps, we don’t mind opening the kimono a bit.

On Thursday we kicked off a new community event series called the Open Dojo where we gathered four Atlassians in various roles into a Google Hangout and talked about the particular challenges facing distributed teams who decide to embrace DevOps principles. Using the Hangouts OnAir option, we were able to broadcast live and take questions from viewers. What resulted was a lively conversation covering culture, tools, technologies and logistics.

If you missed the live event, we posted the video on the DevOps Dojo. Check it out!

Enter the Dojo

Recently we’ve given more flexibility and granularity in the way that your code is exposed: 2.0 introduced the ability to protect certain branches with branch permissions, and 2.4 allowed you to expose individual repositories outside of your core development team with repository permissions. Today, we are pleased to announce Stash 2.5, the final piece of the puzzle: public access to projects and repositories.

Try Stash 2.5 Now

Public access to projects and repositories

Public access provides users with read-only access to select projects and repositories without having to log in or have an account in Stash. Opening up access to Stash allows you to:

• Broadcast your code to a wider audience who generally don’t have access to your source.
• Simplify setup of build servers and automated systems without requiring a log in.
• Link from other systems like JIRA or Confluence, to give users access to code without requiring authentication.
• Create open-source projects or repositories.

In Stash, public access increases cross-project, cross-team, and cross-tool collaboration and visibility. Administrators can easily open up access to single repositories or entire projects, allowing anonymous users to browse code via the web UI, or clone it using any Git client. Internal or external anonymous users (or tools) will have read-only access to public assets in Stash. This lowers the barrier to discovering, collaborating on, and contributing code in Stash – for everyone.

Broadcast your code to a wider audience

These days, enterprises are constantly trying to encourage developers to collaborate, and suggest enhancements or fixes. Most core development teams can already view everything in their project in Stash; this is about opening up access to a larger group of developers. This allows external users to get visibility into your project’s source code, while still ensuring that only core team members have write access to the repository.

Simplify access from build servers and automated systems

By turning public access on, you can simplify the configuration of your IT infrastructure. Build systems such as Bamboo or Jenkins need to clone Stash repositories. Git submodules reference other repositories in Stash. Scripts update Git repositories on several servers at a time to get the latest code just before a test run. All these scenarios can now access Stash without requiring a login.

Link from other systems 

Linking to code assets from other internal systems is common – wikis, issue trackers, project management tools, documents, and more. Stash 2.5 allows you to link to your code assets from any system, without requiring non-developers to have an account on Stash. Nowadays, code bases contain documentation, images, human-readable configuration files, and BDD specifications. It’s great to be able to point your product managers, designers, quality assurance staff, testers, and documentation teams to those assets without requiring them to know Git, or have an account on your Stash instances.

For JIRA issue tracker users, Stash commits appear in the source tab of JIRA issues, regardless of who the user is or whether or not they’re logged in. Now, if a repository or project has public access enabled, when you click on the “view full commit” button, you can see the full source behind those commits in Stash.

Go open source, but keep the code on your own infrastructure

Many businesses ship source code to the public as part of their releases. APIs, connectors, client libraries, and integration code examples can all make up part of the deliverables provided to your customers – so why host them on an external service that you don’t control? Public Stash projects and repositories allow you to deliver code straight from your servers, using the same infrastructure you use for hosting your internal source.

Refined collaboration with pull request improvements

On the Stash team, we’re constantly looking for ways to improve the experience of existing features. In Stash 2.5 our development team found ways to refine pull requests and keep teams in the flow of development during code reviews.

Edit an active pull request’s destination branch

When creating a pull request in Stash, you define the destination (or target) branch you want to merge your code changes into. It’s easy to accidentally create a pull request with the wrong target branch, and then you have no choice but to decline and recreate it. This is not ideal. In Stash 2.5, you can change the target branch for an active pull request. This can be useful after a cut of a release branch, or if a mistake was made when the pull request was first opened.

Get more context in diffs

Context is king. We know instinctively that bug fixes are 90 percent about fact finding, context, and discovery, and only 10 percent about actual code changes.

Seeing more relevant content when you need it is highly beneficial, so we’ve added a seamless way for you to expand the lines of code you see around the diff in a pull request or commit. This allows you to see up to the whole file, if you want. The goal is to simplify the code review aspect of pull requests.

Mailmap support

Over time, Git repositories evolve, committers change, their emails change; everything is in constant flux. Starting today, Stash understands the directives in the .mailmap configuration file (see Mapping Authors for the format). With this, Stash can properly track users – even when they commit from multiple email addresses, or with different names (provided they record the changes in the .mailmap file).

Go public with Stash 2.5

Foster external participation and enjoy even more streamlined code collaboration with Stash 2.5. Start a free trial and get up and running in a matter of minutes.

Try Stash 2.5 Now

Already using Stash? Your upgrade to 2.5 is just a click away. Check out our full release notes to get started.

See, I love working with nerds. Especially software nerds. I love helping make their 9-5 more productive and less painful. If that describes you too, then read on–we need you.

So what does a Technical Product Marketer do all day? We research, which might mean reading up on new developments in the industry or getting involved with our internal dev teams or tinkering with code or all of the above. Then we write. Landing pages, blogs, tutorials, sometimes ad copy, then more blogs. We engage with other people in the software field and exchange ideas via Twitter,  forums, meet-ups, and speaking at conferences.

It’s a helluva lot of fun, especially at a place like Atlassian where we have tremendous creative freedom. Not every company would let my say “pee” publicly, for instance. And because Atlassian doesn’t use the traditional sales model, we don’t have to hold useful product information hostage in exchange for people’s email addresses. But it goes beyond lexical latitude. We largely get to dream up our own projects. And when we’re given direction, it comes in the form of an interface, if you will. We get to design the implementing class.

Even this blog is an example of that. Nobody asked me to write this. A few of us Advocate/Evangelist-flavored folks got to talking at a recent EclipseCon conference about how rewarding the work is, so I decided to advertise that a bit since we’re expanding our team.

If you’re ready to roll up your sleeves and help other developers be more awesome, check out this opening. If you don’t see your perfect fit listed, apply anyway and tell us about the role you’re looking for. Come play on our team.

ps: Yes, the rumors of plentiful office beer are true. And ping-pong.

Try FishEye and Crucible 3.0 Now

Optimized performance

The FishEye and Crucible team have been laser-focused on improving dev speed for our users. Our aim is to optimize performance from the moment you start to index your repositories to when you close a code review. It’s important for us to continue to help you save valuable time in your development process.

In FishEye 2.8 we focused on improving load times on key pages like the activity streams and projects lists. Continuing our focus on performance in 2.9, we delivered improvements to shave off seconds for several common operations between JIRA, FishEye, and Crucible–specifically the source and review Tabs. Then in 2.10, we slashed server load and made every operation faster, especially for Enterprise teams: page loads, reviews and reports. We continue the performance theme in 3.0.

A newer, faster Subversion indexing engine

Take a deep breath Subversion users; you no longer have to wait for a full index of your Subversion repository in order to start using FishEye and Crucible. Our newest release uses intelligent indexing to make viewing your latest changesets and creating reviews available while the indexing is in still progress. Exhale!

Check out the difference from data tested on a load testing instance of FishEye and Crucible comparing index scanning times of 3.0 and 2.10.

The improvements bring these advantages to Subversion users:

• Get productive ASAP: Viewing recent changesets and creating reviews is 10 times faster.
• Understand progress: New progress screens give you a better understanding of how long it will take to index your repository.
• Faster JIRA integration: Information in your JIRA source and review tabs is available while indexing is being performed

Even more performance gains

We did not stop there. We want to make ensure FishEye and Crucible stay fast as you grow. A huge focus was put on improving concurrent performance. You will notice improvement across the common operations you use everyday like creating review and browsing commits.

• Faster source browsing: we upgraded our internal database (to InfinityDB-3), this means greater concurrent access speeds and a better browsing experience
• Quicker review creation: the techy details, we optimized some SQL statements when creating or modifying a review in Crucible. What it means to you, the time to create or modify a review is cut down to save you valuable time.

See some of the browsing improvements from a load testing server comparing FishEye and Crucible 3.0 to 2.10.

Streamlined pre-commit reviews

Simply put, a pre-commit (or patch) review means reviewing code changes before they are checked-in to a repository. Typically, teams adopt pre-commit reviews as part of their code review workflow for reasons such as:

• Catching defects early: Ensure other developers on your team will not get affected by defects or bugs that can be found during a review.
• Keeping code clean: Guarantee that all code that gets into the repository is of high quality.
• Enforcing process: Make sure that reviews are not indefinitely postponed, or pile up to the point of never getting done.

Command line interface (CLI) pre-commit reviews

Until today, Crucible has been handling pre-commit reviews by uploading patch files through the Crucible user interface. We wanted to streamline this process so developers can stay in the flow. Crucible 3.0 introduces the command line interface (CLI) tool which allows you to generate pre-commit reviews, or update existing ones from where you already are: the command line. No logging into Crucible, no context-switching. This shaves off valuable time from the review process, and keeps your coders coding.

The CLI pre-commit reviews works for all supported version control systems including Subversion, Perforce, CVS, Mercurial, and Git.

Iterative pre-commit reviews

Code reviews are naturally iterative, and pre-commit reviews are no different. Let’s face it: Almost all reviews find something that needs to be re-factored or reworked, and it’s not unusual for reviews to include several revisions. Crucible automatically tracks what you’ve reviewed at the file and revision level, as well as comments. This ensures that you’re presented with only the latest changes, and don’t have to wade through the rest. Crucible 3.0 makes it simple to manage reviews throughout the iterations:

• Outdated files: Know when a new revision is available and include it in the review with a single click.
• Tracking as you go: Crucible tracks which files and comments you’ve already covered, then resets them as new revisions or comments are added.

Iterative code review makes it simple for teams to collaborate around code changes in order to ensure the highest code quality.

A brand new experience

Following the lead of JIRA and Confluence, FishEye and Crucible 3.0 introduce a new user experience that follows the Atlassian Design Guidelines (ADG). The goal is simple: Put key elements front and center, so developers can stay in the flow and work faster. The improved design is just the beginning of making it easier to navigate FishEye and Crucible.

New global header

When logging into FishEye and Crucible, one of the first things you’ll notice is the new global header. Navigating FishEye and Crucible is simpler with quick access to recent repositories, projects, reviews, and people.

Application navigator

Many FishEye users connect to other Atlassian applications, like JIRA or Bamboo. Users can now easily switch between FishEye and JIRA–or any other Atlassian application–all from the FishEye and Crucible header. No more bookmarks in your browser; we do the job for you.

JIRA source and review tab redesign

The key ingredient to any source code manager is its relationship to issues. Many FishEye users link their source to JIRA, and close the loop between code changes and the tasks that prompted them. We wanted to simplify the experience but still give users the important information they need to make decisions around their issues.

Improve your dev speed with FishEye and Crucible 3.0

New to FishEye and Crucible? Start a free 30-day trial and get up and running in a matter of minutes.

Try FishEye and Crucible 3.0 Now

Already using FishEye and Crucible? Your upgrade to 3.0 is just a click away. Check out our full FishEye and Crucible release notes  to get started.

Interested in the latest Stash release? Check out What’s New »

The distributed nature of Git gives development teams a plethora of options when choosing how to collaborate on projects. Teams migrating their development to Git need the flexibility to best work with code in a distributed enterprise environment. Common practices have emerged using branch- and fork- based workflows, igniting debates on how they can best be used in the enterprise.

Today we’re pleased to announce Stash 2.4, which offers the choice and flexibility enterprise teams need to manage their Git development workflows. This release introduces several key features to manage and collaborate on your Git repositories behind the firewall–forking, a distributed development workflow popularized in open source development, along with personal repositories and per-repository permissions. Choice, flexibility, control–that’s Stash 2.4.

Try Stash 2.4 Now

Collaborative Git Development with Forks

To fork simply means to create a clone of a repository, including previous history, on the server side. Forks in Stash provide developers with a workflow to contribute code back to a repository for which they do not have write access–adding a layer of control into your development process. In Stash, clicking the ‘Fork’ button on a repository creates a copy that is tracked by Stash and modified independently of the original repository, insulating code from the original repository to unwanted changes or errors. You can fork a repository into any other project in Stash for which you have admin access, or create personal forks and give other developers access. Stash lets you easily merge changes between forks through pull requests.

Why fork?

• Contractors – Allow external developers to contribute to a project while only core team members have write access to the repository. Contributors can simply fork a repository and contribute changes back via pull requests.
• Large teams – With hundreds of developers working on the same repository, the volume of branches and activity in the repository can turn into noise. Forks provide a way for teams to work separately while constantly syncing new additions from the core repository into their project.
• Experiments – Whether you’re participating in ShipIt, spiking a project, or simply prototyping a feature, experimenting on forks gives developers the option to trash changes without polluting the main repository with commits if the experiment goes nowhere.

For an in-depth look at why an enterprise would want to adopt forks see “Why Forks?“.

Contribute changes via pull requests

The beauty of forks is that changes being made on the forked repository will not affect the main code line. Once a fork is ready for primetime, a request can be made to merge it into the original repository. Stash and pull requests facilitate the process of merging those changes. This gives other developers an opportunity to review and discuss the changes before they become a part of the main codebase. From there the changes can be merged based on the pull request settings and branch permissions in the original repository.

Personal Repositories

In Stash 2.4 we’ve added a way to create personal repositories that are not related to other projects. This gives developers the freedom to innovate and store their private snippets of work, kick-start their own project, contribute a bug fix for a project they are not a member of, or add a feature to a common component maintained by a small group in an organization. Keep your personal repositories as open (or closed) as you want, then use repository permissions to collaborate with other users and groups if and when you are ready.

With the introduction of personal repositories and personal forks, we needed an easily accessible place to summarize the information. So we revamped user profiles, too.

Repository Permissions

Stash permissions aim to keep your code secure, and give you the confidence that the right developers have the right access. Early in Stash’s development we introduced two key permission sets: Global permissions to provide control or delegate user and group access to projects, and project permissions to control read and write access per-project. In Stash 2.0 we added a deeper level of access control–branch permissions–to enforce who can commit to specific branches in a repository. Stash 2.4 adds even more fine-grained access control to Stash; you can now set permissions at the repository level.

Administrators can keep projects as open or closed as they want. Grant access to individual repositories within a project without making the entire project available to the user. There are several scenarios where this can benefit your workflow:

• External developers – Opening up broad access to your repositories can be nerve-racking when working with external developers. For a given project, your core team should have access to all repositories, while only select repositories are available to contractors.
• Open up access – Many teams restrict write access to a small group of developers for specific projects. To foster collaboration you can open up view access to the rest of an organization so other non-core team members can fork and contribute.
• Delegate administration – Save valuable time by providing administration access for a repository to trusted team members, giving them the freedom to manage specific repositories.

Stash lets you choose how you and your teams work with distributed code, and that flexibility means you can work and ship faster.

Always Fork Before You Commit With Stash 2.4

New to Stash? Fork today with a free trial and get up and running in a matter of minutes.

Try Stash 2.4 Now

Already using Stash? Your upgrade to 2.4 is just a click away. Check out our full release notes to get started.

• Invite him to a screen sharing session
• Copy my code to a snippet hosting site and share the link via HipChat
• Commit the refactored code to my Stash repo and send him a pull request

Most developers would probably have been fine with any of those options, but none was satisfying to me. Bob and I were already engaged in a detailed discussion via HipChat about my refactoring, and being able to code collaboratively would have been ideal.

Bringing it to life

The situation above isn’t a first for me. In fact, it happens all the time – and I’m sure I’m not alone. For ages I’ve longed for a real-time collaborative editor where my code lives. Many have tried to create a solution like this, but none have proved useful for me.

So a few weeks back when my colleague Tim Pettersen and I were discussing what we should work on for our quarterly ShipIt project, I suggested that we solve this problem. One day of hacking later, we managed to produce a solution.

Introducing the Stash Realtime Editor Add-on

The Stash Realtime Editor makes it possible to edit files in real-time directly from the Stash interface – no cloning, no IDE, no local editor. Because it’s in real-time, you can share a link with your colleagues to collaboratively edit or review code together. Once you’re happy with your edits, you can commit them directly to Stash without the need to push your changes up to the repository. Your commit gets stored in a new branch and can be merged in with a simple pull request.

This add-on adds a real-time editor directly into Stash using the fabulous Firebase service and its awesome Firepad operational transform (OT) based editor. OT makes it possible to edit files in real-time with reliability and predictability, and allows users to see what other users are doing inside the editor (e.g., selecting, highlighting, typing, etc.).

The Stash Realtime Editor works even if you lose network connectivity. If you’re working on a file with someone and happen to suspend your laptop, resume your work on a train, and then come back online at home, your changes will sync up exactly as you would expect.

The Stash Realtime Editor is a free add-on for Stash. Look for it in the Atlassian Marketplace…

Learn more

Interested in the latest Stash release? Check out What’s New »

What do you get when you combine a razor-focused release cycle and implementing one of the highest voted Stash feature requests? It’s Stash 2.3, and it’s available today. Today’s release of Stash 2.3 introduces features for Enterprise teams (single sign-on), Git operations (submodule recognition and branch deletion) and making Stash even more scalable (the SCM Cache plugin).

Try Stash 2.3 Now

Crowd Single Sign-On Support

Many enterprise teams use Atlassian Crowd to integrate and deploy single sign-on (SSO) using popular directory servers such as Active Directory or OpenLDAP. In response to many votes from our users, Stash now supports Crowd SSO.

• IT administrators can centralize user management through Crowd and provide SSO for all Atlassian apps with minimal configuration.
• End-users enjoy the convenience of logging in once to any Atlassian application, avoiding the interruption of repeated authentication across other applications. Log in once, and you’re automatically logged into all applications connected to Crowd, including Stash.

Virtually everything in Stash is pluggable and authentication is no different. Our new plugin based authentication allows you to integrate Stash with other single sign-on solutions.

Even More Scalable

The Stash development team’s approach to Stash performance is simple: keep it scalable and speedy. Stash maintains fast response times and limits memory consumption by using streaming, paged APIs and fine tuning the many Git operations that we use to build the data displayed to the user. We use a mixture of automated performance tests and manual profiling to ensure every last drop of speed is squeezed out of our software. One of the recent results of our focus on performance is the Stash SCM Cache plugin.

Large instances with continuous integration (CI) or other automatic tooling set up to poll Stash for changes can end up with high load on their Stash servers. Consider for instance a CI server that has a number of builds set up for a given repository. Each of those builds polls Stash for changes and when it detects a change, it starts a new build. If your CI server supports parallel and/or chained build steps, each of these builds typically results in multiple clone operations of the same repository. The result: lots of polling for changes, and bursts of clones of a repository when a change is detected.

The SCM Cache plugin adds a caching layer that caches the pack files generated by Git during a clone operation on disk. This greatly reduces the CPU hit on your server and drastically improves response time when you experience repetitive requests from continuous integration. Check out some results from a recent test.

Read more about installing and configuring the Stash SCM Cache Plugin on your Stash server.

Delete Branch

Git, unlike some other SCM systems, makes branching and merging your codebase easy and cheap. However, one side effect is that you can often end up with large numbers of calcifying branches cluttering up your repository, long after they’ve been merged into master.

Up until now, deleting branches after they’ve been merged has been a manual process from the command line (read: it usually never gets done).

Stash 2.3 provides a simple way to delete the branch when you merge the pull request. As you might expect, Stash checks on a few things before allowing the deletion–the branch being merged will not be deleted if:

• The branch is the default repository branch.
• The user does not have permission to delete the branch.
• The branch is subject to an open pull request.

Save your team time; automate the process and keep your code organized with the simple click of a box.

Git Submodules Recognition

Git submodules allow you to nest external Git repositories within the directory structure of your own repository. Submodules are commonly used to embed external codebases–such as shared libraries–which are updated independently of the main project. For a more thorough introduction to submodules, along with some common usage patterns, check out our overview on Git submodules.

Stash 2.3 makes it easy to identify Git submodules through the Stash user interface:

If Stash recognizes the external resource hosting a particular submodule (Bitbucket or Github, for example) it will generate a link to the submodule’s home repository in the Stash UI, so you can easily click through to the relevant project.

Get More Out Of Your Git Repositories With Stash

New to Stash? Start a free trial today and get up and running in a matter of minutes.

Try Stash 2.3 Now

Already using Stash? Your upgrade to 2.3 is waiting for you. Check out our full release notes to get started.

SourceTree is a free Git desktop client for developers on Windows. Say goodbye to the command line and use the full capabilities of Git through SourceTree’s beautifully simple interface (and stop being jealous of what your Mac friends are using).

A simple, powerful Git client

SourceTree for Windows simplifies how you interact with Git repositories so you can focus on coding.

• Get your team up and running using common Git commands from a simple user interface
• Manage all your Git repositories, hosted or local, through a single client
• Put Git commands at your fingertips: commit, push, pull and merge with just one-click
• Use advanced features such as patch handling, rebase, shelve and cherry picking
• Connect to your repositories in Bitbucket, Stash, Microsoft TFS or GitHub

Perfect for Git newbies

SourceTree was built to make Git approachable for every developer – especially those new to Git. Every Git command is just a click away using the SourceTree interface.

• Create and clone repos from anywhere
• Commit, push, pull and merge
• Detect and resolve conflicts
• Search repository histories for changes

Visualize your repositories

SourceTree keeps track of code activity and provides an at-a-glance view of everything from projects to repositories to changesets.

Use SourceTree’s Bookmarks to get a real-time, aggregated view of all your projects and repositories. Jump directly to the changeset graph to visualize changesets across multiple branches and forks.

Powerful enough for Git veterans

SourceTree makes Git simple for everyone, but also makes Git experts faster and more productive. Review your outgoing and incoming changesets, cherry-pick between branches, create and apply patches, rebase, shelve changesets and more with lightning speed.

Git one-stop shop

Atlassian offers a full complement of tools that will help you and your dev team make the most of Git. Whether you’re working on Mac or Windows, behind the firewall or in the cloud, Atlassian’s family of Git tools will bring you the power of Git while making adoption a breeze.

Connect to the cloud or behind the firewall

Thanks to hosting services like Bitbucket, many small teams working with Git repositories begin coding in the cloud. Connect SourceTree to Bitbucket’s free unlimited private repositories to easily manage your Git repositories from the SourceTree interface.

Stash, Atlassian’s Git repository manager for Enterprises, makes it simple to manage your Git Server – behind the firewall. With powerful two-way integration, Stash and SourceTree make it easy for your team to develop with Git. SourceTree can discover and fetch your Stash repositories. And one-click clone operations get you the source you need fast.

If you don’t have Stash or Bitbucket yet, not a problem, SourceTree for WIndows works with any Git repository, including GitHub, Microsoft Team Foundation Server or your own Git server.

What’s coming next?

We received great feedback from the SourceTree for Windows private beta users (a huge thank you). We will continue to push frequent updates and features to SourceTree for Windows users. We plan to bring all the great features that are part of SourceTree for Mac to Windows as well. What can you expect in the near future:

• Mercurial support
• Git-flow support
• Custom actions
• JIRA integration
• and heaps more

Get SourceTree for Free!

If you’re new to Git, or just want a handy tool to make you even faster, download SourceTree – it’s free at our brand spankin’ new website.

Interested in the latest Stash release? Check out What’s New »

No two Git workflows are the same. Every development team is different and so are the workflows they are using. It is impossible to come up with one single “best practice” that will work for all development teams out there. In Stash 2.1 we simplified Git development workflow by providing important information that affect the changes in a pull request – JIRA issues and Bamboo builds. Today’s release of Stash 2.2 takes it to the next level with several capabilities – repository hooks, an API for hook integrations and merge checks during pull requests – to customize your Git development workflow to any requirements and ensure code quality.

Try Stash 2.2 Now

The new, more customizable Stash – now with Git hooks

For those new to hooks, here is a quick primer: every time Git performs an action, you have the option to take an action before or after Git does its bit. “Hooks” are Git’s built-in mechanism to allow a “hook into” operations like commits, pushes, etc. For example: a hook can act as a rule preventing commits that violate your project’s code style from being pushed to your repository, or it could trigger a build on your continuous integration server every time a feature branch is updated.

In Stash 2.2, we leveraged the native Git hooks to create a new hooks API that allows development teams to easily enable, manage and configure hooks per-repository. Hooks in Stash have a few key advantages beyond their native Git counterparts:

• Developers can write hooks using a simple hooks API. Stash handles persistence, packaging and per-repository configuration for your hooks, making it simple to extend Stash to suit your particular project’s needs.
• Admins no longer have to install hooks on the file-system, or give developers access. They can easily manage hooks running in their repositories and enable/configure the hooks via repository settings, all while keeping the server locked down.
• Development teams can mix-and-match out-of-the-box Stash hooks, with additional hooks from the Atlassian Marketplace, to customize and automate their git workflow.

Hook into your Git workflow

Git hooks let you customize your team’s workflow to any requirement they may have, and automate more pieces of your development workflow.

Start customizing with Git hooks

Stash’s new out-of-the-box pre-receive (reject commits that don’t match your policies) and post-receive (perform actions after commits are processed) repository hooks enable you to configure Stash to work the way you work – quickly and easily.

Avoid the “oh sh–” moment: at some point when learning Git, you have probably heard “when in doubt, don’t force-push”. Prevent force pushes to a repository (which is particularly handy if your team is new to Git), and avoid removing any history from your repository with the Prevent Force Push hook.

Keep development teams in the loop via HipChat: when it’s close to release time, gatekeepers may vet everything coming into a release branch. With the HipChat hook, whenever changes get pushed to a repository, teams get instantly notified in a HipChat room.

Don’t see the hook you need out-of-the-box? Stash makes it simple to install additional hooks available on Atlassian Marketplace. Over time, Atlassian and the Stash community will contribute more and more hooks to the Marketplace to adjust your workflow.

Several are already available today:

Iterate smarter: ensure that reviewers approve all updates to pull requests and prevent late-breaking bugs from creeping in during rework. With the Unapprove Reviewers hook if there is an update to the source branch in the pull request all reviewers will automatically be set to unapproved.

Keep branches protected: branches can be deleted accidentally when they are still active (read: not merged). The Protect Unmerged Branch hook rejects all pushes that delete branches with active pull requests.

Pull request settings – enforce your workflow

Stash pull requests aim to keep code quality high by ensuring code has gone through peer review before being merged into your master branch. In Stash 2.1, we simplified your Git development workflow by providing key information about JIRA issues and Bamboo builds in pull requests, giving you a quick idea of whether or not the changes are good to merge. In Stash 2.2, we set the bar even higher by enabling you to enforce certain quality requirements and ensure they are met before a pull request can be merged.

• Tailor your workflow: set checks to control when a pull request can be merged, per-repository.
• Guarantee code quality: whether you require a minimum number of reviewers approving a request or a green build, pull requests cannot be merged if the required checks have not been met.
• Increase development efficiency: developers spend less time investigating changes and more time coding.

Require a minimum number of builds

Stash integrates seamlessly with build automation tools like Bamboo and Jenkins, putting build details at your fingertips on the pull request’s overview. In Stash 2.2, we took this integration a step further. With pull request settings you can now stop pull requests from being merged unless all the related builds are successful.

From the perspective of a gatekeeper, QA or release manager this can save heaps of time when reviewing changes going into the master branch and trusting the changes that have already been merged.

Require a minimum number of approvers

On the Stash development team, we require at least two approvals before merging a pull request. Until today, this was just a cultural discipline – part of our development process. In Stash 2.2 you can make this discipline a requirement. Administrators (including project admins) have the option to block merging of a pull request until it has been approved by at least a select number of reviewers. It’s seamless, it’s automated and it’s easy to update as your team’s processes evolve.

The growing Stash ecosystem

Stash has been built from the ground up with extensibility in mind. With Stash 2.2 we are taking that extensibility to the next level and providing the world’s most customisable Git repository management solution. Stash provides a vast number of plugin points and a comprehensive REST API that allows developers to create custom functionality and integrations.

With this release we are adding more to Stash’s powerful API to improve the experience that native Git hooks provide, hooks API. This will provide a huge lift in the growing Stash ecosystem and give you one more tool in your development tool belt to extend Stash’s capabilities.

Add-on or build it

A growing number of developers are sharing their customizations as free or paid add-ons through the Atlassian Marketplace (35+ are available). Get detailed stats on your commit history, motivate your development team by rewarding them with useful badges for pushing code or contribute an add-on of your own to the Atlassian Codegeist competition (there is a $10,000 Stash prize).

Get hooked on Stash

New to Stash? Start a free trial today and get up and running in a matter of minutes.

Try Stash 2.2 Now

Already hooked on Stash? Your upgrade to 2.2 is waiting for you. Check out our full release notes to get started.

We’re finally organizing our second meetup in Sydney dedicated to people making the switch to Git or Mercurial. On this occasion we’re looking for a company willing to present their own implementation of Git or Mercurial and give a different perspective on their migration. If you’re interested, just send me an email at spittet@atlassian.com.

When

Tuesday, March 12th – 6pm

Where

Level 6, 341 George Street
Sydney

Registration

You can sign up from our meetup page.