この記事は「Git・Gitea入門」シリーズの第2回です。前提となる用語は 第1回：Git、Giteaとは で、実際の操作は 第3回：Gitの基本的なコマンド で整理しています。
GitやGiteaを使い始めるときは、最初に最低限のルールを決めておくと運用が安定します。
前回は、Gitがファイルの変更履歴を管理する仕組みであり、GiteaはそのGitリポジトリを組織内や自分たちの環境で共有・管理するためのサービスだと整理しました。
今回は、その前提をもとに、実際にGitやGiteaを使い始める前に決めておきたいルールを整理します。
なぜ最初にルールを決める必要があるのか
Gitは非常に便利な仕組みですが、自由度が高い道具でもあります。
そのため、何も決めずに使い始めると、次のような問題が起きやすくなります。
- どのブランチで作業すればよいか分からない
- コミットメッセージの書き方が人によってバラバラになる
- 重要なファイルを誤って公開してしまう
- 誰がどの変更を確認するのか分からない
- 変更履歴は残っているが、後から見ても意味が分からない
Gitは履歴を残してくれますが、履歴の意味までは自動で整理してくれません。
そこは人間側のルールが必要です。
つまり、GitやGiteaを使う前に決めるべきことは、単なる作業手順ではありません。
「どのように変更を記録し、どのように共有し、どのように確認するか」を決めることです。
個人利用と組織利用ではルールの重さが違う
GitやGiteaのルールは、個人利用と組織利用で必要な細かさが変わります。
個人で使う場合は、自分が後から見て分かる程度のルールでも十分です。
一方、組織で使う場合は、複数人が同じリポジトリを扱うため、より明確なルールが必要になります。
個人利用の場合
個人利用では、ルールを細かくしすぎる必要はありません。
たとえば、次のような最低限のルールで十分です。
- 作業前に
git statusで状態を確認する - 1つの作業ごとにコミットする
- コミットメッセージは後から見て内容が分かるように書く
- 大きな変更は専用ブランチで作業する
- APIキーやパスワードはコミットしない
個人利用では、ルールが複雑すぎると続かなくなります。
まずは「事故を防ぐ」「後から見て分かる」ことを重視するとよいです。
組織利用の場合
組織利用では、個人利用よりもルールを明確にする必要があります。
理由は、自分だけでなく他の人も同じリポジトリを使うからです。
たとえば、次のような点を決めておく必要があります。
- 誰がリポジトリを作成できるか
- 誰が変更を取り込めるか
- どのブランチに直接コミットしてよいか
- 変更内容を誰が確認するか
- 機密情報をどのように扱うか
- トラブル時に誰が対応するか
組織利用では、Gitの技術的な使い方だけでなく、権限管理や情報管理のルールも重要になります。
特にGiteaは、組織内に構築して使うケースがあります。
その場合、GitHubのような外部サービスを使う場合よりも、自分たちで運用ルールを決める範囲が広くなります。
決めるべきルール1：
リポジトリの用途
最初に決めるべきなのは、そのリポジトリを何のために使うかです。
リポジトリとは、ファイルと変更履歴をまとめて管理する場所のことです。
用途が曖昧なままリポジトリを作ると、後から何を入れる場所なのか分からなくなります。
たとえば、次のように用途を決めておきます。
このリポジトリは、社内向け業務ツールのソースコードを管理するために使用する。
設計メモや一時的な作業ファイルは、必要なものだけを整理して保存する。
用途を決めると、入れてよいファイルと入れない方がよいファイルの判断がしやすくなります。
決めるべきルール2：
公開範囲
次に、リポジトリの公開範囲を決めます。
主な選択肢は次の2つです。
- 公開リポジトリ
- 非公開リポジトリ
公開リポジトリは、外部の人も見ることができるリポジトリです。
非公開リポジトリは、許可された人だけが見られるリポジトリです。
個人開発であっても、公開リポジトリにする場合は注意が必要です。
ソースコードだけでなく、コメント、設定ファイル、READMEなども外部から見られる可能性があります。
組織利用では、基本的に非公開を前提にすることが多いです。
特に業務内容、顧客情報、内部手順、認証情報などが含まれる可能性がある場合は、公開範囲を慎重に決める必要があります。
決めるべきルール3：
入れてはいけない情報
GitやGiteaを使う前に、コミットしてはいけない情報を明確にしておく必要があります。
特に注意したいのは次のような情報です。
- パスワード
- APIキー
- アクセストークン
- 個人情報
- 顧客情報
- 社外秘の資料
- 本番環境の設定情報
- 認証情報が含まれるファイル
Gitは履歴を管理する仕組みです。
一度コミットした情報は、後からファイルを削除しても履歴に残ることがあります。
そのため、「間違えて入れたら消せばよい」という考え方は危険です。
機密情報は、最初からGitで管理しないようにします。
よくある対策としては、 .gitignore を使って管理対象外のファイルを指定します。
たとえば、次のようなファイルはGit管理から外すことが多いです。
.env
.env.local
node_modules/
dist/
build/
.gitignore は、Gitで管理しないファイルやフォルダを指定するためのファイルです。
決めるべきルール4：
ブランチの使い方
ブランチとは、作業の流れを分ける仕組みです。
たとえば、安定版の作業と、新機能の作業を分けたいときに使います。
最初は、複雑なブランチ運用にする必要はありません。
初心者や小規模運用では、次のようなルールでも十分です。
main：
公開・本番反映してよい安定版
feature/〇〇：
新機能や大きめの修正作業用
fix/〇〇：
不具合修正用
たとえば、問い合わせフォームを追加する場合は、次のようなブランチ名にします。
feature/add-contact-form
表示崩れを修正する場合は、次のようなブランチ名にします。
fix/header-layout
ブランチ名のルールを決めておくと、何のための作業か分かりやすくなります。
決めるべきルール5：
コミットメッセージ
コミットとは、変更内容を履歴として保存する単位です。
コミットメッセージは、その変更が何をしたものかを説明する文章です。
悪い例としては、次のようなものがあります。
修正
変更
いろいろ対応
作業中
これでは、後から見たときに何をしたのか分かりません。
よい例は、次のようなものです。
問い合わせフォームへのリンクを追加
ヘッダーの表示崩れを修正
READMEに初期設定手順を追加
ログイン画面の文言を修正
大切なのは、未来の自分や他の人が見たときに、変更内容を理解できることです。
組織で使う場合は、コミットメッセージの書き方をある程度そろえるとよいです。
たとえば、次のようなルールです。
追加：〇〇を追加
修正：〇〇を修正
削除：〇〇を削除
整理：〇〇を整理
例：
追加：問い合わせフォームへのリンクを追加
修正：トップページの説明文を修正
整理：不要なコメントを削除
細かすぎるルールは続かないため、最初はこの程度で十分です。
決めるべきルール6：
直接コミットしてよいブランチ
Git運用でよく問題になるのが、重要なブランチに直接コミットしてよいかどうかです。
たとえば、 main ブランチを公開用・本番用として使っている場合、誰でも直接コミットできる状態にすると事故が起きやすくなります。
個人利用であれば、最初は main に直接コミットしても大きな問題はないかもしれません。
しかし、次のような場合は、専用ブランチを作って作業した方が安全です。
- 新機能を追加する
- 複数ファイルを変更する
- 表示や動作に影響がある修正をする
- まだ完成していない作業を保存したい
- 他の人に確認してもらいたい
組織利用では、原則として main への直接コミットは禁止にして、レビュー後に取り込む運用が望ましいです。
決めるべきルール7：
レビューの方法
複数人でGitやGiteaを使う場合は、変更内容を誰が確認するかを決める必要があります。
レビューとは、他の人が変更内容を確認することです。
確認する観点は、たとえば次のようなものです。
- 意図した変更になっているか
- 不要なファイルが含まれていないか
- 機密情報が入っていないか
- 他の機能に悪影響がなさそうか
- コメントや説明が分かりやすいか
Giteaでは、Pull Requestのような仕組みを使って、変更内容を確認してから取り込む運用ができます。
Pull Requestとは、自分の変更を別のブランチに取り込んでもらうための依頼です。
GitHubではPull Request、Giteaでも同様の仕組みが使えます。
組織利用では、少なくとも重要なブランチに取り込む前に、誰かが確認する流れを作っておくと安心です。
決めるべきルール8：
Issueの使い方
Issueとは、作業内容や課題を管理するための仕組みです。
GitHubやGiteaでは、Issueを使って次のような内容を管理できます。
- 不具合
- 改善要望
- 作業予定
- 調査事項
- 質問
- メモ
Issueを使う場合は、何を書く場所なのかを決めておくと混乱を防げます。
たとえば、次のようなルールです。
Issueには、対応すべき作業や確認事項を登録する。
単なる雑談や一時的なメモは登録しない。
作業が完了したらIssueを閉じる。
個人利用でも、Issueは作業メモとして便利です。
ただし、何でもIssueに入れると逆に管理が重くなるため、最初は重要な作業だけで十分です。
決めるべきルール9：
ファイル名・フォルダ名
ファイル名やフォルダ名の付け方も、ある程度そろえておくと後で楽になります。
たとえば、次のような点です。
- 日本語名を使うか
- 英語名を使うか
- スペースを使うか
- 日付を入れるか
- 大文字・小文字をどう扱うか
開発プロジェクトでは、英数字とハイフンを使った名前にしておくと扱いやすいことが多いです。
例：
contact-form.md
app-settings.md
user-guide.md
スペースを含むファイル名は、コマンド操作で扱いにくくなる場合があります。
そのため、ファイル名にはスペースを使わず、ハイフンで区切る運用が無難です。
決めるべきルール10：
トラブル時の対応
Gitでは、作業中に次のようなトラブルが起きることがあります。
- 間違えてファイルを変更した
- 必要なファイルを消した
- コンフリクトが起きた
- 間違ったブランチで作業した
- pushできない
- pullしたら想定外の変更が入った
コンフリクトとは、同じファイルの同じ箇所を複数人が変更した場合などに、Gitが自動で判断できなくなる状態です。
トラブル時のルールとして、次のような方針を決めておくと安全です。
- よく分からない状態で無理にコマンドを実行しない
- まず git status で状態を確認する
- エラーメッセージを記録する
- 組織利用の場合は、管理者や詳しい人に相談する
- --force や --hard は安易に使わない
特に、 git reset --hard や git push --force は強力なコマンドです。
状況によっては変更履歴や他の人の作業に影響するため、初心者のうちは慎重に扱う必要があります。
最初に決めるルールは少なくてよい
ここまで多くの項目を挙げましたが、最初から完璧なルールを作る必要はありません。
むしろ、最初から細かすぎるルールを作ると、運用が重くなります。
最初に決めるなら、次の5つだけでも十分です。
1. リポジトリの用途
2. 公開範囲
3. 入れてはいけない情報
4. ブランチ名の基本ルール
5. コミットメッセージの書き方
この5つを決めておくだけでも、かなり事故を防げます。
最低限のルール例
最後に、個人利用や小規模な組織利用で使いやすい、最低限のルール例をまとめます。
# Git・Gitea運用ルール例
## リポジトリの用途
このリポジトリは、〇〇プロジェクトのソースコードと関連ドキュメントを管理するために使用する。
## 公開範囲
原則として非公開リポジトリとする。
公開する場合は、機密情報や個人情報が含まれていないことを確認する。
## コミットしてはいけない情報
以下の情報はコミットしない。
- パスワード
- APIキー
- アクセストークン
- 個人情報
- 顧客情報
- 本番環境の設定ファイル
- その他、外部に出してはいけない情報
## ブランチ
mainブランチは安定版として扱う。
新機能や大きな修正は、以下のような作業用ブランチを作成する。
- feature/作業内容
- fix/修正内容
## コミットメッセージ
後から見て変更内容が分かるように書く。
例：
- 追加：問い合わせフォームへのリンクを追加
- 修正：トップページの説明文を修正
- 削除：不要な画像ファイルを削除
- 整理：READMEの構成を整理
## 作業前後の確認
作業前後には、必要に応じて以下を確認する。
- git status
- git diff
- git log
## 注意するコマンド
以下のコマンドは影響が大きいため、内容を理解してから使う。
- git reset --hard
- git push --force
- git clean -f
この程度であれば、初心者でも理解しやすく、実際の運用にも使いやすいです。
まとめ
GitやGiteaは、使い始めること自体はそれほど難しくありません。
しかし、ルールを決めずに使い始めると、後から履歴が分かりにくくなったり、重要な情報を誤って管理対象にしてしまったりする可能性があります。
最初に決めるべきことは、難しいブランチ戦略や高度なコマンドではありません。
まずは、次のような基本的なルールを決めることが大切です。
- 何を管理するリポジトリなのか
- 誰が見られるリポジトリなのか
- 何をコミットしてはいけないのか
- どのようにブランチを使うのか
- どのようにコミットメッセージを書くのか
Gitは履歴を残すための道具です。
Giteaは、その履歴をチームや組織で共有・管理するための場所です。
だからこそ、使い始める前に最低限のルールを決めておくと、後の運用がかなり楽になります。
次の第3回では、ここで決めたルールを実際の作業に落とし込むため、よく使うGitコマンドを整理します。
シリーズ記事：
前の記事：Git、Giteaとは
次の記事：Gitの基本的なコマンド