【初心者】Gitの基本、clone〜pushまでの一連の作業・コマンドの備忘録

ミライトデザイン Advent Calendar 2025 19日目の記事になります。

この記事の目的

Gitは、エンジニアとしてチームで開発をする上で必須となるツールです。
未経験からエンジニアになり、初めてチーム開発をしてみて、Gitについての理解が浅かった部分やチーム開発をしてみて意識すべきポイントが自分なりに出てきました。

この記事では、あらためて Git の基礎・使い方や、実際の実務で意識すべきポイントを書こうと思います。

エンジニアを目指している人、Gitを使い慣れていない人の参考になればと思います。

この記事でわかること

• Git, GitHub の違い
• Git の概要
  • バージョン管理
  • バージョン管理の種類
  • バージョン管理のツール、サービス
• Git のメリット
• 実際の使い方 clone ~ push までの一連の流れ

そもそも Git ってなに？ GitHub と何が違うの？

Git を勉強したり、実際に使おうと思った時に、 GitHub と言うキーワードが出てきます。
※人によっては、GitLab や Bitbucket といった単語を聞いたことがあったり実際に使用しているかもしれません。

今回は、Gitの仕組みや基本、使い方などについての説明をする前に「 Git 」「 GitHub(GitLab, BitBucket) 」がどういったものなのかを混乱しないように事前にさくっと説明します。

一言で言うと、 Git はバージョン管理システムのツールのことで、 GitHub は Git をベースにして開発を行いやすくするための Webサービスです。

とりあえず、Git と GitHub は違うものなんだと思ってもらえれば大丈夫です。

バージョン管理

Git を使う上で、 Git の基本的な仕組みや関連する用語を押さえておく必要があります。
まずは、Gitの仕組み「バージョン管理」について解説します。

バージョン管理とは、「いつ」「誰が」「何を変更した」のかという、ファイルやディレクトリの保存・変更・削除などの変更した内容と変更前の状態との差分をバージョン(履歴)として保存管理できる仕組みのことです。

バージョン管理の仕組みについて

バージョン(履歴)を保存管理する際に、「リポジトリ」にバージョン(履歴)が保存されて管理しています。
リポジトリとは、データの貯蔵庫のようなものでバージョン（履歴）の情報を保存できる場所のことです。

バージョン管理の種類について

バージョン管理システム種類として、「集中型」と「分散型」があります。
この種類の違いは、バージョン(履歴)をどのように保存・管理を行うかの違いになります。

バージョン管理の種別	システムの特徴	ツール名
集中型	Webサーバー上にある保存領域のファイルを更新する	Subversion（SVN）, CVS
分散型	各自、個人のパソコン上にリポジトリ(データの貯蔵庫)を持ち、好きなタイミングで好きなリポジトリに同期する	Git, Mercurial, Fossil

集中型は「ひとつのリポジトリ(データの貯蔵庫)に接続して、みんなでファイル管理保存を行う」タイプのバージョン管理システム。
分散型は「各自、個人のパソコン上にリポジトリ(データの貯蔵庫)を持ち、好きなタイミングで好きなリポジトリ(データの保存場所)に同期する」タイプのバージョン管理システムです。

また、バージョン管理のツールが集中型、分散型のそれぞれの種類でツールがあります。
Git は分散型のサービスになります。他にも、 Mercurial、Fossilといったツールがあります。

キーワードや用語がたくさん出てきたので、ここまでのバージョン管理についての内容を絵で整理してみました。

Git のメリット

Git を使うことで、複数人での開発がしやすくなります。
メリットとしては、以下の内容があります。

• 各メンバーのPC内にリポジトリを作り、そこで各自ファイルの変更を同時に行いながら開発をすることができる
• バージョン(履歴)を全員で共有・保存管理ができる
• 現在のファイルの最新バージョン(履歴)が明確になる
• リポジトリ内のファイルに対して、「誰が」「いつ」「何をした」のかが記録として残るので、変更履歴に対しての意図が把握しやすい
• 過去のバージョン(ファイルの変更履歴)にファイルの状態を戻すことができる
• 万が一、１つのリポジトリが使えない状態になってしまっても、それぞれ個人のPCにリポジトリを作成しているので、データのバックアップが行いやすい

Git の構造

Gitの構造として、どのようにバージョン管理を保管管理しているのかというと「リモートリポジトリ」「ローカルリポジトリ」を使用してバージョン管理を行なっています。

全体像を絵にするとこんな感じです。

