仕上げ、マージ、クリーンアップ

ワークフローのレビューが終了して reviewed になると、CodeDAG の側の仕事は完了です。デフォルトの分離ブランチモードでは、レビューを通った結果はすべて、ローカルの統合ブランチ cdg/<ワークフロー名>/integration にあります。メインブランチは変更されておらず、リモートリポジトリへのプッシュも行われていません。結果の確認、メインブランチへのマージ、増えたブランチのクリーンアップは、どれも自分で Git を使って行います。共有ワークスペースモードには、これらのブランチがありません。共有ワークスペースモードでの仕上げを参照してください。

統合ブランチの結果を確認する

統合ブランチ cdg/<ワークフロー名>/integration には、今回の実行で承認されたタスクの結果がすべて集まっています。このブランチは今回のワークフローのベースから作られているので、main と比較すれば、このワークフローによる変更のすべてがわかります。各ブランチの関係は、タスクブランチ、統合ブランチ、ベースを参照してください。

git log --oneline --no-merges main..cdg/<ワークフロー名>/integration
git diff --stat main...cdg/<ワークフロー名>/integration

1 つ目のコマンドは、各タスクが残したコミットを一覧表示します。--no-merges を付けているので、CodeDAG が各タスクブランチをマージしたときのマージコミットは省かれます。CodeDAG はタスクを承認するときに、そのタスクの変更をタスクブランチにコミットします。コミットメッセージはデフォルトでタスクのタイトルになるので、どのコミットがどのタスクのものかを対応づけられます。たとえば、3 つのタスクからなるワークフロー add-notes では、次のようになります。

569eb2f Build notes index
a251a6a Write beta note
483711d Write alpha note

CodeDAG は、タスクの完了を判定するときも、結果を自動承認するときも、テストが通ったかどうかを見ません。変更が正しいかどうかは、自分で確認する必要があります。マージする前に変更をひととおり読み、統合ブランチでプロジェクトのテストを実行してください。プライマリリポジトリが実行に使われていた場合、ワークフローの終了後、プライマリリポジトリは統合ブランチをチェックアウトした状態になっています。そのため、プライマリリポジトリでそのままコードを読み、テストを実行できます。

ワークフローに dagAutoAccepted: none を設定していて、結論を待って止まっているときも、統合ブランチにはマージ済みの結果がすでにあります。同じコマンドで先に確認したうえで、ワークフロー全体をレビューできます。

メインブランチにマージする

いつ、どのような方法でマージするかは自分で決め、自分で操作します。リモートにプッシュしてプルリクエストを作成することも、ローカルで直接マージすることも、一部のタスクの結果だけを取り込むこともできます。CodeDAG 自体が、リモートリポジトリにプッシュしたり、リモートリポジトリからプルしたりすることはありません。

チームで開発している場合は、通常、チームの規約に沿った名前のブランチを統合ブランチから新しく作り、プッシュしてからプルリクエストを作成します。

git checkout -b <自分のブランチ名> cdg/<ワークフロー名>/integration
git push -u origin <自分のブランチ名>

ワークフローを既存のフィーチャーブランチから始めていた場合は、代わりにそのブランチに戻って統合ブランチをマージし、それからプッシュします。統合ブランチをそのままプッシュすることもできます。ただし、統合ブランチの名前はワークフロー名から決まるため、ほかのメンバーが同じワークフローを実行すると、同じ名前のブランチができます。これを同じリモートにプッシュすると、名前が衝突します。

個人プロジェクトなどでコードレビューが不要な場合は、ローカルで直接マージできます。main に戻ってから、統合ブランチをマージします。

git checkout main
git merge cdg/<ワークフロー名>/integration

このマージに CodeDAG は関与しません。ワークフローの実行中に main に新しいコミットが入り、そのためにコンフリクトが起きた場合は、普段と同じように解決してください。

一部のタスクの結果だけを取り込む

各タスクの結果は、それぞれのタスクブランチにも残っています。ブランチ名は cdg/<ワークフロー名>/t<タスク ID>-<タイトル> の形式です。そのため、統合ブランチを使わずに、一部のタスクだけを main にマージすることもできます。

