Git: サーバー サイド フックによる自動マージ (これで決まり!)

Nicola Paolucci
Nicola Paolucci
リストに戻る

エンタープライズ DVCS ワークフローは定着しつつあり、パターンが統合されてきています。Git を使うと各チームは非常に柔軟に作業できるため、1 つの企業内でもチームによって異なった方法でコードの共有やコラボレーションを行っている場合があります。

この記事の内容は、確固たる証拠に基づいています。なぜなら、これはアトラシアンで実際に起こっていることだからです。Bitbucket Server チームは Confluence チームと働き方が違います。Confluence チームは Jira チームと働き方が違います。これらのチームはすべて同じようなアジャイル プロセスを共有していますが、分岐、継続的インテグレーション、チーム編成に対するアプローチが異なっています。

このような違いにもかかわらず、共通のパターンが浮かび上がってきます。業界で繰り返し発生しているパラダイムは、main ブランチを持つ集中リポジトリや、いくつかの安定した開発ラインを使用し、新機能とバグ修正を個別に開発できるフィーチャー ブランチ ワークフローに従うことです。これにより、迅速な統合が可能になり、チームは DVCS に付随する効率の向上を活用できます。

完全なブランチ モデル

これを読んで少し考えてみると、「上記の一元管理型リポジトリのワークフローに従っているのに、なぜまだフォークが必要なのか?」と疑問に思うかもしれません。

フォークが企業内でも有効で必須となっている理由がいくつかあります。その理由をお話しする前に、まず少しさかのぼって、フォークの背景と定義について話をします。

目次

  1. フォークとは
  2. フォークがオープンソースのワークフローに採用される栄誉を獲得
  3. 企業でフォークは必要?
  4. 中核のコンポーネントを保護し、イノベーションと採用を促進
  5. 複数の部門にまたがるコラボレーションを組織
  6. ノイズの削減
  7. 請負業者とのやり取りの合理化
  8. ファイアウォールの内側で行われる開発者同士の相互交流
  9. 結論

フォークとは

最近の DVCS 用語では、フォークはリポジトリのリモートなサーバーサイド コピーであり、オリジナルとは区別されます。クローンはフォークではなく、リモート リポジトリのローカル コピーです。これは、ソフトウェア開発における一般的なフォークの定義とは少し異なりますが、この記事ではこの意味で言及しています。

フォークがオープンソースのワークフローに採用される栄誉を獲得

世の中の動きにあまり詳しくない方に、疑いようもない事実をお伝えします。フォークはオープン ソースの世界で広く採用されるようになっています。フォークのおかげで参入の障壁とコード コラボレーション摩擦が大幅に減り、誰でも容易にオープン プロジェクトに参加できるようになっています。

オープン プロジェクトは誰でもフォークでき、フォークしたせいで元の作成者に不利益や負担が発生しません。運用は透明です。元の作成者はプル リクエストという形でフィードバックや改善を受ける可能性がありますが、それだけです。

企業でフォークは必要?

完全に分散された分散型アプローチは、つながりが緩いオープン ソース チームには効果的ですが、全員同じオフィスで中央リポジトリを使って作業しているエンタープライズ チームにとってはどうでしょうか? その環境ではフォークは役に立つでしょうか?

フォークは、企業のファイアウォールの内側でも驚くほど便利です。

要約すると、組織内でフォークを使えば信頼性を維持し、コードベースの成熟度を追跡し、チーム間のコラボレーションを促進することができます。

以下に、具体例を挙げます。

  • 中核のコンポーネントを保護し、イノベーションと採用を促進
  • 複数の部門にまたがるコラボレーションを組織
  • ノイズの削減
  • 請負業者とのやり取りの合理化
  • ファイアウォールの内側で行われる開発者同士の相互交流

それぞれ詳しく見てみよう。

中核のコンポーネントを保護し、イノベーションと採用を促進

多くの企業には、社内で再利用される中核的なコンポーネントが存在します。多くの場合、こうしたコンポーネントには、変更を加える人物に関する厳格なポリシーや安定性の保証、精細なレビュー プロセスが適用されます。

フォークを使用することにより、認可を受けたコードを厳重に保護し、同時に採用とイノベーションを促進することができます。

