Git ワークフローには一つとして同じものはありません。すべての開発チームは同じではないので使用するワークフローも違います。全ての開発チームが使える単一の「ベスト・プラクティス」を生み出すことは不可能です。Stash 2.1 において私たちは Git を利用した開発を簡単にしました。JIRA 課題や Bamboo ビルドなど、プルリクエスト内の変更に影響する重要な情報を提供することによってです。
本日リリースする Stash 2.2 ではすべての要件に対応できるように Git 開発フローをカスタマイズしたり、コードの品質を保証できるようにして、これをさらに高いレベルに高めました。リポジトリフック、フック統合用 API およびプルリクエスト中のマージチェック、といったいくつかの機能によってです。
さらにカスタマイズしやすくなった新しい Stash ‐ Git フック が利用可能に
フックが初めての方に簡単な手引きを記します：Git が仕事をする前か後のいずれに動作をさせるかを、Git の動作ごとに選択できます。「フック」は Git に備わっている機能で、コミット、プッシュのような「フックする（引っ掛ける）」操作を可能にする目的です。たとえば、フックはプロジェクトのコードスタイルに違反するコミットがリポジトリにプッシュされることを防止するためのルールとして使われたり、あるいはフィーチャーブランチを更新するたびに継続的インテグレーション サーバー上でビルドを始動させたりします。
Stash 2.2 では開発チームが容易にリポジトリごとにフックを管理し設定できるように、ネイティブ Git フックを活用して新しいフック API を創りました。ネイティブ Git と比較して、Stash のフックには、幾つかの重要な利点があります。
- 開発者は簡単なフック API を使ってフックを書くことができます。Stash はフックの持続性、パッケージ化およびリポジトリ毎の設定に配慮しているため、プロジェクト独自のニーズに合うように Stash を拡張することが簡単です。
- 管理者はもはやファイルシステムにフックをインストールしたり、開発者にアクセスさせる必要はありません。リポジトリで作動中のフックを簡単に管理でき、サーバーをロックダウンしたままリポジトリ設定を操作してフックの有効化/設定ができます。
- 開発チームは標準機能として使える Stash フックと、Atlassian Marketplace にある追加フックをミックスしたりマッチさせることにより、チームの git ワークフローをカスタマイズや自動化ができます。
Git ワークフローにフック
チームのニーズがどのようなものであっても Git フックによってワークフローをカスタマイズし、開発ワークフローのより多くの部分を自動化できます。
Git フックを使ってカスタマイズを開始
Stash の標準機能である、受入前（ポリシーに合わないコミットを拒否）および受入後（コミットの受入後動作を実行）リポジトリフックによって、作業方法に合わせて迅速、簡単に Stash を設定できます。
「しまった、、」という体験を避ける：Git を学習中のある時点でおそらく「迷ったときには強制プッシュをするな」と聞かれたことがあるでしょう。リポジトリへの強制プッシュを防ぎ（これはチームが Git に不慣れなときには特に重要です）、「強制プッシュ防止フック」によってリポジトリからの履歴削除を回避しましょう。
HipChat により開発チームを常に巻き込む：リリース時期が近付くとゲートキーパーはリリースブランチに関係するあらゆるものを検査します。HipChat フックを使うことによって、リポジトリに変更のプッシュがあるとチームは HipChat ルームでいつでも直ちに通知を受けられます。
標準機能の中に必要なフックが見つかりませんか？ Stash では Atlassian Marketplace から入手可能な追加フックのインストールが簡単に行えます。今後、アトラシアンや Stash コミュニティは、あなたのワークフローに対応できるようにますます多くのフックを Marketplace に提供していくでしょう。
いくつかは現在すでに利用できます:
賢くイテレーション: レビューワーがすべてのプルリクエストの更新を許可することによって再作業中に後からバグが入り込むことを確実に防ぎます。「Unapprove Reviewers hook (未承認レビューワーフック)」によって、プルリクエストのソースブランチに更新があるときは、すべてのレビューワーが自動的に未承認として設定されます。
ブランチの保護を維持:ブランチはアクティブなときに誤って削除されることがありえます（非マージと読むこと）。「Protect Unmerged Branch hook (非マージブランチ保護フック)」はアクティブなプルリクエストを持つブランチを削除するすべてのプッシュを拒否します。
プルリクエストの設定 – ワークフローを強制
Stash のプルリクエストは、コードがマスターブランチにマージする以前に確実に同僚のレビューを受けることにより、コードの高い品質を維持することを目的としています。Stash 2.1 ではプルリクエストの時に JIRA 課題と Bamboo ビルドについての重要情報を提供することによって Git を利用した開発を簡単にし、変更がマージに適するか否かが速やかに分かるようにしました。Stash 2.2 ではプルリクエストがマージ可能となる前に、一定の品質条件を設定し、それを満たしているかを確認できるようにすることによって、基準をさらに高くしました。
- ワークフローのカスタマイズ:プルリクエストがマージできる時、リポジトリごとに、制御できるようチェックを設定する。
- コード品質の保証: リクエストの承認に最低数のレビューワー数を設定しようと、成功ビルドであろうと、必要なチェック項目が満たされないときはプルリクエストをマージできない。
- 開発効率の向上:.開発者が変更の調査に使う時間を削減し、コードを書くのに使う時間を増加させる。
必要な最小ビルド数を設定
Stash は Bamboo や Jenkins のようなビルド自動化ツールと継ぎ目なく統合されており、プルリクエストの検討に当たりビルドの詳細が手元で一覧可能となっています。Stash 2.2 ではさらに一歩統合が進みました。プルリクエスト設定により、すべての関連ビルドが成功していない限りプルリクエストをマージさせない、ということができます。
ゲートキーパー、QA またはリリースマネージャーの視点からいえば、これはマスターブランチに入る変更をレビューし、マージ済みの変更を信用できるようにするために、多くの時間の節約を可能にします。
必要な最小承認数を設定
Stash 開発チームにおいては、プルリクエストをマージするのにあたり、最低二つの承認を必要としています。現在までこれは開発プロセスの一部としての単なるルールでした。Stash 2.2 ではこれを必要条件とすることができます。管理者（プロジェクト管理者を含む）は選択した最低数のレビューワーの承認が得られるまではプルリクエストのマージを阻止することを選択できます。チームのプロセスが進化するにつれて更新は継ぎ目なしに、自動的に、容易に行われるようになります。
成長する Stash エコシステム
Stash は拡張を念頭に置いてゼロから開発されました。Stash 2.2 によって私たちは拡張性をさらに次のレベルへと発展させ、世界で最も柔軟にカスタマイズが可能な Git リポジトリ管理ソリューションを提供します。Stash は極めて多数のプラグインポイントと包括的な REST API を提供し、開発者による機能カスタマイズや統合を創出可能にします。
このリリースにより私たちは Stash の強力な API にさらにフック API を加え、ネイティブ Git フックが提供する性能を改善します。これにより、成長中の Stash エコシステムは大きく躍進し、また Stash の性能を向上させるもう一つのツールをお持ちの開発ツール群に追加することになります。
アドオンまたは開発
ますます多くの開発者が Atlassian Marketplace を通じて無料または有料のアドオンとしてカスタマイズのソリューションを共有しています (35 種以上が利用可能）。コミット履歴の詳細統計をご覧になり、コードのプッシュに対して有用な表彰を用意してチームに賞を与えることにより、またはアトラシアン コードガイスト大会へ独自開発したアドオンを提供して参加するよう促すことにより、開発チームを動機付けましょう（10,000 ドルの Stash 賞が提供されています）。
Stash にフックする
Stash をお使いではないですか？今すぐ無料のトライアルを始めましょう。数分で設定し開始できます。
もう Stash にフックしてますか？ Stash 2.2 があなたをお待ちしています。リリースノート全文をご覧になり開始しましょう。
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2013 年 3 月 5 日投稿 “Stash 2.2: Customize your workflow with Git hooks“