git branch --list 'cdg/<ワークフロー名>/*'
git merge cdg/<ワークフロー名>/t<タスク ID>-<タイトル>

マージするときは、依存関係に注意してください。下流タスクが始まる前に、CodeDAG は上流の結果をそのタスクのブランチにマージしています。そのため、下流タスクのブランチをマージすると、その上流の結果も一緒に入ってきます。そのタスク自身の変更だけが欲しい場合は、代わりに git cherry-pick を使って、そのタスク自身のコミットだけを取り込みます。通常は、タスクのタイトルがコミットメッセージになっているコミットです。

このほかに、別の扱いが必要な場合が 2 つあります。1 つは、キャンセルまたは見送りになったタスクです。変更はデフォルトで、cdg/<ワークフロー名>/snapshots/ で始まるスナップショットブランチに保存されていて、タスクブランチはタスク開始前の状態に巻き戻されています。取り出す方法は、スナップショットから一部の変更を取り出すを参照してください。もう 1 つは、clone をレプリカにしている場合です。ある clone で実行されたタスクのタスクブランチは、その clone にしかなく、プライマリリポジトリにはありません。必要なときは、その clone からフェッチします。

ワークフローの終了後、リポジトリはどのブランチにあるか

ワークフローが終了しても、CodeDAG がワークスペースを元のブランチに戻すことはありません。プライマリリポジトリが実行に使われていた場合、プライマリリポジトリは、このワークフローの統合ブランチをチェックアウトした状態のままです。各レプリカは、そこで最後に実行されたタスクのブランチをチェックアウトした状態のままです。main には何の変化もありません。main に戻りたいときは、自分で git checkout main を実行します。こうなる理由は、タスクブランチ、統合ブランチ、ベースを参照してください。

ここで main に戻すかどうかで、次のワークフローがどこから始まるかも決まります。baseRef を書いていないワークフローは、実行開始時にプライマリリポジトリでチェックアウトされているコミットをベースにします。プライマリリポジトリが統合ブランチのままなら、次のワークフローは今回の結果の続きから作業し、main に戻していれば、main から始まります。そのときプライマリリポジトリがどのブランチにあるかにベースが左右されないようにするには、ワークフローファイルに baseRef を書きます。たとえば baseRef: main です。

実行中もプライマリリポジトリのブランチを切り替えられたくない場合は、ワークフローファイルに excludeWorkspaces: ["."] と書いて、タスクをレプリカだけで実行させます。こうすると、プライマリリポジトリのブランチは終始そのままです。方法はワークフローの実行中に自分でも開発を続けるを参照してください。

もう一度実行する

レビューが終了したワークフローは、そのままでは再投入できません。cdg dag submit を実行すると、ワークフローが reviewed フェーズにあると表示されます。先にレビュー記録をクリアして planning に戻してから、投入します。

cdg dag review clear <ワークフロー名>
cdg dag submit <ワークフロー名>

再投入は、新しい実行になります。投入した時点のワークフローファイルの内容で実行され、実行が始まるときに、タスク数の分の CodeDAG クレジットが改めて消費されます。課金ルールは、クレジットが差し引かれるタイミングを参照してください。まだキューにあるワークフローのレビュー記録は、そのままではクリアできません。先に、ワークフローレベルのレビューの結論を出す必要があります。手順は投入済みのワークフローを変更するを参照してください。

投入する前に、新しい実行がどこから始まるかを確認してください。baseRef を書いていない場合は、その時点でプライマリリポジトリにチェックアウトされているコミットから始まります。プライマリリポジトリが前回の統合ブランチのままであっても、前回の結果をすでに main にマージしていても、新しい実行は前回の結果の上で進み、タスクは変更済みのコードを相手にすることになります。元のコードをもとにやり直したい場合は、マージする前に git checkout main を実行しておくか、ワークフローファイルに baseRef: main と書きます。