Git を使って、チームで開発をする際は基本的に以下のステップで開発プロジェクトに Gitを導入します。

1. サーバー上にリモートリポジトリを作成する ( Github , GitLab , BitBucket でリモートリポジトリを作成する)
2. ローカル環境(自分のPC)内にプロジェクトのディレクトリを作成・環境構築をして、リモートリポジトリの最新情報を反映させる
3. 各メンバーのPC内にローカルリポジトリを作成する
4. リモートリポジトリの最新のバージョン状態をローカルリポジトリに反映させる
5. ローカルリポジトリで実装をする
6. ローカルリポジトリの実装の差分と何をしたのかのコメントをリモートリポジトリに反映させる

今回はコードレビューのやり方などは載せないです。

リモートリポジトリ

サーバー上に１つだけあるリポジトリ。
開発をする際のメインとなるリポジトリになります。
開発メンバーの全員がアクセスできて、このリポジトリでローカルリポジトリ(各メンバー)の作業内容を統合して常にプロジェクトの最新バージョンにしていきます。

ローカルリポジトリ

ローカル(主にメンバー自身のPC)での各メンバーが実装を行うための作業用のリポジトリ。
複数人いれば、それぞれ自分のローカル環境でのリポジトリを作成・使用して実装を行います。
実装や変更が終わると、どういった内容を変更したのかわかるようにするコメントと変更差分をリモートリポジトリに反映させます。

ワークツリー

ローカルリポジトリ内での、実際に作業をしているディレクトリのことです。

ステージングエリア

ワークツリー内で実際に作業した内容でリモートリポジトリに反映させたいファイルを一時的に置いておくためのエリアです。
このステージングエリアがあることによって、リモートリポジトリの履歴に反映させたい内容がいきなり保存されることを防いでいます。
また、リモートリポジトに反映させたい履歴を事前に確認することができるので、安全にローカルリポジトリの履歴をリモートリポジトリに反映させることができます。

実務での基本的な Gitの作業手順・使用コマンドについて

今回は、すでにプロジェクトに Git が導入されている状態から参加して、ローカルリポジトリを構築・履歴を作成してリモートリポジトリに反映させるまでの手順を解説をします。

事前にローカル環境で準備すること

まず、前提としてローカル（自分のPC）にプロジェクトを開発するための開発環境や準備を行います。

1. 自分のPC内の好きな場所にプロジェクト用のディレクトリを作成、作成したディレクトリに移動をする

ターミナルで mkdir コマンドを使って、プロジェクトのディレクトリの作成・カレントディレクトリを移動します。

## プロジェクト用のディレクトリを作成
$ mkdir git-project

※git-projectは任意のディレクトリ名をつけます

## プロジェクト用のディレクトリに移動する
$ cd git-project

2. 1で作成したディレクトリに、対象プロジェクトのリモートプロジェクトを ローカルのプロジェクト用ディレクトリに clone をして複製する

対象のリモートリポジトリのURLをコピペして clone コマンドを実行する

## ターミナル上でプロジェクト用のディレクトリにいるかを確認
$ pwd

## プロジェクト用ディレクトリにリモートリポジトリの最新情報を clone する
$ git clone コピペしたurl

clone を実行することで、リモートリポジトリの状態をローカルリポジトリに複製することができました。

基本的なコマンドと流れ

ここからは実際にタスクが振られて、実装を行なってリモートリポジトリに反映させるまでの流れと使用するコマンドを紹介します。

1. リモートリポジトリの最新の履歴をローカルリポジトリに適応させる(git pull)
2. 現在のコミット履歴を確認する(git log)
3. 作業用のブランチを切り、作業ブランチに移動する(git switch)
4. 作業前と作業後の差異を確認する(git diff)
5. 作業内容に問題なければ、作業対象のフォルダを指定してステージングエリアに移動させる(git add)
6. コミットを作成して、ローカルリポジトリに記録する(git commit)
7. 現在のコミット履歴を確認する(git log)
8. ローカルリポジトリに保存された作業内容をリモートリポジトリに反映させる(git push)

1.リモートリポジトリの最新情報をローカルリポジトリに適応させる

$ git pull origin main

• origin リモートリポジトリ(プロジェクトの最新履歴の情報)のこと
• main デフォルトで作成されるブランチ名

上記のようにコマンドを実行すると、リモートリポジトリの main ブランチの最新の履歴を、ローカルリポジトリに反映させることができます。

