Git が分散型であるという性質のため、プロジェクトの共同作業をどのように進めていくかを選択する際に、開発チームには多すぎるほどの選択肢が与えられることになります。開発中のプロジェクトを Git に移行しようとするチームには、分散したエンタープライズという環境下で、コードを使用して最善の仕事を行うために、十分なフレキシビリティーが求められます。ブランチやフォーク ベースでのワークフローを使って実施する、というケースも出てきました。これはエンタープライズ内部でどのように使えばよいか、という点で議論に火を付けたようです。
本日、Stash 2.4 を発表できることをうれしく思います。これは、Git 開発ワークフローを運用するためにエンタープライズチームが必要とする、選択肢とフレキシビリティーを提供するものです。このリリースには、ファイヤーウォールの内側で、お使いの Git リポジトリを適切に運用し、その上で共同作業を進めるのに重要ないくつかのフィーチャーが含まれています。フォークすること、つまりオープンソース開発分野で人気のある分散型開発ワークフローで、パーソナル リポジトリ単位やリポジトリ毎のパーミッションを得て、実行されるものです。選択できること、フレキシビリティー、コントロール、それが Stash 2.4 です。
フォークを用いて Git 開発コラボレーション
「フォーク」とは単に、サーバーサイドで、以前の履歴を含んだリポジトリのクローンを生成することを意味します。Stash におけるフォークでは、開発者に対し、書き込みアクセスができないリポジトリに、コードを返すワークフローを提供します。開発プロセスに管理的階層を追加するというものです。Stash では、リポジトリにある「Fork」ボタンをクリックすることで、Stash が追跡し、親リポジトリから独立して修正されたコピーを生成できます。さらにそこからコードを分離して思わぬ変更やエラーを避けることができます。自分が管理者アクセス権を持っている Stash 内の他プロジェクトへリポジトリをフォークしたり、個人フォークを生成して他の開発者にアクセスさせることができます。Stash を使えば、プルリクエストを用いてフォーク間の変更を簡単にマージすることができます。
なぜフォークするのか?
- 契約開発者にとって － 外部開発者のプロジェクトへの作業参加を可能にします。ただしコア・チームのみがリポジトリへの書き込みアクセス権を有します。契約開発者は、リポジトリをフォークし、プルリクエストを経由して変更を返すのみです。
- 大規模チームにとって － 何百もの開発者が同じリポジトリで作業しているので、リポジトリ内でのブランチや活動量の多さは、ただただ喧騒の素になるだけです。フォークを行うと、コア・リポジトリからプロジェクトへの新規追加を常にシンクロさせながら、各チームがそれぞれ独立して作業することができます。
- 試行として － フォークに基づく試行では、ShipIt に参加していても、プロジェクト妨害があっても、単なるフィーチャーの原型制作であっても、もし試行が失敗した場合、メイン・リポジトリがコミットで乱されることなく、開発者は不要な変更を廃棄することができます。
エンタープライズでフォークすることについての考察は “なぜフォークするのか?” をご覧ください。
プルリクエストを用いて変更に貢献
フォークの素晴らしさは、フォークされたリポジトリで行われる変更がメインのコード・ラインに影響を与えないということです。フォークがプライムタイムで使える状態になれば、元のリポジトリへのマージをリクエストすることができます。Stash とプルリクエストで、これらの変更をマージするプロセスが可能になります。これにより、他の開発者にも、メイン・コードベースに参加する前に、変更についてレビューしたり、協議したりする機会が与えられます。そこから、元のリポジトリ内でのプルリクエスト設定やブランチパーミッションに基づいて、変更をマージすることができます。
パーソナル リポジトリ
Stash 2.4 では、他プロジェクトに関係ないパーソナル リポジトリを生成する方法を追加しました。これにより、開発者は自由に、作業上の個人的こだわりを保存してこれに改良の手を加えたり、自分のプロジェクトを始めたり、メンバーでないプロジェクトへバグ修正を送ったり、組織内の小グループが管理維持している共通コンポーネントにフィーチャーを追加したりすることができます。パーソナル リポジトリをオープン（あるいはクローズ）状態にしておき、そして自分の準備ができたら、リポジトリ・パーミッションを使って他ユーザーやグループと共同作業するのです。
パーソナル リポジトリとパーソナル フォークの導入に伴ない、簡単にアクセスできて情報を要約する場所が必要になりました。そこでユーザー プロファイルも改訂したのです。
リポジトリ パーミッション
Stash パーミッションの目的は、コードを安全に保つこと、そして正当な開発者こそがアクセスできる、ということを信用してもらうことです。Stash 開発当初、主なパーミッションセットを 2 つ用意しました。1 つは、コントロール権を与えたり、ユーザーやグループに委託してプロジェクトにアクセスさせるするグローバル・パーミッション、もう 1 つは、プロジェクト毎に読み出し・書き込み用アクセスのコントロール権を与えるプロジェクト・パーミッションです。Stash 2.0 では、さらに深化したレベルのアクセス・コントロール権（すなわちブランチ・パーミッション）を追加し、あるリポジトリ内の特定のブランチに対し、誰がコミットできるのかを明確にし遵守させるようにしました。また Stash 2.4 では、Stash へのアクセス・コントロール権を、さらにきめ細かく付け加えました。これで、リポジトリ レベルでのパーミッションが一式揃ったわけです。
管理者は、プロジェクトを、オープンにもクローズにもしておけます。ユーザーは、プロジェクト全体には手が届かず、プロジェクト内での個々のリポジトリへのアクセスだけが許可されることになります。これにはあなたのワークフローに利益となるシナリオがいくつかあります。
- 外部開発者 － 外部開発者と作業するときに、自分のリポジトリへのアクセスを開けっぴろげにオープンにすることは、かなり神経に障るものです。特定のプロジェクトにおいて、すべてのリポジトリにアクセスできるのは自分のコアチームだけ、という方がいいでしょう。契約開発者にはこちらで選んだリポジトリのみが使用可能という状態です。
- アクセスをオープンにする － 特定のプロジェクトにおいては、書き込みアクセスを開発小チームに制限しているチームが多いようです。作業の協力関係を促進するために、組織内の他メンバーには閲覧アクセスをオープンにし、コアチーム以外の人もフォークしたり、協力したりできるようにしておくことが有効です。
- 管理権を委託する － あるリポジトリへの管理アクセス権を信頼できるチームのメンバーに与え、その特定リポジトリ管理を自由できるように任せて、貴重な時間を節約することができます。
Stash では、あなたやチームが分散したコードでどのように作業するか選択することができます。この柔軟性があってこそ、作業を迅速に処理することができるのです。
コミットする前にはいつもフォークしよう。Stash 2.4 を使って
Stash を使うのは初めてですか? 無料トライアルで今すぐフォークしましょう。ほんの数分で開始できます。
すでに Stash をお使いですか? 2.4 へのアップグレードは簡単です。リリースノート全文をご覧になり開始してください。
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2013 年 5 月 6 日 "Stash 2.4: Forking in the Enterprise"