前回の実行で作られたブランチが残っている場合、新しい実行のブランチ名には、名前が重ならないように、実行開始時の日時が付きます。たとえば cdg/add-notes-20260930-105924/integration です。ワークフローの名前は変わらないので、コマンドではこれまでどおり add-notes と書きます。branchName でブランチ名を指定したタスクは、自動では名前が変わりません。同じ名前の古いブランチが残っていると、このタスクは on-hold で止まります。対処方法はブランチの問題を参照してください。

別のファイル名で投入する

定期実行のジョブで毎日 1 回投入する場合のように、ワークフローを繰り返し実行するときは、レビュー記録をクリアしない方法もあります。毎回ワークフローファイルをコピーし、ファイル名にサフィックスを付けて、その新しいファイルを投入します。

cp .codedag/dags/add-notes.yaml .codedag/dags/add-notes-20261010.yaml
cdg dag submit add-notes-20261010

ワークフローの名前はファイル名から決まるので、新しいファイルは別のワークフローになります。投入するのに、前回の実行のレビューが終了している必要はありません。前回の実行がまだキューにある場合は、その後ろに並びます。実行ごとの記録も、別々に残ります。以前の各実行の状態とレビュー結果は、これまでどおり cdg dag status <ワークフロー名> で確認できます。今回の実行のブランチはすべて cdg/add-notes-20261010/ の下に作られ、ログも専用のファイルに書かれます。その代わり、実行するたびに、ワークフローファイルが 1 つ、ブランチが 1 組、ログファイルが 1 つ増えます。ブランチとログのクリーンアップは、ブランチとワークスペースをクリーンアップするを参照してください。

ベースと課金のルールは、レビュー記録をクリアして再投入する場合と同じです。タスクに branchName を書いている場合、新しいファイルでもブランチ名は同じままなので、古いブランチが残っていると、タスクは同じように on-hold で止まります。

一部のタスクだけをあとから実行する

再投入では、必ずワークフロー全体が実行されます。一部のタスクだけをあとから実行したい場合や、やり直したい場合は、それらを新しいワークフローファイルに書いて、別に投入します。クレジットが消費されるのはそのタスクの分だけなので、全体を再実行するよりも少なくて済みます。

新しいワークフローは、すでに承認された結果から始める必要があります。baseRef を書かない場合、プライマリリポジトリが前のワークフローの統合ブランチのままであるか、結果を main にマージして main に戻していれば、新しいワークフローはその結果の続きから作業します。baseRef: cdg/<ワークフロー名>/integration と書いて、明示的に指定することもできます。元の上流タスクは新しいワークフローに含まれないので、dependencies には書けません。その結果はすでにベースに入っているので、読むべきファイルをプロンプトで指定すれば十分です。

ワークフローがまだ実行中で、途中まで進んだものの続けるのが難しくなった場合は、まず完了済みの結果を確保します。手順はワークフローが途中まで進んだが、続けるのが難しいを参照してください。そのうえで、同じ方法で続きを進めます。

ブランチとワークスペースをクリーンアップする

ワークフローのレビューが終了し、必要な結果もマージし終えたら、ワークフローが残したブランチとログ、そして使わなくなったレプリカは、どれもクリーンアップできます。クリーンアップの対象にするのは、レビューが終了したワークフローだけです。まだキューにあるワークフローや、レビューを待っているワークフローでは、CodeDAG がそのブランチでマージやレビューを続ける必要があり、ブランチを削除するとその処理が妨げられます。たとえば、統合ブランチが削除されると、ワークフローは on-hold で止まります。

ブランチを削除する

ワークフローが残すブランチは、どれも cdg/<ワークフロー名>/ で始まります。タスクブランチ、統合ブランチ、そして cdg/<ワークフロー名>/snapshots/ の下のスナップショットブランチです。Git では、いずれかのワークスペースでチェックアウトされているブランチは削除できません。ワークフローの終了後、プライマリリポジトリは統合ブランチを、worktree の各レプリカは最後に実行したタスクのブランチをチェックアウトしています。そのため、先にプライマリリポジトリとレプリカを、これらのブランチから切り替えておく必要があります。そうしないと、削除するときに cannot delete branch ... used by worktree というエラーが表示されます。

