リポジトリとプルリクエストの使い方：変更を安全に取り込むレビューの流れ

Gitea を導入したら、最初に覚えたいのが、リポジトリとプルリクエストの使い方です。この二つを理解すれば、日々の開発の大半は回せるようになります。リポジトリは、コードとその変更履歴を保管する場所です。プルリクエストは、「この変更を取り込んでください」と提案し、仲間に確認してもらう仕組みです。

プルリクエストと聞くと、コードを書く人だけのものだと感じるかもしれません。実際には、設定ファイルや文書、サイトの本文のように、テキストで管理するものすべてに使えます。この記事では、リポジトリの作成から、レビューを経てマージするまでの流れを、Gitea の機能に沿って説明します。確認した時点は2026年11月15日で、ドキュメントの最新の安定版は 28.3.0 です。

直接書き込む運用が、あとで招く手戻り

小さなチームでは、全員が同じブランチに直接コードを書き込む運用になりがちです。手続きが少ないので始めやすい反面、人数や変更の量が増えるにつれて、問題が目立ちます。

• 誰かの変更が、ほかの人の作業を壊します。 確認を経ないまま取り込まれた変更が、ほかの人の作業と食い違い、原因の特定に時間がかかります。
• 変更の意図が残りません。 履歴には変更の内容が残りますが、なぜその変更が必要だったのか、どんな点を確認したのかは、残りにくくなります。
• 担当以外の人が気づく機会がありません。 書いた本人が見落としたものは、他の目で見たときに見つかることが少なくありません。

プルリクエストは、この手戻りを減らすための仕組みです。変更をいったんブランチに分け、確認を経てから本流に取り込むことで、品質と記録の両方を確保できます。次の節から、その流れを順に見ていきます。

リポジトリを作って、最初のコミットを置く

リポジトリは、画面の操作で作成します。名前と、公開するかどうか、最初に置くファイル（説明を書く README など）を指定します。作成後は、手元のパソコンに複製（クローン）して作業します。

git clone <リポジトリの URL>
cd <リポジトリ名>

URL は、リポジトリの画面に表示されるものを使います。SSH で接続する場合は、あらかじめ、自分のパソコンの公開鍵を、Gitea のユーザー設定に登録しておきます。

作業するときは、本流（多くの場合は main や master）に直接書かず、作業用のブランチを作ります。

git switch -c fix-typo

ファイルを編集してコミットし、そのブランチを Gitea に送ります。

git add README.md
git commit -m "READMEの誤字を修正"
git push origin fix-typo

ここまでで、Gitea 上に fix-typo というブランチが作られます。

プルリクエストを出して、確認してもらう

ブランチを送ると、Gitea の画面にプルリクエストを作る案内が表示されます。プルリクエストを作ると、変更の差分と、確認を依頼するための場が用意されます。

作成時に決めるのは、次の点です。

• タイトルと説明です。 タイトルの既定値は、設定で選べます。既定の first-commit は、いちばん古いコミットの要約を使います。auto を選ぶと、コミットが一つなら、そのコミットの要約を使い、複数なら、ブランチ名を文章に変換して使います。
• 作業中かどうかです。 まだ仕上がっていない場合は、タイトルの先頭に WIP: または [WIP] を付けます。大文字と小文字は区別されません。これらの目印が付いたプルリクエストは、誤ってマージされることが防がれます。
• 確認する担当者です。 担当者を指定すると、通知が届き、確認が始まります。

作業中の目印は、本来の使い方を意識すると効果的です。「途中だけれど、早めに方向性を見てほしい」ときに、WIP: を付けて出します。仕上がったら、目印を外して、正式な確認を依頼します。この運用なら、レビューを担当する人も、いま確認すべきものと、まだ待つものを区別できます。

この目印の文字列は、設定ファイル app.ini で変更できます。

[repository.pull-request]
WORK_IN_PROGRESS_PREFIXES=WIP:,[WIP]

日本語のチームで、独自の表記を使いたい場合は、ここに書き足すことで対応できます。

レビューの進み方

プルリクエストが出されると、担当者に通知が届きます。担当者は、差分を確認し、コメントを書き、必要なら変更を依頼するか、承認します。

進み方は、次のようになります。

1. 担当者が差分を読み、気になる箇所にコメントを付けます。
2. 変更が必要なら、変更を依頼します。
3. 作者は、同じブランチに追加のコミットを送ります。プルリクエストは、自動で更新されます。
4. 担当者が内容を確認し、承認します。
5. 承認されたプルリクエストは、権限を持つ人がマージします。

ここで大切なのは、2 と 3 の往復が、同じプルリクエストの中で完結することです。やり取りが一か所に記録されるため、あとから読み返したときに、なぜ最終的な形になったのかが分かります。

取り込まないと決めた場合は、「Close Pull Request」のボタンで、マージせずに閉じられます。却下の記録も、そのまま残ります。

ブランチを守る、権限で支える

プルリクエストの運用は、全員が守る前提でないと、形骸化します。誰かが本流に直接書き込めてしまうなら、手順を決めても意味がありません。

そのため、本流のブランチに保護を設定し、直接の書き込みを制限する使い方が、よく選ばれます。ドキュメントでも、コラボレーターに書き込み権限があっても、ブランチへの書き込みはブランチ保護の規則に従うことが説明されています。保護の規則を設けておけば、書き込み権限を持つ人も、決められた手順に従うことになります。

権限の設計は、チームの規模が大きくなるほど重要です。誰に何を許すのかを、組織とチームの単位で整理する方法は、組織とチームで権限を設計するで詳しく扱います。

GitHub などからの移行

