By Jon Mooring on February 7, 2013
Have you ever been in this scenario: you are in a rush and need to find a file that you know the name of, but can’t remember where that file lives? You search the file browser in Bitbucket directory after directory… and finally find that elusive file.
When you’re looking for something in your DVCS projects, you want find it fast. We set out to make file search better, simpler, faster.
Meet the new file search
We’ve made it incredibly easy to jump to the exact file that you want to find or to search more broadly. From any repository page, simply press F and the quick file search dialog will appear.
Bitbucket uses a variation of ”fuzzy” searching, meaning you can enter the query “aui src .js” and we’ll return all files with the extension .js in the /aui-sandbox/src/ directory. If you’ve ever used Sublime Text’s or TextMate’s Command+T file search, you’ll feel right at home.
There are a few additional tricks baked into this feature as well. Here’s a quick rundown of what else you can do with fuzzy file searching:
- Filter by directory path e.g. /media app.js to search for public/media/app.js
- Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java
- Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory
- Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml
We’ve also paid homage to the Vim diehards out there; you can navigate the list of files with Ctrl+J (next) and Ctrl+K (previous) and view a file with Ctrl+O.
Moar shortcuts!
Bitbucket features a host of other keyboard shortcuts to make repository and account management a breeze.
Just hit ? at any time to see a full listing of the shortcuts available in your current context.
Check out Bitbucket
Get your team going with a free Bitbucket account – unlimited private repositories for 5 users.
By Brodie Rao on February 4, 2013
When developing on a feature branch or a fork, your code can often get out of date. There are a number of reasons this might happen:
- You’re concentrating on a feature rather than syncing.
- You’re not yet ready to worry about integrating just yet.
- You’re returning to a stale branch or fork to pick up where you left off.
Have you ever wished there was a simple way to update your feature branches and forks with the most recent commits from mainline? Bitbucket now automates syncing your projects without ever needing to go to the command line.
Managing feature branches
We recently added the feature branches tab to the commits page, allowing you to see what branches are ahead of your main branch. From the feature branches tab, you can now keep these feature branches in sync with your main branch with one click.
Merging regularly helps avoid nasty merge conflicts and lets you focus on developing new features. If you decide you’re done with a feature branch (or just forgot to close a branch after merging in a pull request), you can also delete it directly from the feature branches page.
No fork left behind
When you’ve forked project, it can be tedious to keep up to date with the upstream repository. Bitbucket now informs you when your fork is behind, and you get the option to instantly merge in those upstream changes with a single click.
Merging in the compare view
For cases where you need to quickly merge in a branch without making a pull request, you can now do the merge directly from the compare view.
On the Bitbucket team, when we make a pull request with hot fixes, it goes on our production branch. When we accept the pull request, we go to the compare view and merge production into our staging branch, making sure the fix makes it out both externally and internally.
Being able to sync your branches and merge through the compare view lets you manage your branches in Bitbucket from start to finish.
Sync and merge with Bitbucket
Sign up free for 5 users today using your Google, Facebook or GitHub account.
By Jesper Noehr on January 28, 2013
Chances are you have an account on Facebook or Google and you don’t want to have to enter all your information again when signing up for a Bitbucket account. Who wants to remember another user name and password?
We just made it easier to sign-up (or connect your existing Bitbucket accounts) to an account from one of your favorite providers – Twitter, Facebook, Google…
New to Bitbucket?
You can now sign-up in a matter of seconds using your username/password via Google, Facebook, Twitter and GitHub.
It’s simple: pick your favorite provider, confirm Bitbucket can fetch information your data and Bitbucket will do it’s best to fill out as much information as possible to streamline the sign-up process. If you already have a Bitbucket account you can associate it with one of your provider accounts.
Here, I used Twitter:
The username ‘jespern’ is already taken, so we’ve suggested ‘jespern_’, which is available. If the service had provided us with an email address, that’d be pre-filled, too.
Already a Bitbucket user?
For those of you with a Bitbucket account we have you covered. Connect that account to any or all of the external services to make your sign-up process easier (and saves you from remembering another username and password).
For example, let’s say you have a Bitbucket account and want to use Facebook to log in with from now on. Just head over to the “Connected accounts” page under your account settings. Click the “Connect” button next to Facebook, and you’re off! When you return to Bitbucket in the future, you can now just click the Facebook button to log back in. You can of course do the same with the other options!
Sign-up using Google, GitHub, Twitter, or Faceb0ok
Sign-up free for 5 users today using one of your favorite providers. We hope you find this as useful as we do!
By mfrauenholtz on January 9, 2013
Are you a Markdown wizard? Perhaps you have spent the last few years learning the ins and outs of reStructuredText.
Let’s be honest: when you know a markup language well, that’s what you want to use to create rich content.
Now, wiki pages on Bitbucket render Markdown, reStructuredText, Textile—and they’re still fluent in Creole. New wiki pages default to Markdown, but it’s easy to switch:
Even more improvements…
We’ve freshened up the look of our markup toolbar and added buttons to insert links and images into your pages. Now you have everything you need to write full-featured wiki pages. Just in case you can’t remember the syntax, the toolbar is available everywhere on the site where you can enter markup. Even better, you can use the improved toolbar to preview wiki markup in any language with just one click.
We’ve also made it easier to manage your wiki directly from Bitbucket. You can now rename or delete pages right from the site. You can manage your files without having to clone the wiki repository — but you still have the option to clone, if you prefer.
Git or Mercurial repositories continue to back our wikis. You can clone your wiki, compose with your favorite editor, and push your changed pages back up to Bitbucket. Just make sure each page’s file uses the appropriate extension for your markup and Bitbucket will handle the rendering.
By Nicolas Venegas on December 21, 2012
Did you know that you can use @mentions when commenting on commits, pull requests, and issues to get the attention of your teammates?
When a user is mentioned they will receive an email letting them know their attention is needed on Bitbucket. We often use mentions in pull requests to let other devs know we would like feedback on a particular change.
We’ve been noticing a problem though: as the number of developers at Atlassian has grown (300+), we’ve found it difficult to keep track of who has which username when leaving a comment.
You autocomplete me…
Simply type @ to start finding any user on Bitbucket, especially members of your team, without having to know their Bitbucket username.
Bitbucket will remember the users you have most recently mentioned and highlight those users who are in any team you are a member of. You can also quickly see when you or your teammates have been mentioned and click-through to their user profile.
Cursores.js: putting the ‘complete’ in ‘autocomplete’
As part of building autocomplete for mentions, we’ve open-sourced a new library, Cursores.js, which allows you to get and replace the token under the cursor in a textarea or input.
By Justen Stepka, Product Manager on December 20, 2012
Today we’re rolling out a new profile page that is more in-line with the larger site redesign we did in October. At a glance you can now see a more detailed list of repositories for a user, with the most recently active repositories displayed at the top. You can also see the teams a developer is a member of.
We’ve split out the content into four tabs to provide additional details and make it easier to find what you’re looking for. On the new “Followers” and “Following” tabs you can see a list of users in a network, and easily discover and follow interesting users.
Also new is the “Activity” tab that shows all the commits, comments and changes a user has recently made. Of course if you’d like to set your user profile pic, you’ll want to setup an account on Gravatar and upload a high-res profile image to be used throughout Bitbucket.
Team Profiles
When looking at a team account, you can now see a list of members for that particular team.
If you’re an admin, we’ve added shortcuts to directly manage members of a team. If you’re browsing around on Bitbucket and find a particular team interesting, you can choose to follow a team and your dashboard will be updated with key events from that team.
By Justen Stepka, Product Manager on December 10, 2012
The Bitbucket team uses Git’s branch and merge features religiously with pull requests for code review. At any given time we may have a dozen open pull requests for code that is looking to be merged into our staging branch, which later gets promoted to our production branch and deployed to bitbucket.org.
With so much in code in flight, keeping track of which branches are open, active, or gone stale can be a hassle. This got us thinking during our recent Innovation Week, “What if there was a way to review open branches that need to be pulled?”
Introducing a new way to see branches
With the new “Feature branches” commit listing, you can now see branched commits that are ahead of your main branch. This new view allows you to:
- get a sense of team activity
- compare and create pull requests for open branches
- find stale branches that need to be reviewed or closed
- view an open pull request for a branch
Branching is easy with Git
Creating branches, working on them, and merging your changes is effortless. To get started, simply clone your repository and create a feature branch:
git clone git@bitbucket.org:username/reponame.git
git checkout -b my_new_branch
Make some changes and when you are done, push your changes:
git commit
git push origin my_new_branch
Your branch will now show up on the “Feature Branches” view for everyone to see. Next you’ll want to share your branch with your team by creating a pull request to conduct a code review.
Closing branches with pull requests
The simplest way to close a branch with pull requests is to use the close branch option when creating a pull request.
When selecting this option, Bitbucket will automatically close the source branch for you, tidying up your team’s repository and “Feature branches” view.
By Dylan Etkin on November 27, 2012
On the heels of our big UI release we decided it was time to let the Bitbucketers sow their wild oats – we call it Innovation Week.
What’s Innovation Week?
We set aside one week for developers to work on whatever they desire – feature enhancements, new features, bug fixes, internal dev-speed, performance improvements, whatever they are interested in. Developers can fly solo or form groups to tackle larger projects. The end goal is to have a shippable feature or improvement by the end of the week.
The results of Innovation Week were awesome with a host of them available on Bitbucket today.
What did we ship?
Real-time pull request status
The Bitbucket team uses pull requests a lot. Over time we have found that several of us may be reviewing a specific pull request at any given moment. This spurned an Innovation Week thought, “It would be cool if we could see who else is looking at the pull request I’m reviewing.” Cue the music, enter real-time status updates.
Now if another developer is working on the same pull request, you are notified in real-time, in browser of any changes that occur. Get notified if a user adds a new comment or if a pull request is approved or updated.
Giving the green light
Bitbucket has a light-weight approval process that allows participants to Approve a commit or pull request – this signifies that a user has reviewed a change and that it LGTM.
Later, when browsing the list of commits or pull requests, Bitbucket displays the total number approvals for a particular change as a gray circle.
A gray badge shows how many reviewers have approved a particular change – now, for those commits or pull requests that you personally have approved, the badge is now green giving you a quick summary of changes that are yet to be reviewed by you.
Identify who you are interacting with
For comments on a commit or a pull request, we’ve added AUTHOR and REPO OWNER lozenges to call out comments made by the pull request or commit author, or repository owner.
Efficient, relevant search and filtering by programming language
We set out to give the search features of Bitbucket some love – the UI had a makeover and search wanted to get in on the fun.
At the core of our search changes we implemented Postgres’s full text searching capabilities. Since implementing the full text search, Bitbucket search queries on average now take less than 50ms and return results based on text relevance across multiple fields increasing relevant results you see.
In addition, we added the ability to filter your search by repository language as well.
The best is yet to come
One more feature came out of innovation week that really knocked our socks off – a collaboration between a front-ender, back-ender and a designer. It really pushed the innovation envelope and it will be shipping to you soon, watch this blog for details.
By Jonathan Nolen on November 8, 2012
Join Bitbucket today — Bitbucket is looking for an inspirational engineering leader to help us build Bitbucket for the future. We’re growing the service and the team, and we’re tackling some of the biggest challenges around. You’ll help scale our service for millions of developers around the world.
Improve software development for everyone — Bitbucket is bringing the power of DVCS to developers everywhere, to help them share code and create better software together. At Bitbucket you and your team will imagine, design, build, and release features that the next generation of software developers will use to change the world.
Make an impact, fast — At Bitbucket, you’ll focus on shipping code to our users every day, building resilient systems that withstand chaos, and learn instantly from how live users behave.
Be the change you seek — With Bitbucket’s ShipIt days, 20% time, and innovation weeks you can showcase your genius. We don’t just want your opinions, we want to see your ideas in action. We hire great people and trust them to be great.
Who You Are
- A hands-on technical leader for a small team — with first-hand experience of shipping software projects.
- Able to slice and dice problems so they can be worked on by several people.
- Enthusiastic about mentoring other developers.
- Relaxed yet enthusiastic; calm but urgent.
- A creative and innovative problem-solver.
- Able to work independently and as part of a team.
- Excited about building for the modern web.
- Familiar with the best of agile software development.
- Able to learn new languages, frameworks and tools.
- Able to legally work in the US today.
What you know
- How to build web-apps with Python and Django.
- How to design a scalable and efficient platform for transferring and storing massive amounts of data.
- How to run a large-scale, popular, reliable and performant web service.
What You’ll Do
- Ship great code — Lead a team of crack Bitbucket developers to create features and build the infrastructure that will make Bitbucket the tool of choice for the next generation of software devs.
- Plan for the future — Stay ahead of Bitbucket’s rapid growth by building a reliable but nimble platform.
- Grow your team —Provide technical leadership and mentorship through pairing, code reviews and design.
- Stay on target — Make iteration commitments and ensure your team meets them. Help the team schedule work, remove any impediments, and facilitate timely decision making.
- Find the path — Explore new work to better understand the size and shape of features. Guide the team to make accurate estimates and good trade-offs.
- Keep channels open — Communicate with your lead and your peers to keep everyone on the same page.
- Innovate — Champion the effective use of 20% time, ShipIt Days and Innovation weeks within your team. Lead by example.
- Use the power of Atlassian — Work with other teams across the company to use their expertise. Keep everyone informed, and ensure the points of coordination are handled smoothly.
- Know your team — Use techniques like regular one-on-one meetings to make sure that you’re getting the best from your people.
You’ll love it here
Bitbucket is a part of Atlassian. We help innovators everywhere dream, plan, build, and launch great software. More than 23,000 companies of all sizes—including Blizzard, Pixar, Twitter, Netflix, NASA and Facebook—use our issue tracking, collaboration, and software development products to work faster and smarter, together.
With offices in Sydney, San Francisco and Amsterdam, we are growing fast, and we are building a different kind of software company: one that listens to customers, encourages innovation and solves customer problems with brilliant simplicity. We’re out to transform the way developers build great software. We live our values. Find out more about Life at Atlassian.
Sounds great!
Show us your résumé, CV, blog, Bitbucket or GitHub profile, open-source contributions, or things you’ve built. We want to see your amazing work!
By Brian Nguyen on November 7, 2012
On October 9, we released a site wide redesign of Bitbucket. The release was the culmination of 4 months of effort, in which we simultaneously ran two versions of Bitbucket side-by-side for a select group of beta users as we converted each page to the new look and feel now found on Bitbucket. At the end of 4 months, we were able to roll an entirely new version of the site by literally turning on a simple flag for all users. No deploy process; no build scripts; no hassles.
Laying the groundwork
Before we started implementing, we laid out some constraints on what we wanted to change:
- We’re not going dark: Rather than have the whole team stop everything to work solely on this project, we wanted to still be able to work on the existing design and make changes and improvements.
- Reskin, not reconstruct: We wanted to retain the functionality and existing feature set of Bitbucket as much as possible. So, for the most part, we only rebuilt the HTML/CSS for each existing page.
- Fail gracefully: Since we wanted to do some alpha testing of the site as early as possible, we needed to present the new view to some users even though we weren’t necessarily finished converting the website. So, if a user viewed a page that hadn’t been redesigned yet, the site would fallback to the old view.
- Clean up after yourselves: As is the case with many projects, when you rewrite something, the existing code becomes intertwined with your new code. By the end, you just have a mess of duplicated files that you’re not quite sure you can delete. We wanted to make sure that we implemented a proper system for removing the old code after we released.
Moving all the code
To start our redesign, we moved all the existing HTML templates into a directory called old. We didn’t just blindly move the entire templates directory into a different folder though. Instead, the top-level directory and each first-level subdirectory had its contents moved into the ‘old’ subdirectory. For example, templates/base.html moved to templates/old/base.html and templates/account/email.html moved to templates/account/old/email.html.
Why make it so complicated? One of the main reasons we did it this way was because a majority of the team was still working on the existing website. By only moving subdirectories, our developers were more easily able to see which templates had been reworked and might need to have a change incorporated.
Along with moving the templates, we also built a small Django app for handling the two sites.
Using django-waffle, we wrote a wrapper for Django’s render_to_response function. In pseudocode, the wrapper would:
- Check if the requesting user had the ‘niptuck’ flag enabled.
- If the flag was enabled, it would then search for the template
- If found, we would render the new template.
- If not, we would reconstruct the template URL to search for the old template and render the old view.
With the render wrapper in place, we were able to convert each template without affecting the live site. We were also able to fail gracefully as we turned on the flag for ourselves.
This process enabled us to convert views without conflicting with other streams of work.
What about the CSS and JavaScript?
We moved the CSS and JavaScript in the same fashion as our HTML templates. Since we were rewriting the CSS as part of the redesign, there wasn’t much to do apart from moving the CSS and updating the script tags.
The JavaScript was a different matter though. Our JavaScript had accumulated over the years and had grown to the point where it was much like our python backend — too big to change. To resolve this, we created a ‘shared’ directory, in addition to moving our JavaScript files to an ‘old’ directory. The ‘shared’ directory would include all our JavaScript files that were able to run on both the existing and the new site. The theory was that we would try and keep the ‘shared’ directory as large as possible and only create new files if they were absolutely necessary.
In practice however, it turned out that this was not a great solution. In almost all cases, trying to maintain two different views with the same file was just too unwieldy. If done again, I would suggest copying the JavaScript to a different location, even if only minor changes are made.
Caveats and exceptions
What’s a good system without a few pitfalls and exceptions? We encountered a few minor issues when we implemented this redesign, mostly related to views and templates provided by third party apps.
Third party views
In Bitbucket, we use Django’s built-in user authentication, as well as the Social Registration app. Both of these apps have their own views that are given the location of the template in their parameters. Because of this behavior, we are not able to replace the call to the render method like we do with our custom views.
To get around this, we wrote a view wrapper that would wrap the execution of the view with our own and manipulate the provided template name.
Default templates
These third party apps also present additional issues since they provide default templates. Therefore, our check for the template’s existence always resolves to ‘True’. This problem only occurred if the template had not yet been converted AND if the user has the flag turned on. Since it only affected our alpha testers, we decided that this issue was a worthwhile compromise.
Feedback and iterations
You never get things right the first time, so we also had a solid process in place for feedback and redesign. We started releasing the new look to the rest of Atlassian’s staff in August, months before the official release in October. This meant that we received large amounts of feedback from users who interacted with Bitbucket on a daily basis. We also ran Friday afternoon demos to gather feedback from the team about new changes made during the week.
With all this data, we could identify which views needed work and iterate on them again. Most of our pages went through multiple incarnations and in some extreme cases were removed entirely. All this occurred without ever affecting the old site.
Deploying the new look
By using this system, we not only were able to have both designs run concurrently, but it also made the deployment process seamless. To deploy the new look, we simply needed to turn on the waffle flag to activate the new view for all users. There was no need for a deployment script, which in many cases could be flaky.
After the deployment, we then monitored our Sentry platform in order to find any errors. We also watched our support, issues, and social media channels to catch any UX issues that we may have missed.
The code
The templating code is now available for open-source use at bnguyen/niptuck-templating. You should be able to deploy it directly into your Django app.
