What's New In Stash 2.4
エンタープライズでフォークする
Git が分散型であるという性質のため、プロジェクトの共同作業をどのように進めていくかを選択する際に、開発チームには多すぎるほどの選択肢が与えられることになります。開発中のプロジェクトを Git に移行しようとするチームには、分散したエンタープライズという環境下で、コードを使用して最善の仕事を行うために、十分なフレキシビリティーが求められます。ブランチやフォーク ベースでのワークフローを使って実施する、というケースも出てきました。これはエンタープライズ内部でどのように使えばよいか、という点で議論に火を付けたようです。
Stash 2.4 のリリースには、ファイヤーウォールの内側で、お使いの Git リポジトリを適切に運用し、その上で共同作業を進めるのに重要ないくつかのフィーチャーが含まれています。フォークすること、つまりオープンソース開発分野で人気のある分散型開発ワークフローで、パーソナル リポジトリ単位やリポジトリ毎のパーミッションを得て、実行されるものです。
選択できること、フレキシビリティー、コントロール、それが Stash 2.4 です。
Stash をお持ちですか？
リリースノート (英語) をご覧ください »
Stash は初めてですか?
Stash 機能ツアーをご覧ください »
フォークのワークフロー
「フォーク」とは単に、サーバーサイドで、以前の履歴を含んだリポジトリのクローンを生成することを意味します。Stash におけるフォークでは、開発者に対し、書き込みアクセスができないリポジトリに、コードを返すワークフローを提供します。開発プロセスに管理的階層を追加するというものです。Stash では、リポジトリにある「Fork」ボタンをクリックすることで、Stash が追跡し、親リポジトリから独立して修正されたコピーを生成できます。さらにそこからコードを分離して思わぬ変更やエラーを避けることができます。自分が管理者アクセス権を持っている Stash 内の他プロジェクトへリポジトリをフォークしたり、個人フォークを生成して他の開発者にアクセスさせることができます。
なぜフォークするのか?
- 契約開発者にとって － 外部開発者のプロジェクトへの作業参加を可能にします。ただしコア・チームのみがリポジトリへの書き込みアクセス権を有します。契約開発者は、リポジトリをフォークし、プルリクエストを経由して変更を返すのみです。
- 大規模チームにとって － 何百もの開発者が同じリポジトリで作業しているので、リポジトリ内でのブランチや活動量の多さは、ただただ喧騒の素になるだけです。フォークを行うと、コア・リポジトリからプロジェクトへの新規追加を常にシンクロさせながら、各チームがそれぞれ独立して作業することができます。
- 試行として － フォークに基づく試行では、ShipIt に参加していても、プロジェクト妨害があっても、単なるフィーチャーの原型制作であっても、もし試行が失敗した場合、メイン・リポジトリがコミットで乱されることなく、開発者は不要な変更を廃棄することができます。
エンタープライズでフォークすることについての考察は “なぜフォークするのか?” をご覧ください。
リポジトリ パーミッション
管理者は、プロジェクトを、オープンにもクローズにもしておけます。ユーザーは、プロジェクト全体には手が届かず、プロジェクト内での個々のリポジトリへのアクセスだけが許可されることになります。これにはあなたのワークフローに利益となるシナリオがいくつかあります。
- 外部開発者 － 外部開発者と作業するときに、自分のリポジトリへのアクセスを開けっぴろげにオープンにすることは、かなり神経に障るものです。特定のプロジェクトにおいて、すべてのリポジトリにアクセスできるのは自分のコアチームだけ、という方がいいでしょう。契約開発者にはこちらで選んだリポジトリのみが使用可能という状態です。
- アクセスをオープンにする － 特定のプロジェクトにおいては、書き込みアクセスを開発小チームに制限しているチームが多いようです。作業の協力関係を促進するために、組織内の他メンバーには閲覧アクセスをオープンにし、コアチーム以外の人もフォークしたり、協力したりできるようにしておくことが有効です。
- 管理権を委託する － あるリポジトリへの管理アクセス権を信頼できるチームのメンバーに与え、その特定リポジトリ管理を自由できるように任せて、貴重な時間を節約することができます。
Stash では、あなたやチームが分散したコードでどのように作業するか選択することができます。この柔軟性があってこそ、作業を迅速に処理することができるのです。