すでに別のサービスでリポジトリを管理している場合は、Gitea の移行機能で取り込めます。ドキュメントによると、GitHub からは、Gitea 組み込みの移行用の画面を使います。課題やプルリクエストも取り込む場合は、少なくとも自分のユーザー名の入力が必要です。API を使う場合は、課題、ラベル、マイルストーン、プルリクエスト、リリース、Wiki を取り込むかどうかを、項目ごとに指定できます。

注意したいのは、取り込める範囲の確認です。ドキュメントでは、Gogs 0.11.46.0418 からの移行にも触れられていますが、GitLab については、組み込みの機能ではなく、第三者が作ったツールが案内されています。このツールは、Gitea とは関係のない別のプロジェクトです。移行する元のサービスによって、手順が異なることを、事前に確認しておく必要があります。

また、移行したあとは、取り込んだ内容を確認します。リポジトリの履歴、課題の件数、プルリクエストの状態など、重要なものを元の環境と見比べます。移行前の環境は、確認が終わるまで残しておくのが安全です。

変更を小さく保ち、読みやすくする工夫

プルリクエストの効果は、レビューする人が、内容を無理なく理解できるかどうかに左右されます。大きすぎる変更は、見落としが増え、確認に時間がかかります。そこで、次のような工夫が役に立ちます。

• 一つのプルリクエストでは、一つの目的だけを扱います。 不具合の修正と、見た目の整理を、同じ提案に混ぜないようにします。
• 変更の量を、読み切れる範囲にします。 大きな変更は、段階に分けて、順に出します。
• 説明に、理由を書きます。 何を変えたかは差分から分かります。なぜ変えたのか、どう確かめたのかは、書かなければ伝わりません。
• ブランチの名前から、内容が分かるようにします。 fix-typo のように、目的が読み取れる名前にします。
• コミットのメッセージを、あとから読める形にします。 変更の要点が一行で分かると、履歴をたどるときに役立ちます。

これらは Gitea 固有の機能ではなく、レビューを回すための一般的な習慣です。ただ、Gitea の画面では、説明の欄、コメント、コミットの一覧が一か所に集まるため、こうした工夫の効果が、そのまま画面に現れます。

レビューする側の心がけ

レビューは、書いた人を評価する場ではなく、変更の質を高める場です。担当者が意識しておくと、やり取りが円滑になる点があります。

1. まず、変更の目的を理解します。 説明を読み、何を実現しようとしているのかを把握してから、差分に進みます。
2. 指摘は、理由とともに書きます。 「直してください」だけでは、書いた人は判断できません。どこが問題で、どうなると困るのかを添えます。
3. 必須の修正と、提案を区別します。 取り込む前に必ず直してほしいことと、気づいた点の共有を、書き分けます。
4. 確認が終わったら、結果を明確に示します。 承認するのか、変更を依頼するのかを、はっきりさせます。曖昧なままでは、作者が次に何をすればよいか分かりません。

Gitea では、担当者が、コメント、変更の依頼、承認の三つの方法で意思を示せます。この三つを使い分けるだけでも、レビューの状況が、画面上で一目で分かるようになります。

作業中の提案と、完成した提案を区別する

WIP: の目印は、小さな機能ですが、チームの意思疎通に大きく貢献します。たとえば、設計の方向性を早めに確認したいとき、完成を待たずにプルリクエストを出せます。目印が付いているので、担当者は、細かな指摘を控え、方向性についてのコメントに絞って返せます。

目印を外したときが、正式な確認の依頼になります。この区別がないと、「どこまで見ればよいのか」が、担当者に伝わりません。チームで、「目印を付けたものは、方向性の確認だけ」「外したものは、細部まで確認」という約束を共有しておくと、無駄な往復が減ります。

小さな修正から、運用を始める

仕組みを導入する際は、いきなり大きな変更で試さないほうが安全です。最初は、README の誤字の修正のような、影響の小さい変更で、一通りの流れを体験します。ブランチを作り、push し、プルリクエストを出し、レビューを受けてマージする。この一周を、チーム全員が一度経験しておくと、その後の変更でも、手順に迷いません。

体験する際は、次の点を意識すると、学びが大きくなります。

• 差分の画面で、どの行が変わったのかが、どう表示されるのか。
• コメントを付けたときに、作者へ、どのように通知が届くのか。
• 追加のコミットを送ると、プルリクエストが、どう更新されるのか。
• マージしたあとに、履歴が、どのように記録されるのか。

最初の一周は、誰かが操作を見せながら、全員で行うのも一つの方法です。画面の見方や、言葉の意味を、その場で確認できます。

取り込んだあとの、後片づけ

プルリクエストがマージされたら、作業に使ったブランチは、役目を終えています。そのまま残しておくと、ブランチの一覧が増え、どれが現役なのか分かりにくくなります。マージ後は、不要になったブランチを、削除する習慣をつけておくと、リポジトリが整理された状態に保たれます。

日々の運用に取り入れるために

ここまでの流れを、日々の運用に落とし込むと、次のように整理できます。

最初から完璧な運用を目指す必要はありません。まずは、本流への直接の書き込みをやめ、すべての変更をプルリクエストで出すことから始めれば十分です。慣れてきたら、保護の規則や、確認する担当者の決め方を、少しずつ整えていきます。

自動テストを組み合わせると、確認の負担はさらに減ります。プルリクエストが出された時点で、テストやビルドを自動で実行し、結果をレビューの材料にできます。その仕組みは、Gitea Actions で CI/CD を始めるで説明します。この記事の内容は、2026年11月15日時点のドキュメントに基づいています。