pull コマンドは、 fetch + merge を同時に実行しているコマンドです

• fetch ：リモートリポジトリの最新履歴の情報をローカルリポジトリに持ってきます（あくまで、情報を持ってくるだけ）
• merge ：現在いるブランチに対して、別のブランチの履歴を取り込み、統合するためのコマンド

2. 現在のコミット履歴を確認する(git log)

$ git log --oneline

• --oneline のオプションをつけると、コミット履歴を1行ずつ簡易的に見やすく表示することができます

リモートリポジトリの最新情報をローカルリポジトリに正しく反映できているか、確認をします。

3. 作業用のブランチを切り、作業ブランチに移動する(git switch)

ブランチとは、 あるコミット(変更の記録)からコミットの流れを分岐させてポインターを指し示すためのものです。

今回の例で言うと、git clone をした時点で main ブランチ がリモートリポジトリにデフォルトで作成をされた上で、ローカルリポジトリにもmain ブランチ が作成されているイメージです。

このブランチを切ることによって、特定のコミット（変更の記録）から新しくコミットを作成をして、そのブランチに移動をすることで新しい機能の開発を複数人で進めることができるようになります。

※イメージはこんな感じ

$ git switch -c ブランチ名

• git switch ブランチ名 だと、指定されたブランチに移動することができる（移動のみ）
• -c のオプションを指定することで、ブランチを作成した上で作成したブランチに移動する

リモートリポジトリの最新情報をローカルリポジトリに正しく反映できているか、確認をします。
問題がなければ、移動したブランチ内で実装をします。

4. 作業前と作業後の差異を確認する(git status, git diff)

$ git status

コマンドを実行すると変更差分のファイルが表示され、どのファイルが変更があったのかを確認することができます。

$ git diff

status コマンドより詳細に変更差分を確認することができます。新しく追加した部分には + の表示、削除した部分などは - で表示がされます。

自分の変更内容があっているか、確認をして問題がなければ次のステップにいきます。

5. 作業対象のフォルダを指定してステージングエリアに移動させる(git add)

$ git add ファイル名

• git add . 全ての変更差異があるファイルをステージングエリアに移動させることができる

リモートリポジトリに反映させたいファイルをステージングエリアに移動をさせます。

6. コミットを作成して、ローカルリポジトリに記録する(git commit)

$ git commit -m '修正内容の概要や詳細を記載する'

コミットメッセージを記載して、コマンドを実行することでローカルリポジトリに変更対象のファイル等の情報を記録します。

commit とは、一言で言うと変更内容をリポジトリ(データの貯蔵庫)に保存する操作のことです。
commit には、以下のようなさまざまな情報が記録されます。

1. コミットハッシュ: コミットを一意に識別するID
2. 親コミット: 直前のコミットのID
3. コミットをした人の情報: コミットをリポジトリに適用した人（名前、メールアドレス、日時）
4. コミットメッセージ: 変更内容を説明するテキスト

ポイントとしては、以下の２つのことがあります。

• コミットには実施の作成・編集・削除したディレクトリやファイルがそのまま記録されているわけではない
• どのコミットも親コミットの情報を必ず持っていること

7. 現在のコミット履歴を確認する(git log)

$ git log --oneline

先ほど、自分で作成をしたコミットの情報が正しく作成をされているか確認をします。

チーム開発で Git を使用すると、ものすごいスピードでリモートリポジトリの最新情報・最新のコミット履歴情報などが変化していきます。(複数人で開発をしているため)

なので、こまめに git log を使って、現在のコミット履歴の情報などを確認、把握をしながら開発をすことで Git でのミスが減ってスムーズに開発を進めていくことに繋がります。

8. ローカルリポジトリに保存された作業内容をリモートリポジトリに反映させる(git push)

$ git push origin ブランチ名

最後に switch コマンドで作成をして、今いる作業用のブランチ名を指定して push コマンドを実行することでリモートリポジトリに新しく反映させたブランチが作成をされて作業内容が反映されます。

ここまでが clone ~ push までの一連の作業手順・コマンドとなります。

最後に

ここまで記事を読んでくださり、ありがとうございます！
もし、記事内で間違った記載等あればご指摘いただけると幸いです。

現場に入ったばっかりのジュニアエンジニアの方、エンジニアを目指して学習の方の参考や学びに少しでも繋がっていたら嬉しいです。一緒に頑張っていきましょう。

次の記事は yukiさんの記事になります！
お楽しみに！