Gitは、ファイルの変更履歴を管理する仕組みです。GitHubやGiteaは、Gitで管理しているリポジトリを共有し、変更の確認や作業管理をしやすくするために使います。
目次
Git・GitHub・Giteaは何が違うのか
まずは、次のように分けると分かりやすいです。
| 用語 | 役割 |
|---|---|
| Git | 自分のPCなどでファイルの変更履歴を記録する |
| GitHub | Gitリポジトリの共有、変更のレビュー、課題管理などを行う |
| Gitea | Gitリポジトリの共有、変更のレビュー、課題管理などを行う。自分たちのサーバーに構築できる |
Gitだけでも、自分のPCで履歴を残せます。GitHubやGiteaのアカウントは必須ではありません。
この記事は「Git・Gitea入門」シリーズの第1回です。まず全体像を確認し、第2回の運用ルール、第3回の基本コマンドへ進めるように整理します。
Gitでできること
Gitは、分散型バージョン管理システムと呼ばれます。ファイルの変更を記録しておくことで、後から変更内容を確認したり、記録した時点の状態を取り出したりできます。
たとえば、アプリやWebサイトの作業では、次のように使います。
- どの変更で何を直したか確認する
- 新機能の作業を、安定版とは別のブランチで進める
- 複数人の変更を確認しながら取り込む
- 変更前の状態と見比べる
ただし、ファイルを編集しただけでは履歴に残りません。残しておきたい変更を、自分で「コミット」する必要があります。
Gitによる履歴管理の考え方は、Git公式の入門資料でも説明されています。
最初に押さえたい4つの用語
リポジトリ
リポジトリは、プロジェクトのファイルと変更履歴を管理する単位です。
アプリ開発なら、プログラム、画像、設定ファイル、READMEなどの説明ファイルをまとめて管理します。
コミット
コミットは、変更を履歴として記録することです。作業の区切りごとに、「何を変更したか」が分かるメッセージを付けます。
ログイン画面を追加
ヘッダーの表示崩れを修正
READMEにセットアップ手順を追記
コミットした内容は、まずローカルの履歴に残ります。コミットしただけでGitHubやGiteaに送られるわけではありません。
ブランチ
ブランチは、作業の流れを分けるために使います。
たとえば、main を安定版として扱い、問い合わせフォームの追加は feature/add-contact-form で進める、といった使い方です。作業を終えたら、変更を確認して元の流れに取り込みます。
main という名前だけで安全になるわけではないので、直接変更してよいか、確認後に取り込むかは別に決めます。
ローカルとリモート
ローカルは、手元で作業するリポジトリです。リモートは、変更を送ったり取得したりする相手のリポジトリです。
よくある構成は、次のようになります。
自分のPC GitHub / Gitea
ローカルリポジトリ ←→ リモートリポジトリ
リモートはインターネット上に限りません。社内ネットワーク上や、同じPC内の別の場所にあるリポジトリも指定できます。Git公式のリモートの説明にも、この点が補足されています。
コミットとpushの違い
GitHubやGiteaを使う場合、基本的な流れは次のようになります。
- 自分のPCでファイルを編集する
- 変更内容を確認し、コミットに含めるファイルを選ぶ
- コミットして、ローカルに履歴を残す
pushして、リモートに変更を送る
ここで覚えておきたいのは、コミットは手元への記録、pushはリモートへの送信、という違いです。
チームで作業する場合や、重要なブランチを保護している場合は、作業ブランチをpushした後にPull Requestを作成し、変更の確認やチェックを通してから取り込みます。
具体的なコマンドは、第3回：Gitの基本的なコマンドで扱います。
GitHubとGiteaを選ぶときの違い
GitHubとGiteaでは、どちらもブラウザからファイルや履歴を確認でき、IssueやPull Requestを使えます。
- Issue：不具合や作業予定などを記録するもの
- Pull Request：別のブランチへ取り込む変更を確認・相談するもの
GitHubの役割はGitHub公式ドキュメント、Giteaの主な機能はGitea公式ドキュメントで確認できます。
ここでは、GitHubが運営する GitHub.com と、自分たちでサーバーを用意する セルフホスト版Gitea を比べます。
| 確認すること | GitHub.com | セルフホスト版Gitea |
|---|---|---|
| サーバーの準備 | 自分で用意する必要はない | 自分たちで用意する |
| サーバーの更新や障害対応 | サービス側が担当する | 自分たちで担当する |
| コードの置き場所 | GitHubのサービス上 | 自分たちで選んだ環境 |
| 公開範囲や利用権限 | 利用者側で設定する | 利用者側で設定する。接続できるネットワークも設計できる |
| 導入前に確認すること | 外部サービスの利用可否、必要な機能やプラン | 運用担当者、更新方法、バックアップと復旧方法 |
GiteaにもマネージドサービスのGitea Cloudがあります。また、GitHubにも自分たちの環境で運用できるGitHub Enterprise Serverがあります。製品名だけで決めず、どの提供形態を使うかまで確認します。
サーバー管理をせずに始めたい場合
個人でGitを学ぶ入口としては、GitHub.comが始めやすい選択肢です。自分でサーバーを準備せずに、リポジトリを作成できます。
公開リポジトリでコードを共有するほか、非公開リポジトリも使えます。会社のコードを扱う場合は、非公開であっても、そのサービスに置いてよいかを先に確認します。
自分たちの環境に置きたい場合
社内ネットワーク内で管理したい場合や、サーバーの構成を自分たちで決めたい場合は、セルフホスト版Giteaが選択肢になります。
ただし、構築後の更新、バックアップ、復旧まで担当する人が必要です。Giteaのバックアップ・復旧手順を確認し、サーバーが止まったときに戻せるかまで考えておきます。
GitHubは組織でも使えますし、Giteaは個人でも使えます。個人か組織かだけでなく、コードを置ける場所と、運用を担当できるかで選ぶと判断しやすくなります。
使い始める前に決めておくこと
どちらを使う場合も、最低限、次の3点は決めておきます。
- 誰に見せてよいリポジトリか
- パスワードやAPIキーなど、入れてはいけない情報は何か
- どのブランチで作業し、何を確認してから取り込むか
公開リポジトリでは、作業用のブランチも非公開の下書き置き場にはなりません。まだ見せられない内容を送る前に、リポジトリ自体の公開範囲を確認します。
次に読む記事
全体像が分かったら、次は自分の作業に必要なルールと操作を確認します。
- 第2回：Git、Giteaを始める前に決めるべきルール：公開範囲、ブランチ、コミットの決めごと
- 第3回：Gitの基本的なコマンド：状態確認からコミット、pushまでの操作
GitHubを1人で使いながら、main への反映前に確認する流れを作りたい場合は、main保護設定の実例も参考にしてください。Pull Requestと必須チェックを使う設定を整理しています。