---
sidebar_position: 2
title: Gitea × OpenClaw 連携の開発プロセス実践ガイド
description: Issue/PR Webhook連携でAI開発を回すための実運用プロセス（ブランチ戦略、レビュー、マージ、再発防止）
hide_table_of_contents: false
displayed_sidebar: null
---

# Gitea × OpenClaw 連携の開発プロセス実践ガイド

## はじめに

Gitea Webhook で OpenClaw を呼び出す構成は便利ですが、運用ルールが曖昧だとすぐ壊れます。

この記事では、実際に運用しながら整えた **Issue/PR 駆動の開発プロセス** をまとめます。

## 目的

- Issue を起点に AI が修正提案・実装を進める
- PR でレビューし、問題なければ main へ反映
- ブランチ運用・反映手順を毎回明示し、Git に不慣れでも迷わない

## 全体フロー

1. Gitea で Issue を作成
2. Webhook Bridge が OpenClaw にタスク転送
3. 修正ブランチで実装・検証
4. PR 作成
5. PR Webhook で最終レビュー
6. main へマージ
7. Issue に進捗コメント（手順付き）

## 運用ルール（重要）

### 1) 変更は必ず作業ブランチで

- `fix/issue-<番号>-<要約>`
- `feat/issue-<番号>-<要約>`
- `docs/issue-<番号>-<要約>`

### 2) Issue コメントに毎回この3点を記載

- ブランチ切替コマンド
- 検証コマンド
- main へのマージコマンド

### 3) PR イベントも Webhook で処理

`issues` だけでなく `pull_request` も受ける。
対象アクションは最低限以下を推奨：

- `opened`
- `reopened`
- `synchronize`

## 実用テンプレ（そのまま使える）

### ブランチ切替

```bash
git fetch origin
git switch fix/issue-123-xxx
# 古いgitなら: git checkout fix/issue-123-xxx
```

### 検証

```bash
python3 -m py_compile src/*.py app/*.py
python3 app/web_ui.py --port 7860 --config config/config.yaml
```

### main へ反映

```bash
git switch main
git pull origin main
git merge --no-ff fix/issue-123-xxx
git push origin main
```

## 破綻しやすいポイントと対策

### Webhook が `EOF` で失敗

- 原因の多くは受信サーバー側の例外落ち
- `do_POST` 全体を `try/except` で囲み、必ず HTTP 応答を返す

### 別機能の修正で Webhook が壊れる

- ブリッジ機能を分離（例: Gitea用 / Discord用を別リポ・別サービス）
- systemd サービスも分離

### ローカル設定ファイルが pull を壊す

- `config.yaml.example` を追跡
- `config.yaml` は `.gitignore`

## まとめ

Gitea × OpenClaw 連携は、技術そのものより **運用ルールの明文化** が効きます。

- ブランチ命名を固定
- Issue コメントのテンプレを固定
- PR Webhook まで含める
- 失敗しやすい箇所を分離・自動化

この4つを守るだけで、連携はかなり安定します。

---
*この記事は2026年2月時点の情報です。*