Why did we choose Bitbucket for code review, not GitHub?

In our small company (6 backend + 4 frontend developers) we used Gerrit for code review (hereinafter CR). Gerrit is used, for example, to develop Android . This is a tool that gives a lot of freedom in setting up the CR process, but we have abandoned it. Why? It’s perfect for the harsh backend guys that easily make interactive rebase, merge, resolve conflict, amend commit, etc. People from the frontend team cry at night in a pillow from the work process in Gerrit.

In an attempt to organize our work process so that everyone was happy, we chose one of the popular solutions that would suit everyone. In other words, the solution should not contain critical flaws for all developers.
')
We came to Bitbucket. Under the cut answers to the questions why Bitbucket and why not GitHub.

1. Unlimited private repos

GitHub tariff plans are based on the number of private repositories. Bitbucket tariff plans - on the number of developers in the team. Those. GitHub is more suitable for large teams with a small number of projects, and Bitbucket for small and medium-sized teams with a large number of projects. We are just the second option and pay $ 10 per month instead of $ 100 when using GitHub.

2. Side-by-side diff

After the Gerrit side-by-side diff is a prerequisite, Bitbucket has it:

There are several non-critical flaws, such as the impossibility of commenting code in the modal window side-by-side diff ( issue ).

3. Ban push-in master branch ( issue )

Every pull request in our company must pass a code review (CR). Therefore, in our case, the safety net from a random push to the master branch is quite important. Those. The workflow looks like this:

1. the developer creates a branch (feature / foo or bug / bar)
2. makes changes to the code and push to the created branch
3. makes a pull request if in his opinion the branch is ready for CR
4. CR happens, which is well described in the bitbucket guideline
5. reviewer presses the Approve button if the code in his opinion has passed CR
6. author pull request-a does merge after getting Approve from at least two people

4. Keeping up with the times

The other day Bitbucket rolled out a new rubber interface . Of course, there are shortcomings, but a good trend is obvious.

5. Nice little things

• Approved button for pull request
• no hard limit on repository / file size
• Russian interface language (we do not use it, but still)

Two details that userscript had to temporarily solve:

1. fancybox . Unfortunately, yes, the guys from the Bitbucket team use the fancybox in the most inappropriate place for this - Side-by-side diff. Script turns off annoying fade-out animation
2. highlighting of spaces / tabs , in order not to accidentally send mismatches to the master with the code format rules adopted by the company