認可を受けていないチームや、プロジェクトの内容に関心のある単独の開発者が、監視を必要とせず、コア チームの作業を妨げることなく、プロジェクトをフォークして貢献を開始できます。コラボレーションは、プル リクエストやフィーチャー ブランチを使って通常どおり行われます。

メインリポジトリとは別の場所で実験を行うことにより、コントリビューションの完成度が高まっていく過程を効果的に管理し、追跡できます。動作が異常な不安定なハックプログラムはフォーク内に封じ込められたままとなり、信頼できる部品はレビュー後に中核のコアコンポーネントにマージされます。フォークにはこれができて、通常のクローンでできないのはなぜでしょうか。それはフォークはトラックキング ビットが使用できるからです。誰でもローカルにクローンを作成し、独自の実験に取り組めますが、このコードをサーバーサイドのフォークにプッシュすると、そのコードは追跡可能となります。

アトラシアンには、Atlassian User Interface など、さまざまなグループで共有されているコア ライブラリがあります。フォークは、それらを維持するコア チームの負担を軽減します。誤ったフィーチャー ブランチや乱雑なツリーがメイン リポジトリに表示されなくなりました。

複数の部門にまたがるコラボレーションを組織

特定のソフトウェア コンポーネントを管理する ”中核的な” チームがなく、複数の部門が同じインフラストラクチャを独自に修正したバージョンを維持している場合にも、代わりとなる似たようなシナリオがよく見られます。フォークを使えば、チームは独自のバリエーションを管理し、保証できます。プル リクエストGit の素晴らしい統合機能のおかげで、部門間のコラボレーションはやはり簡単で透明です。

ノイズの削減

チームが非常に大規模になると、フィーチャー ブランチやバグ修正ブランチのノイズが実質的に大きくなりすぎて、UI を正常に表示できなくなります。プロジェクト履歴は非常に混乱した状態になり、何が進行しているのか、どこに何がマージされているのか理解できなくなります。この状況では、ツールの効果がなくなっていきます。

この場合も、フォークを使うと、サブチームはオープンにコラボレーションできますが、統合が行われる中央リポジトリはできるだけクリーンに保たれます。

請負業者とのやり取りの合理化

フォークが役立つもう 1 つの分野は、サード パーティ、請負業者、フリーランスとのやり取りです。請負業者がリポジトリにアクセスする唯一のアクセス ポイントとしてフォークを提供することで、多くの利点が得られます。

  • メインリポジトリをクリーンで制限された状態に保つ。
  • 計画した時間にレビューした後で、サード-パーティの作業を統合する。
  • 共通の Git コラボレーション プロセスを維持する。

ファイアウォールの内側で行われる開発者同士の相互交流

パズルの最後の、そして非常に重要なピースを省くわけにはいきません。

開発者の個人的なフォークです! コア インフラストラクチャの一部を自主的に改変、改善、強化している開発者は、まだ完成していない作業を他の人と共有することを望まないかもしれません。このような開発者に、ミッション クリティカルな専用コードの公開を求めはしないでしょう。

他のケースでは、問題に対して少し異なるアプローチを取っている開発者は、特定の設計上の決定がチームに利益をもたらすことを証明できるまで、貢献を公開せずにおきたいと思うかもしれません。このようなシナリオでは、個人的なフォークが威力を発揮します。

個人的なフォークは、DVCS がオープン ソース コミュニティで大成功した原因となった、分散した、調整されていないインタラクションも可能にします。

結論

フォークは、すべてのコード コラボレーションの問題に対する答えにはなりませんが、いくつかの懸念に対する効果的な解決策を提供します。この記事では、企業内のフォークがコードベースの信頼性や成熟度を維持し、チーム間のコラボレーションを促進するのに役立つという説明を裏付けるアイデアをいくつか紹介しました。

最後に、Bitbucket Server の新しいリリースには、他の多くの機能に加えて、フォークに対するファーストクラスのサポートが含まれています。

DVCS トレンド スポッティングや Git コンテンツの詳細については、いつものように私 @durdn か素晴らしいチーム @AtlDevtools に ping してください。

(謝辞: ブランチ モデルの画像は、もともと nvie の git-flow キーノート ソースからフォークされたものです)

Git を学習する準備はできていますか?

この対話式チュートリアルを利用しましょう。

今すぐ始める