この記事の目的
GitHubはチーム開発では欠かせないツールです。しかし慣れないうちは色々な用語が出てきて混乱することもあります。今回はそんな人にとってまさに必要な、GitHubの開発でよく使われる用語をまとめていきます！
また用語を解説後、開発中にその用語が登場する順番(それを使用する流れ)を、具体的に確認します。
そして最後に、私が当初感じた2つの疑問とその回答を紹介します。
2つの疑問まで読んでいただけると、チーム開発でGitHubを使う際のイメージがかなり鮮明になることが期待できます。
用語解説
この記事では9個の基本用語を以下の流れでそれぞれ解説していきます
1.何をする？（何をする用語か）
2.なぜ必要？
3.例え
4.具体例
では一つずつ見ていきましょう！
①clone（クローン）
1.何をする？
GitHubに保存されているプロジェクトの内容を、あなたのパソコンにコピーする操作です。このコピーを使って、自分のパソコンでコードを編集できるようになります。
2.なぜ必要？
初めてプロジェクトに参加するときは、まずリモート（GitHub）にあるコードをコピーして手元に持ってくる必要があります。それが「クローン」です。
3.例え
学校の教科書を先生が黒板に書いてくれたとします。それをあなたのノートに書き写す作業が「クローン」です。
4.具体例
プロジェクト「myアプリ」のリポジトリ（プロジェクトのコードが保存されている場所）をクローンする。git cloneコマンドを実行。
git clone https://github.com/username/project-name.git
②Branch（ブランチ）
1.何をする？
メインのコードとは別の「コピー」を作成して、その中で新しい機能を開発したり修正を行います。このコピーを「ブランチ」と呼びます。
2.なぜ必要？
メインのコードを直接変更してしまうと、他の人が使っているコードに影響が出る可能性があります。ブランチを使うことで、独立した作業環境を作れます。
3.例え
先生が宿題のプリントを配ったとき、あなたがコピーを取ってそのコピーに答えを書くイメージです。本物のプリント（メインブランチ）はそのまま。
4.具体例
branchコマンドで、ログインページを追加する作業用のブランチを作成。
checkoutコマンドで作成したブランチに移動。
git branch feature/add-login-page
git checkout feature/add-login-page
③Commit（コミット）
1.何をする？
コードを保存する操作です。ただの「保存」ではなく、何をどう変えたかの履歴を一緒に記録します。後で「いつ、誰が、どんな変更をしたか」を確認できます。
2.なぜ必要？
開発中に何か問題が起きたとき、いつでも過去の状態に戻せます。また、誰がどの部分を変更したのかをチームで共有できます。
3.例え
作文を書いているとき、「今日はここまで」と日付を書いて保存しておくイメージです。その日何を直したか覚えておく感じ。
4.具体例
「ログインフォームを追加しました」というコミットを記録。
git commit -m "Add login form to LoginPage component"
④Push（プッシュ）
1.何をする？
自分のパソコンで保存した変更（コミット）を、GitHubに送る操作です。これをしないと、チームメンバーがあなたの変更を見られません。
2.なぜ必要？
チーム開発では、他の人とコードを共有する必要があります。プッシュをすることで、GitHubのリポジトリにあなたの作業内容が反映されます。
3.例え
ノートに書いた宿題を先生に提出するイメージです。
4.具体例
ログインページの開発をGitHubに反映。
git push origin feature/add-login-page
⑤Pull Request（プルリクエスト）
1.何をする？
自分が作業したブランチの内容をメインのコード（main）に統合してもらうためのお願いを出します。他のメンバーが内容を確認し、問題がなければ統合されます。
2.なぜ必要？
作業内容を確認せずに統合すると、バグやエラーが混ざる可能性があります。プルリクエストはコードを確認するための「提出書類」のようなものです。
3.例え
宿題を提出するときに、「この問題の答えが正しいか先生に確認してもらう」感じ。
4.具体例
GitHub上で、ログインページの作業をメインブランチに統合するプルリクエストを作成。
⑥Merge（マージ）
1.何をする？
プルリクエストが承認された後、作業ブランチ（feature/add-login-page）の変更をメインブランチに統合します。
2.なぜ必要？
チーム全員が同じ最新のコードを使えるようにするため。
3.例え
宿題の答えが確認されて、クラス全員に配られるイメージ。
4.具体例
プルリクエストを承認後、ブランチをマージ。
メインブランチに移動してから、ログインページの作業ブランチをメインにマージする。
git checkout main
git merge feature/add-login-page
⑦Pull（プル）
1.何をする？
他のメンバーがGitHubのメインブランチに追加した変更を、自分のパソコンに反映します。
2.なぜ必要？
メンバー全員が同じ最新のコードを使って作業できるようにするため。
3.例え
クラスメートが新しい情報を教えてくれたら、それを自分のノートに書き写す感じ。
4.具体例
最新のコードを自分のパソコンに取得。
git pull origin main
⑧Conflict（コンフリクト）
1.何をする？
競合が発生した場合、どの変更を採用するかを手動で決めて修正します。
2.なぜ必要？
複数人が同じファイルを変更していると、どちらの変更を採用するかをGitが判断できないため。
3.例え
同じノートに違う人が違う答えを書いてしまった状態。その答えをまとめて正しいものにする感じ。
4.具体例
競合を修正し、再度コミット。
⑨Issue（イシュー）
1.何をする？
バグや機能追加など、やるべきタスクをGitHub上で管理します。
2.なぜ必要？
チーム全員がやるべき作業を把握しやすくするため。
3.例え
学校の「今日の宿題リスト」を全員で共有する感じ。
4.具体例
「ログイン画面でエラーメッセージが出ない」というバグをIssueとして記録。
用語を使用する順番
とりあえずベタ書きするので、一旦読んでみてください。これを読むと上記で学んだ用語の解像度が増すと思います。
**
まずは自分が作業をするためにGitHubをVScodeにcloneします。
そして自分が担当している部分を開発するために、ブランチを作ります。
編集を行った後Commitして、編集履歴をGitHubに残します。
それをPushすることで、GitHubにデータを渡します。
そしてそのデータをPullしてもらいたい、すなわち最新のコードとして反映して欲しいので担当者にPull Requestをします。
Requestを受けた人は、問題がなければMergeして、ブランチで行われた変更をメインに反映します。
Mergeが完了したら、Pull Requestを行った人もMergeした人も、それ以外の開発メンバーもPullを行なって、コードを最新の状態にします。
**
簡潔verでも用語をまとめておきます。
Clone：
- プロジェクトをローカルにコピー（最初のステップ）
Branch:：
- 自分の作業用のブランチを作成
Commit：
- 変更を記録
Push：
- GitHubに変更を送信
Pull Request：
- チームに変更内容をレビューしてもらい、統合をリクエスト
Merge：
- 問題がなければ、変更をメインブランチに統合
Pull：
- チーム全員が最新のコードを取得
私が感じた疑問とその回答
疑問その１
どうせcloneすればコピーした環境で開発できるのだから、わざわざブランチを作る必要なくない？
当初の私は、一度コピーしたものをさらにコピーして使うってなんかまどろっこしくないかという感覚になりました。
結論
ブランチを作成することによって、メインブランチが不完全な状態になりバグが発生するのを防げます。また複数人でパーツごとに分けて開発する場合に、自分の作業内容が他の人のパーツに影響を与えないようにできます。
ブランチの流れをちょっと詳しく解説
1.クローンする
- GitHubにある「プロジェクト全体（リポジトリ）」を、自分のパソコンにコピーします
- ここでコピーされるのは、リポジトリのメインブランチ（
mainやdevelop）とその内容です
GitHub (mainブランチ)
↓ クローン
ローカル (mainブランチ)
2.ブランチを作成
- ローカルで作業用の「別の分岐点」を作成します。これが新しいブランチ（例えば
feature/add-login-page） - 新しいブランチは、最初は
mainブランチの内容と同じ状態です
ローカル
├── main (元のコード)
└── feature/add-login-page (新しい作業用のコピー)
3.ブランチで作業
- 作業はfeature/add-login-pageブランチ内で行い、変更や新機能を追加します
- 変更が完了したら、このブランチを
mainにマージします
つまりブランチを作ったとしても、それはmainブランチの内容と同じなのでcloneした時のものと全く同じ状態のものが別で作成されるわけです。
そのため例えばログイン画面用のブランチで作業する時に、ログイン画面に関係しない部分まで変更を加えてしまうと、そのままマージしてしまった場合mainブランチに思わぬバグが発生する可能性が出てきます。
その問題を防ぐために、ブランチで作業する際は以下の点に注意します。
- ブランチごとの役割を明確にする
- 他の部分には手を触れないよう意識する（ログイン用ブランチならログインに関係しない部分は触らない）
- Pull Request時に変更を確認する（プルリクエストには「このブランチでどのファイルが変更されたか」の一覧が表示されるので、これを確認すれば不要な変更を防げます）
- 変更内容を小さな単位でコミットする（「ログインフォームを追加」や「バリデーションを修正」など、一つの目的だけをコミットします）
疑問その２
私は次の状況を考えました。
Aさんがログイン画面のブランチで修正を加えています。同時にBさんがTOP画面のブランチで修正を加えています。
ここでAさんがプルリクを送り、変更がマージされたとしてください。
その後にBさんがプルリクを送ってもそれはAさんの変更をプルする前のものなので、Aさんの変更に上書きしてしまうわけにはいかないのでマージできません。
そのため、Bさんはこれまで行っていた変更を一度破棄して、一度プルしてから改めて編集を行わなければならなくなります。
このようにブランチで分けて複数人で分担して作業していても、結局このようなプルしてやり直さないといけないという問題が生じて、効率的に作業が行えないのではないか。
結論
そんなことはないです。
AさんとBさんはそれぞれ別のブランチで作業しているため、Aさんの変更をBさんがプルしたとしても、Aさんが作業していた部分だけが反映され、Bさんが現在作業しているブランチの内容は保持,継続されます。
すなわちBさんがプルしたとしても、これまでにBさんが行っていた部分に影響がないということです。
そのためBさんはプルした後に、引き続き途中から担当しているパーツの開発を行うことができるのです。
この点がブランチを作成して開発することの最大のメリットと言えるでしょう。
終わりに
ここまで読んでくださりありがとうございます！
GitHubでのチーム開発でよく使われる用語の意味を把握し、実際の流れのイメージをそこそこ鮮明にイメージできたのではないでしょうか？
GitHubで開発をする際の基本用語が理解できたら、GitFlowを理解しましょう。
GitFlowとはブランチの運用ルールのことです。これがわかればチーム開発のじz準備は概ねOKです！