私たちの小さな会社（6人のバックエンド+ 4人のフロントエンド開発者）では、コードレビュー（以下CR）のためにGerritを使用しました。 Gerritは、たとえばAndroid開発に使用されます。 これは、CRプロセスを設定する際に多くの自由を与えるツールですが、放棄しました。 なんで？ インタラクティブなリベース、マージ、競合の解決、コミットの修正などを簡単に行えるタフなバックエンドの人に最適です。 フロントエンドチームの人々は、夜間、Gerritのワークフローの困難から泣きます。
みんなが幸せになるようにワークフローを整理しようとして、みんなに合った人気のあるソリューションを選びました。 つまり、すべての開発者にとって重大な欠陥がソリューションに含まれてはなりません。
Bitbucketに来ました。 カットの下で、なぜBitbucketで、なぜGitHubではないかについての質問に答えます。
1.無制限のプライベートリポジトリ
GitHubの価格プランは 、プライベートリポジトリの数に基づいています。 Bitbucketの料金プランは、チーム内の開発者の数に基づいています。 つまり GitHubは、少数のプロジェクトを持つ大規模なチームにより適しています。また、Bitbucketは、多数のプロジェクトを持つ中小規模のチームにより適しています。 私たちは2番目の選択肢であり、GitHubを使用する場合は100ドルではなく、1か月あたり10ドルを支払います。
2.横並びの差分
Gerrit side-by-side diffが前提条件となった後、Bitbucketには次の機能があります。
サイドバイサイドdiff（ issue ）モーダルウィンドウのコードにコメントできないなど、重大ではない欠点がいくつかあります。
3. masterブランチでのプッシュの禁止（ issue ）
当社の各プルリクエストは、コードレビュー（CR）に合格する必要があります。 したがって、私たちの場合、マスターブランチへの偶発的なプッシュに対するセーフティネットが非常に重要です。 つまり ワークフローは次のようになります。
- 開発者がブランチを作成します（feature / fooまたはbug / bar）
- コードを変更し、作成されたブランチにプッシュします
- 彼の意見では、ブランチがCRの準備ができている場合、プルリクエストを行います
- bitbucketのガイドラインで詳しく説明されているCRに進みます
- レビュー担当者は、自分の意見のコードがCRに合格した場合、承認ボタンを押します
- 少なくとも2人から承認を受け取った後、著者プルリクエスト-aはマージします
4.時代に遅れずについていく
先日、Bitbucketは新しいラバーインターフェイスを公開しました。 もちろん、欠陥はありますが、良い傾向は明らかです。
5.すてきなこと
- プルリクエストの承認済みボタン
- ハードリポジトリ/ファイルサイズの制限なし
- インターフェースのロシア語（使用していませんが、それでも）
userscriptが一時的に解決しなければならなかった2つの詳細：
- fancybox 。 残念ながら、はい、Bitbucketチームのメンバーは、このために最も不適切な場所であるSide-by-side diffでfancyboxを使用しています。 スクリプトは迷惑なフェードアウトアニメーションをオフにします
- 会社のコードフォーマットルールとの不整合を誤ってマスターに送信しないように、 スペース/タブを強調表示する