git checkout main
# worktree のレプリカごとに 1 回ずつ実行する
git -C ../<プロジェクト名>-wt-1 checkout --detach

続いて、このワークフローのブランチを一覧表示し、確認してからまとめて削除します。

git branch --list 'cdg/<ワークフロー名>/*'
git branch --list 'cdg/<ワークフロー名>/*' --format='%(refname:short)' | xargs git branch -D

再実行したことのあるワークフローには、名前に日時の付いたブランチの組もあります。git branch --list 'cdg/<ワークフロー名>-*/*' で一覧表示し、確認してから同じように削除します。clone をレプリカにしている場合、clone で実行されたタスクのブランチは、その clone の中で削除します。codedag-mirror リモートは CodeDAG が管理しているので、そのままにしておいてかまいません。その中で固定のブランチ名を占有しているブランチは、cdg branch release <ブランチ名> で解放します。

古いログを削除する

各ワークフローのログは、.codedag/local/logs/ の下にある 1 つの .log ファイルに書かれます。パスはログファイルの場所を参照してください。再実行したときのログは、同じファイルの末尾に追記されます。不要になったら、このファイルをそのまま削除してかまいません。

使わなくなったレプリカを削除する

レプリカは、ずっと残しておいてかまいません。今後のワークフローでも、並列実行に引き続き使われます。worktree のレプリカが本当に不要になった場合は、そのレプリカを削除してから cdg init をもう一度実行し、登録されているレプリカを実際の状態に合わせます。

git worktree remove ../<プロジェクト名>-wt-1
cdg init

初期化し直すときに既存の設定を残す方法は、再初期化と既存の設定の保持を参照してください。

共有ワークスペースモードでの仕上げ

共有ワークスペースモードには、タスクブランチも統合ブランチもなく、プライマリリポジトリのブランチが切り替えられることもありません。すべてのタスクの成果物は、タスクが実行されたワークスペース（デフォルトではプライマリリポジトリ）に、未コミットの変更として残ります。確認したうえで、自分でコミットしてください。ここまでの各節で説明したブランチの操作は、このモードではどれも当てはまりません。もう一度実行する方法は同じで、cdg dag review clear を実行してから cdg dag submit を実行します。新しい実行は、ワークスペースに今あるファイルの上で進みます。

よくある質問

統合ブランチへのマージ中にワークフローが止まった

すべてのタスクのレビューが終わると、CodeDAG は各タスクの結果を統合ブランチにマージします。複数のタスクの変更がコンフリクトし、別に起動されたエージェントセッションが 3 回試みても解決できなかった場合、ワークフローは on-hold で止まり、理由は integration-merge-conflict になります。この時点では、統合ブランチにまだ完全な結果がありません。統合ブランチがチェックアウトされているワークスペース（通常はプライマリリポジトリ）でマージを完了させてから、cdg dag recover <ワークフロー名> を実行します。ワークフローは、残りの結果のマージを続けます。具体的な手順は、マージコンフリクトを参照してください。

統合ブランチに変更が何もない

最もよくある原因は、ワークフローレベルのレビューで cancel または defer を実行したことです。分離ブランチモードでは、どちらのアクションでも、統合ブランチが今回のワークフローのベースに戻ります。デフォルトでは、CodeDAG は先に結果全体を、cdg/<ワークフロー名>/snapshots/dag-review- で始まるスナップショットブランチに保存するので、必要なときはそこから取り出せます。スナップショットから一部の変更を取り出すを参照してください。もう 1 つ考えられるのは、タスクがすべてキャンセルまたは見送りになった場合です。それぞれの変更は、同じようにデフォルトでスナップショットブランチに保存されています。

関連ページ

• タスクとワークフローをレビューする：タスクやワークフローがレビューゲートで止まっているときに、結果を確認して結論を出す方法。
• レビュー：レビューアクションの引数とデフォルト値、レビュー記録をクリアするときのルール。
• ファイルとブランチの操作：スナップショットブランチから変更を取り出す方法と、ワークフローの設定を別に保存する方法。