Skip to main content
1つのPRとしてではレビューしづらいほどタスクが大規模な場合、Devinはタスクをスタックに分割できます。スタックとは、1つの作業を構成する順序付きの一連のプルリクエストで、下から上へ順にまとめてマージされます。スタック内の各PRは、直下のPRを基盤とする通常の焦点を絞ったPRです。レビュアーは、巨大な単一のdiffではなく、小さく自己完結した変更を一度に1つずつ確認できます。 DevinのスタックはGitHubネイティブのスタック型プルリクエストを基盤としているため、スタックはブランチ名の命名規則によって成り立つ慣例ではなく、GitHubの第一級オブジェクトです。
スタック型PRはGitHub.comのリポジトリでのみサポートされています。GitHub Enterprise Server、GitLab、その他のプロバイダーには、スタック型PR用のAPIがありません。

​
スタックの仕組み

スタックは一連のパッチです。
  • PRは下から上に順番に積み重なります。最下位のPRはトランクブランチ (例: main) を対象とし、それ以外のPRのベースブランチは、その直下のPRのヘッドブランチになります。
  • 各PRは直下のレイヤーとの差分として表示されるため、そのPR固有の変更のみが表示され、上下のレイヤーの変更が混ざることはありません。
  • スタックは下から上へマージされます。スタック内のPRをマージすると、その下にあるすべてのオープンなPRも、1回の操作でアトミックにマージされます。下位のPRがマージされると、GitHubは残りのPRのベースブランチを自動的にトランクブランチに変更します。

​
Devin がスタックを作成する場合

Devin は場当たり的にではなく、意図してスタックを作成します。1 つの作業を、まとめてマージされるよう設計された順序付きの一連の PR に意図的に分割した場合にのみ、スタックを作成します。たとえば、スキーマの変更、そのスキーマを利用するサービス層、その上に構築する UI という順です。単に別の PR のブランチに基づいているだけの PR は、スタックとしてグループ化されません。 Devin がスタックを計画する場合、次のことを行います。
  1. スタックを告知します。PR を作成する前にスタック名を示すため、セッション内で一連の PR が形作られていく様子を確認できます。
  2. 各 PR を作成します。それぞれ独自の説明と CI を備えた、通常どおり焦点を絞った PR として作成します。各 PR の対象ブランチは、その下にある PR のヘッドブランチです。
  3. PR をスタックとしてグループ化します。PR の作成後、GitHub 上でグループ化します。
各レイヤーには、Devin が作成する単独の PR と同じ基準が求められます。つまり、最小限で焦点を絞った diff と、コードを見たことがないレビュー担当者向けに書かれた、要点を押さえた説明です。

​
スタックの整合性を保つ

スタックは一度作成したら固定されるわけではありません。Devinはセッション中、スタック内のすべてのPRに継続してアタッチします。
  • 競合の解決 — いずれかのレイヤーで、その下のブランチとのマージ競合が発生した場合 (たとえば、下位レイヤーにレビューのフィードバックが反映された後や、スタックの下でトランクブランチが更新された場合) 、Devinに自動的に通知され、競合をバックグラウンドで解決します。判断に影響し、入力が必要な競合の場合にのみ、確認を求めます。
  • スタック全体のCI — Devinは各レイヤーのCIを監視し、失敗が発生すると修正します。PRを1件ずつ管理するのではなく、シリーズ全体の準備状況を追跡します。
  • 自動リターゲティング — スタックの最下層がマージされると、GitHubは残りのPRのターゲットをトランクブランチに変更します。手動でrebaseを管理する必要はありません。

​
スタックの操作

セッションでは、Devin のスタックの扱いを指示できます。
  • 大規模な変更をスタックに分割するよう Devin に依頼することも、作業を単一の PR として維持するよう依頼することもできます。
  • 既存のスタックの先頭にフォローアップ PR を追加するよう Devin に依頼できます。
  • スタックのステータスを確認するよう Devin に依頼できます。各レイヤーの状態、CI、レビュー結果、マージ可能性が報告されます。
  • Devin に unstack を依頼できます。スタックは解除され、未マージの PR は再び独立した PR になります。ブランチはそのまま保持され、すでにマージされたレイヤーはマージ済みのままです。
セッションビューでは、スタックに属する PR にスタックへの所属が表示されます。また、通知されたスタックは PR が作成される前に表示されるため、Devin が一連の変更を作成する様子を追うことができます。

​
スタックのレビューとマージ

Devin Review では、スタックは第一級の概念として扱われます。シリーズ全体をひと目で確認でき、各レイヤーの準備状況も把握できます。マージは、アトミックな下から上へ方式のスタックマージで行われます。詳細は、Devin Review ドキュメントの スタック型PR セクションを参照してください。

​
制限事項

  • GitHub.com のみ — スタックは GitHub Enterprise Server、GitLab、Bitbucket、Azure DevOps では利用できません。
  • スタックのサイズ — スタックには 2～100 件の PR を含めることができます。
  • マージ — スタック型PR は GitHub の通常のマージフローではマージできません。スタックマージでは、選択した PR とその下にあるすべてのオープンな PR がまとめてマージされます。