Bitbucketを「ただのGit置き場」で終わらせるな。現場を加速させるGitflow極限運用術
多くの現場がBitbucketを採用している。しかし、そのポテンシャルを使いこなせているチームはどれだけいるだろうか。ただコードをプッシュし、Pull Request（PR）を眺めるだけなら、それはBitbucketの機能の1%も使っていないに等しい。
今日は、Bitbucketというエコシステムを最大限に活用し、開発速度を劇的に高める「プロの運用戦略」を伝授する。
—
1. Gitflowの呪縛を解け：現場のための「適応型ブランチ戦略」
教科書通りのGitflowは、現代のCI/CD環境ではしばしばオーバーヘッドになる。特に`develop`と`master`の同期に疲弊しているチームは多い。
プロの最適化ルール:
- 短命ブランチの徹底: フィーチャーブランチの寿命は最大3日。それ以上かかる機能は、フラグ管理（Feature Flags）で隠してメインにマージする。
- マージコミットを禁止せよ: Bitbucketの「Merge Strategy」設定で`Fast-forward`または`Squash`を強制する。これにより、履歴が一直線になり、`git bisect`でのデバッグが劇的に楽になる。
- `main`へのデプロイ直結: `master`ではなく`main`を標準とし、保護ルール（Branch Permissions）で「直接プッシュ禁止」「最低1人の承認」「ビルド成功が必須」を徹底する。
—
2. Bitbucketの真価を引き出す「必須神プラグイン」
Bitbucketは単体でも強力だが、Marketplaceのプラグインで「開発体験（DX）」を一段上のレベルへ引き上げられる。
- [Awesome Graphs for Bitbucket](https://marketplace.atlassian.com/apps/1212876/awesome-graphs-for-bitbucket): チームの生産性可視化に必須。誰がボトルネックになっているか、どのPRが滞留しているかを定量的に把握できる。
- [Code Insights](https://confluence.atlassian.com/bitbucket/code-insights-994332155.html): これを導入していないチームはモグリだ。CIのテスト結果やLinterの警告をPR上に直接オーバーレイ表示させる。レビューの際、コンテキストスイッチなしで修正指示が出せる。
—
3. 指先一つで加速する：キーボードショートカット
マウスに手を伸ばすのは「負け」だ。Bitbucketはキーボードだけで完結する。
- `g` + `p`: Pull Request一覧へ即座にジャンプ。
- `g` + `c`: Commits一覧へ。
- `a`: PRの承認（Approve）。
- `e`: PRの編集。
- `.` (ドット): ファイルの検索（これが最強。リポジトリ全体を爆速でgrepできる）。
—
4. CI/CD設定（bitbucket-pipelines.yml）のベストプラクティス
多くのチームが「重い」パイプラインに苦しんでいる。鍵は「キャッシュ」と「並列実行」だ。
bitbucket-pipelines.yml
image: node:18-alpine
definitions:
caches:
# node_modulesを再利用してビルド時間を50%短縮
node: ~/.npm
steps:
- step: &test-unit
name: Unit Tests
caches: [node]
script:
- npm ci
- npm run test:unit
- step: &lint-check
name: Linting
script:
- npm run lint
pipelines:
pull-requests:
”: # すべてのブランチのPRで実行
- parallel: # テストとLintを同時に走らせる
- step: test-unit
- step: lint-check
極限のハック:
- キャッシュ戦略: `~/.npm` や `~/.cache/pip` を適切にキャッシュさせるだけで、パイプラインの待ち時間は劇的に変わる。
- パイプラインの分割: `bitbucket-pipelines.yml` が長すぎる場合、`include`機能を使って設定をモジュール化せよ。
—
5. チーム開発の規律：PRの「品質」を自動化する
PRのテンプレート（`pull-request-template.md`）はただの飾りではない。「思考のプロセス」を強制するフレームワークだ。
概要
- 何をしたか（一言で）
変更内容
- [ ] UI変更あり
- [ ] DBマイグレーションあり
確認事項
- どの環境でテストしたか？
- 懸念点はあるか？
これをプロジェクトルートの `.bitbucket/` フォルダに置くことで、全員が同じ解像度でレビューに臨めるようになる。
—
最後に：テックリードからの提言
ツールは「入れたからOK」ではない。「チームがそのツールをどう使いこなすか」という文化の構築こそが、DevOpsの神髄だ。
まずは明日、チームメンバーと「キーボードショートカットの共有会」を開き、CIのパイプラインを1分短縮することから始めてほしい。その小さな積み重ねが、半年後に圧倒的な開発速度の差として現れるはずだ。
Bitbucketは強力な武器だ。あとは、それを握る君たちの腕次第だ。さあ、コードを書こう。そして、デプロイを遊びにしよう。