Effective Bitbucket: 10 Tips to Better Utilisation of the Tool

One can simply use Bitbucket as a basic source repository, configured to behave like SVN. But with a few configurations and proper usage, it can be very powerful. Here are 10 things I've found for getting the most out of it.

1. Use the feature-branch branching model
   Although Bitbucket can be configured to work in master, creating branches should be the default. It allows you to separate out all the muck that happens through the development process from the clean deployable code in the master branch. Merge back into master when the code is ready, and only when it is ready.
   (The feature-branch model is good, the gitflow model is better.)
2. Prevent changes to master except by pull request
   Setting up a feature branch workflow doesn't guarantee people won't develop in master. Putting a rule restricting commits to master will. This can be achieved by going to "Settings -> Branch permissions" then adding a rule that master can only be changed by a pull request.
3. Create branches in JIRA
   Working in branches is good. Working in meaningfully named branches is better. If you are integrating Bitbucket with JIRA, then you can create branches from a ticket. From the JIRA issue, click "Create Branch", then set the right branch type and which branch to branch from.
4. Don't take ownership of branches
   The main point of source control is collaborative development. Creating branches is a good way to isolate changes from the main codebase (until they are ready), but that's no reason to isolate yourself.
5. Write meaningful comments in commit messages
   This is true for any source repository, but it's well worth repeating. Writing a good commit message may seem tedious at the time, but it's invaluable for understanding that code in the future. The code is the how, the commit message should be the what and the why.
6. Turn on mandatory code review approval
   In "Settings -> Pull requests", tick "Requires [1] approvers". Bitbucket has code review built into the web interface, so make sure they happen before the code is merged back into master. Having code reviews at this point dissolves the pre-commit / post-commit dilemma, as the gateway moves from entry into the repository to entry into the main codebase.
7. Turn on mandatory successful build
   All source repositories should be hooked up to a continuous integration tool. Bitbucket goes one better in that it can use the results of the build as a necessary step in the merge process. In "Settings -> Pull requests", tick "Requires a minimum of [1] successful builds. But it also requires some setup on the CI tool. For Jenkins, it required the Stash plugin (the Bitbucket plugin is for the cloud version). And to set the job up right, build branches with the prefix features and bugfix. If you're using Maven, set the goals as clean test as this will compile / run the unit tests, but not build the final artefact.
8. Treat the code reviews as a conversation
   Comments can be put against files or against lines. Multiple commits contribute to a pull request. The history of pull requests can be viewed at any time by changing the filter on the Pull Request screen. So treating the code reviews as a conversation between developers is a way of documenting specific changes in a way that most code review processes lack.
9. Don't hang onto old branches
   If you're finished with a branch, and the code has been successfully merged into master, then clean up the branch right then and there. Deleting the branch signals that there's no work left to be done on it. And even if a defect is found on that feature, just create a new branch in its place. This way, the repository does the job of keeping the branch up to date with all the other code changes.
10. Search is a fast way to find code
    Searching on Bitbucket is much faster than searching in an IDE, so using the Bitbucket interface can assist in being able to navigate through an unfamiliar codebase. If there are multiple projects / repositories on the same server, a global search can be performed. To search, just use the search box located on the top navbar. This, by default, will be a global search. To search within a particular repository, navigate to that repository before performing the search.