この記事はProgate Path コミュニティ Advent Calendar 2025(シリーズ2)の6日目の記事です。
はじめに
「はじめてのハッカソン」という、Voltechさん主催の福岡で開催される初心者向けハッカソンに、メンターとして参加させていただくことになりました。
また、Progateさんも初心者歓迎で定期的にハッカソンを開催してくださっています。
そこで、はじめてのチーム開発で知っておきたい、GitとGitHubの基本的な操作を解説する記事を書きます！
こんな方におすすめ
- Gitを使ったことがない人
- はじめてチーム開発を行うために、GitとGitHubの使い方を知りたい人
Gitを使い慣れてる方は、ぜひこちらの記事をお読みいただけるとありがたいです！
15000字くらい書いたので、いいねが欲しいな～
この記事では、初心者向けに分かりやすい解説を意識して、一部内部構造的には正確ではない説明が含まれます
ぜひGit操作に慣れ親しんだ後、上の解説記事で内部のことも知っていただけると幸いです
Gitとは
Gitとは何か、ネット等で調べるとこのように書いてあるかと思います。
Gitは、分散型バージョン管理システムの１つである
「分散型」は各々のローカル環境で分散して作業ができることを指すと考えてよいです。
一か所だけにデータが置いてある(集中型)のではなく、各々が全てのデータを持っているという状態です。
「バージョン管理システム」はファイルの変更履歴を保存するものです。
具体的には、「いつ・誰が・どの部分を編集したか」を管理すると思ってよいです。
Gitを使うことで、チームの共同作業を効率的に進めることができます。
ローカル操作
Gitで管理する準備
リポジトリのセットアップ
Gitで管理をするときは、まずは「Gitのリポジトリ」を作ります。
ローカルで新規のリポジトリを作るときは
# ブランチ名をmainにする
$ git init --initial-branch main
を実行します。
チームで誰かが作ったリポジトリがリモート(GitHubなど)に置いてある場合は、
$ git clone <url>
を実行することで、リモートリポジトリをローカルにコピーすることができます。
リモートとローカルの連携について、詳細は後述します！
ls -aコマンドを使うと、.gitディレクトリがあることを確認できると思います。
ファイルを編集し、gitコマンドを操作すると、.gitディレクトリに記録されていきます。
git configの設定
Gitは「いつ・誰が・どの部分を編集したか」を管理する
このうち、「誰が」の部分は、事前に設定する必要があります。
通常、ユーザー名とメールアドレスを設定します。
# ユーザー名の設定
$ git config --global user.name warisuno
# メールアドレスの設定
$ git config --global user.email warisuno@example.com
--globalは、ユーザー全体に対するGitの設定です
このリポジトリのみで設定したいときは、--localに変えて実行してください
git configで、エディタの設定も可能です。
コミット時に、デフォルトでVimというエディタが開く場合が多いですが、慣れていない方はVS Codeに変更することができるので、不安な方は実行しておきましょう。
$ git config --global core.editor 'code --wait'
Vimについて知りたい方は、ぜひProgateコミュニティ運営部のthirdlfさんの記事を参照してみてください。
おかげさまでVimにハマりつつあります
ブランチの移動・作成
チーム開発では、並行作業を行いたいこともあると思います。
このような並行作業をする時に、Gitにはブランチという便利な機能があります。
作業に応じたブランチを切ることで、このようなメリットがあります。
- 作業を互いに干渉せず行うことができる
- 作業をプロジェクト本体に影響を与えずに行うことができる
- 同時に並行して作業を行うことができる
今どのブランチで作業しているかと、ブランチ一覧はこのコマンドで確認できます。
$ git branch
今いるブランチから、新規ブランチを作成するときは、このようにコマンドを実行します。
$ git checkout -b <ブランチ名>
ブランチを作成することを、よく「ブランチを切る」と言います
ブランチは、{prefix}/{変更内容}のような形式で命名することが多いです
例えば、
feature/deploy-to-awsfix/top-page-layout
のように、その名前でどのような変更を行っているブランチかが分かるとよいですね
ブランチを移動するときは、このコマンドを実行します。
$ git checkout <ブランチ名>
最近はgit checkoutではなく、新しめのコマンドgit switchを使用する方も多いようです
プロジェクトの本体をmainブランチで管理している場合は、mainブランチで作業を行うのではなく、mainブランチから作業ブランチを作成して、そこで作業を行います。
これをコマンド操作で書くと、
# mainブランチに移動
$ git checkout main
# 今いるブランチから、新規ブランチfeature/aを作成し、移動
$ git checkout -b feature/a
これで作業の準備が整いました！
コミット
Gitでは、作業内容を記録することを「コミット」といいます。
コミットするまでには、3つのステップを踏みます。
- 実際にファイルを編集する
- コミットする変更を、ステージングエリアに追加する
- ステージングエリアにある変更を、実際にコミットする
まずは、ファイルを編集しましょう。
編集した内容を記録したいと思ったら、変更をステージングエリアに加えます。
$ git add <ファイルのパス>
例えばsrc/main.pyのファイルを編集して、変更をステージングエリアに加えるときには、以下の方法などでコマンドを実行します。
# 直接ファイルパスを指定
$ git add src/main.py
# ディレクトリを指定して、その中のファイルで変更があるものを追加
$ git add src/
# カレントディレクトリを指定する（自分はこれをよく使います）
$ git add .
そして、ステージングエリアにある変更をコミットします。
Gitでは、メッセージと共に記録します。(コミットメッセージといいます)
$ git commit -m <コミットメッセージ>
コミットメッセージに行った変更内容を記録しておくと、チームメンバーが確認しやすいですね
APIキーなど、機密情報を記録しないように必ず確認しましょう
.gitignoreというファイルにGit管理したくないファイルパスを記載し、Git管理から除外することができます
マージ
他のブランチでの変更を、特定のブランチに反映させることを「マージ」と言います。
必要な変更を作業ブランチで行った後に、mainブランチにマージして本体に反映させることができます。
# 反映(マージ)先のブランチに移動する
$ git checkout main
# feature/aをマージするには
$ git merge feature/a
# 場合によってはコミットメッセージを入力するエディタが開きますが、そのまま閉じて問題ないです
# マージ完了！
マージ先と元で同じ場所に違う変更があると、マージ時にコンフリクト（競合）が発生します
今回は基本操作に絞っているため省略しますが、よく聞く用語です。
今は言葉だけ覚えておき、実際に発生したら解決方法を調べてみましょう！
コンフリクト発生時のVS Codeの画面
チーム開発で、本体にリリースするときには、「プルリクエスト」という機能を通してマージすることが多いです。
プルリクエストについては後述します！
GitHubを使ったチーム開発
リモートとローカルの連携
ローカルでのセットアップ
Gitを使ってファイル管理をし、チームで共同作業をするときには、
- GitHubなどのリモートでファイルを共有する
- 作業は各々のローカルで行う
という形になります。今まで説明したブランチ作成やコミットは、ローカルで行う作業です。
このようなローカルで行った作業をリモートに共有することができ、チームメンバーはリモートから作業内容を同期することができます。
リモートの設定は、以下のコマンドで実行します。
# リモートリポジトリをローカルにコピーする場合
$ git clone <url>
# GitHubなどリモートで用意した空のリポジトリに、ローカルを紐づける場合
$ git remote add origin <url>
リモートリポジトリには、デフォルトではoriginという名前がついています。
リモートブランチの一覧は、git branchにオプションをつけて確認することができます。
# リモートブランチ一覧を表示
$ git branch -r
# ローカルとリモート合わせたブランチ一覧
$ git branch -a
例えばorigin/developというブランチであれば、リモート(origin)のmainブランチの状態を保管しています。これはgit checkoutで参照できます。
# ローカルにdevelopという名前のブランチがなければ
# origin/developを参照するdevelopブランチを作成し、移動する
$ git checkout develop
プッシュとプル
リモートに更新された内容は、このコマンドで取得することができます。
$ git fetch
取得した情報は、リモートブランチorigin/mainなどに反映されます。ここで取得した更新内容をローカルのmainに反映させるには、マージを実行します。
$ git checkout main
$ git merge origin/main
fetchとmergeを一度に行うのが、pullコマンドです。
$ git checkout main
$ git pull origin main
これらの操作で、チームメンバーが行った作業を自分のローカルに取り込むことができます。
pullやmergeで取り込む際は、今どのブランチにいるのかを確認してから実行しましょう
逆に、自分の作業ブランチをリモートに反映させるには、このコマンドを実行します。
$ git push -u origin feature/a
pushは指定したブランチをローカルからリモートに反映させるコマンドなので、別のブランチにいる状態で実行しても問題ないです
一度-uオプションをつけて実行しておくと、以降のpushとpullは、コマンドを省略して
# git push -u origin feature/a を省略して
$ git push
# git pull origin feature/a を省略して
$ git pull
で実行することができます
このpullとpushを適宜使用することで、チーム開発時に自分の作業内容を共有することや、他の人の作業内容を取り込むことができます。
プルリクエスト
GitHubなどで、行った変更のレビューとマージを依頼する機能を「プルリクエスト」といいます。
mainブランチなど、本番環境へ反映させる前に、チームで確認を行うというイメージです。
このようにタイトルと概要を書いてプルリクエストを作成し、チームメンバーにレビュー・マージを依頼します。
チームメンバーはレビューを通して確認、場合によっては修正を依頼します。
問題なければ、GitHub上でマージを実行します。
まとめ
作業の一連の流れ
大まかな作業の流れとしては、以下のようになるかなと思います。
# mainを最新状態にして、新規の作業ブランチを作る
$ git checkout main
$ git pull origin main
$ git checkout -b feature/advent-calendar
# ファイルを編集し終わったら
$ git add .
$ git commit -m "feat: アドベントカレンダーの記事を書く"
# リモートに反映する
$ git push -u origin feature/advent-calendar
# GitHub上でプルリクエストを作成する -> マージされれば作業内容がmainに反映される
今の状態を確認する
git statusを実行すると、今の状態を確認することができます。
$ git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: hello.txt
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: test.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
new_file.txt
git add .のようにカレントディレクトリで指定すると、時々addし忘れや、不要なファイルをaddしてしまうことも起こり得ます。
確認したいときには、git statusを活用しましょう。
あとがき
私がエンジニア業務を始めた当初は、Gitコマンドに自信がなかったため、一連の流れで書いたようなメモを見ながら実行をしていた記憶があります。
チーム開発を通して必要なコマンドに触れながら、徐々にGit操作に慣れていくのが良いかと思います。
この記事がその手助けになっていれば幸いです。