エンジニア入門者向け！GitとGithubでバージョン管理する流れ

Git

GitHub

最終更新日 2023/08/22

エンジニアにとって、必須スキルとして知られるソースコードのバージョン管理システムであるGitや、Gitで使われる有名ツールであるGithubの使い方をステップバイステップ形式で紹介します。

このガイドは、バージョン管理と共同コーディングの基本を把握するために初心者向けとして書かれています。
中級者〜上級者向けではなく、これからGitを使い始める入門者向けですのでご注意ください。

GitとGitHubでバージョン管理を始める

プログラミングの世界に足を踏み入れたとき、バージョン管理を理解・実践することは非常に重要な第一歩となります。
GitとGitHubを使いこなすことで、作業効率が上がるだけでなく共同作業の機会も大きく広がります。

このチュートリアルは、GitとGitHubの基礎からリポジトリやブランチの操作までを理解する足がかりとなるような内容になっています。

GitとGitHubの価値を理解する

Gitは非常に強力なツールであり、数え切れないほどのプロジェクトのバックボーンとして機能しています。

Gitを使えば、変更点を追跡したり異なるバージョンのコードを作成したりすることによってコード履歴を簡単に操作できます。
一方、GitHubはGitの力を利用してコラボレーションとコード共有のための空間を提供するプラットフォームです。GitHubでGitリポジトリをホストすることで、単にコードを保存するだけでなく、世界中の開発者からコラボレーション、フィードバック、改善の機会を得ることができます。

バージョン管理システムとは

Gitのようなバージョ管理システムを使えば、手作業でファイルをコピーしたり、コードの改変を恐れたりすることがなくなります。

Gitはタイムマシンのようなもので、プロジェクトの異なるバージョンを行き来でき、実験のためのセーフティネットを提供します。
また、GitHubと組み合わせることでシームレスな同時開発が可能になります。

Git / GitHub 基本編

ここから、GitとGithubについて細かく紹介していきます。

Gitとは

Gitはファイルの変更内容を記録する分散型バージョン管理システムです。

Gitは作業を保存するたびにファイルのスナップショットを作成し、このスナップショットへの参照を保存します。ファイルに変更がなければ、Gitはそのファイルを保存することはなく、すでに保存されている以前の同じファイルへのリンクだけを保存します。

この効率的なアプローチにより、Gitはファイル群（特にソースコード）の変更を管理・追跡するための非常に有能で柔軟なツールとなっています。

GitHubとは

GitHubはファイルの変更を追跡し、複数の人々の間で作業を調整するためにGitの機能を使用するオンラインプラットフォームです。
Gitリポジトリのハブ（中心や中核の意）であり、開発者がプロジェクトで共同作業したり、他の人に貢献したりできます。

Gitがコマンドラインツールであるのに対し、GitHubはWebベースのインターフェースを提供しています。
Gitの機能を拡張し、アクセス制御、タスク管理、他のサービスとの統合などの機能を追加されているため、多くの企業やプロジェクトで利用されています。

GitとGitHubの主要用語

GitとGitHubを使い始める際にはいくつかの重要な用語に慣れておく必要があります。

リポジトリ(repository/repo): ソースコードなどが保存されるディレクトリやストレージスペースのこと。コンピュータのローカルであったり、GitHubのようなリモートサーバーであったりすることがあります。
コミット(commit): コミットするとその時点のリポジトリの「スナップショット」が作成すること。コードを再読み込みしたり、以前の状態に戻したりするためのチェックポイントとなります。
ブランチ(branch): リポジトリのバージョン。リポジトリ内に含まれますが、作業ブランチはメインブランチには影響しないため、主流となるメインプロジェクトを中断することなく自由に作業する目的で使われます。
フォーク(folk): あるユーザーのGitHubアカウントから別のユーザーへリポジトリのコピーを作成するプロセスのこと。これにより、元のプロジェクトに影響を与えることなく自由に変更を試すことができるようになります。
マージ(merge): 履歴を取り込むためのコマンド。ソースブランチの内容をターゲットブランチと統合できるのです。
プルリクエスト(PR): メインプロジェクトに変更を提案すること。ソースコードのレビュアーは変更を確認し、承認または拒否できます。

入門編 Gitのインストールとセットアップ

Gitを使い始めるにはコンピュータにインストールする必要があります。
OSに関係なく公式WebサイトからGitをダウンロードできます。Gitのインストールに成功したら、ターミナル（Windowsではコマンドプロンプト）を開き、gitと入力してインストールが成功したことを確認します。
Gitの一般的なコマンドのリストが表示され、セットアップが成功したことを示すはずです。

$ git

別のGitのインストール方法

Gitは様々なOSにインストールできます。

Windowsユーザーの場合はGitの公式WebサイトからGitをダウンロードし、インストールウィザードに従うことができます。
MacOSユーザーはHomebrew（brew install git）を、Linuxユーザーはパッケージ管理システムを使ってGitをインストールできます。（例えばUbuntuユーザーはターミナルにsudo apt-get install gitと入力します）

# MacOS
$ brew install git

# Ubuntu
$ sudo apt-get install git

初期セットアップ

Gitをインストールしたら、すべてのローカルリポジトリで使用するユーザー情報を設定することが重要です。

ターミナルを開き、以下のコマンドでユーザー名とメールアドレスを設定します。
Your Nameと[email protected]を実際の名前とメールアドレスに置き換えることを忘れないでください。これらの情報は、あなたが行うすべてのコミットに関連付けられます。

$ git config --global user.name "Your Name"
$ git config --global user.email "[email protected]"

これにより個人情報が設定されます。設定した内容はgit config --listでGitの設定を表示することで確認できます。

$ git config --list

はじめてのリポジトリ作成

Gitをインストールしてセットアップした後の最初のステップはリポジトリを作成することです。
これは今から学ぶGitプロジェクトの中心となります。

リポジトリ（略してrepoとも呼ばれます）とは、コードファイルを保存・管理・追跡するためのディレクトリやストレージスペースのことです。新しいリポジトリを作成するにはターミナルを使ってプロジェクトのディレクトリに移動し、git initコマンドで新しいGitリポジトリを初期化します。

これにより、新しいリポジトリに必要なすべてのメタデータを含む.gitという名前のサブディレクトリが作成されます。このメタデータには、オブジェクト、ref/heads、ref/tags、テンプレートファイル用のサブディレクトリが含まれています。

$ cd /path/to/your/project # バージョン管理したいディレクトリへ移動
$ git init
Initialized empty Git repository in /path/to/your/project/.git/

add, commit, pushで変更履歴を作成する

Gitの基本的なサイクルには、変更を加え、コミットすることが含まれます。

まず、作業ディレクトリにあるファイルへ変更を加えます。
変更の保存を準備する（「ステージする」とも言います）ために、git addコマンドを使います。これは、次のコミットで最新の変更を取り込みたいことをGitに伝えるものです。そして、git commitでステージされた変更を保存します。

$ echo "サンプルファイルです。" > sample_file.txt # ファイルの変更例
$ git add .
$ git commit -m "コメントを残せます。例（初めてのコミット）"

プッシュとはコミットした変更をGitHubなどのリモートリポジトリに送信することを指します。これには、git pushコマンドを使用します。
以下のコマンドで可能ですが、ここではリモートリポジトリを設定していないためエラーが出ます。

$ git push origin master
# リモートリポジトリを設定していないため以下のエラーが出ます。
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

コミットのHEADとは

コミットを利用していると、しばしば"HEAD"という言葉が出てきます。
Gitにおいて、HEADは現在チェックアウトされているブランチの最後のコミットへの参照となります。基本的にプロジェクトの最新のスナップショットへの参照を意味するものであり、最後のコミット以降にあなたが行った変更をGitに知らせる機能があります。
コミットを実行すると、"HEAD"はその新しいコミットに移動します。

ほとんどの場合、"HEAD"は現在のブランチの先端 (最新のコミット) を指しています。
しかし、前のコミットをチェックアウトすることで"HEAD"は最新のコミットではなく、チェックアウト先のコミットを指すように移動できます。

さらに、"HEAD"は「切り離された状態」になることもあります。
これはブランチの最新コミットでないコミットをチェックアウトしたときに起こります。HEADが切り離された状態では、HEADはチェックアウトしたブランチの最新コミットを指しているのではなく、コミットを直接指している状態です。
"HEAD"が切り離された状態でコミットを行うと、Gitは新しい識別子を持つ新しいコミットを作成し、それを指すブランチを残しません。この時点で別のブランチをチェックアウトすると、そのコミットは参照がなくなるため消えてしまいます。

Gitのライフサイクル

Gitのライフサイクルは4つのステージで構成されています。

Untracked, Modified, Staged, Committedです。
未追跡（Untracked）のファイルとはGitがまだ認識したことのない新しいファイルのことです。ファイルを編集すると、Gitはそれを修正されたもの（Modified）として認識します。
そして、git addコマンドを使用してこれらの変更をステージします（Staged）。
最後に、変更のスナップショットをプロジェクト履歴へ保存するために、git commitを使って変更をコミットします（Committed）。

このライフサイクルを理解することはGitでバージョン管理を効果的に行うために不可欠です。

$ git status  # Gitにおけるファイルの状態を確認
$ git add .   # 変更をステージする
$ git commit -m "コメント"  # 変更をコミット

GitHubで共同作業

GitHubはGitのバージョン管理機能を強化し、開発者がGitリポジトリをホストして他の人と共同作業できるWebベースのプラットフォームを提供しています。

さらに、GitHubを使えばオープンソースプロジェクトに簡単に貢献できますし、どこにいてもチームと一緒に作業できます。また、バグ追跡、機能リクエスト、タスク管理、Wikiなどの機能があるチーム開発に欠かせないツールです。

GitHubでは、アカウントを作成、またはリポジトリを作成・参加することから始めます。
GitHubの一般的なワークフローは、ブランチに変更をコミットし、議論のためにプルリクエストを開き、全員が変更に同意したらプルリクエストをマージするという流れです。

Githubアカウント作成はこちらから

最初のGitHubリポジトリを作成する

GitHubのリポジトリはプロジェクトの作業をホストし、コラボレーションとバージョン管理を可能にします。
GitHubで新しいリポジトリを作成するには、どのページでも右上にある「+」アイコンをクリックし"New repository"を選択します。リポジトリの名前、簡単な説明、公開または非公開を選択し、必要であればREADMEファイルを作成して初期化します。

以下は例です。

Repository name: my-first-repo
Description: これは最初のリポジトリです。
Public/Private: Private
Initialize this repository with a README: チェックしない

そして"Create repository"をクリックすれば完了です。

リモートリポジトリとして登録

先ほど、pushの際にリモートリポジトリが登録されていないためエラーが出ましたが、自身のリポジトリを作成したタイミングで登録しておきましょう。
以下のコマンドでリモートリポジトリを登録できます。

# もしkt2763というユーザー名でmy-first-repoを作成したら
# https://github.com/kt2763/my-first-repo.git となる
$ git remote add origin https://github.com/自分のユーザー名/リポジトリ名.git

clonse, folk, pull requestを使って共同作業

GitHubのコラボレーションは、clone, folk, pull requestの作成という3つの主要なアクションで成り立っています。

リポジトリのクローンを作成すると自分のマシンにローカルコピーが作成され、オリジナルに影響を与えることなくプロジェクトに取り組むことができるようになります。

# これは運営者の田邉のPython遊び場用で作成したリポジトリです。ご自由にお使いください。
$ git clone https://github.com/kt2763/python-playground.git

一方、folkはGitHubのアカウントにリポジトリのコピーを作成します。
これにより、元のプロジェクトに影響を与えることなく、自由に変更点を試すことができます。変更を加え、それを共有する準備ができたらプルリクエストを作成します。元のリポジトリの所有者にあなたの変更が通知され、所有者は変更を確認し、承認されればマージできます。

folkはGithubの画面右上のほうにある以下のボタンから可能です。

# フォークかクローンした後、自分で変更をするためにブランチを作成
$ git checkout -b your-branch-name # your-branch-nameというブランチを作成するコマンド

# add, commit, pushする
$ git add .
$ git commit -m "変更したよ！"
$ git push origin your-branch-name

変更をプッシュした後、元のリポジトリに移動しNew pull requestをクリックすることでpull request（通称PR）を作成できます。

ブランチとマージを理解する

ブランチはGitの中核的な機能で、メインのプロジェクトに影響を与えることなくリポジトリの異なるバージョンを同時に作業できます。
git branch branch-nameでブランチを作成し、git checkout branch-nameでそのブランチに切り替えます。ブランチで変更を加えた後、それをメインブランチにマージできます。

# git checkout -b new-featureの場合はブランチ作成とcheckoutを同時に行います
$ git branch new-feature
$ git checkout new-feature
# 〜〜何か変更を加える〜〜
# 〜〜add, commitの流れ〜〜
$ git checkout main
$ git merge new-feature

マージはあるブランチの変更を別のブランチに統合することです。
その機能の作業が終わったら、機能ブランチの変更をメインブランチにマージするのが一般的なやり方です。

次のステップ

ここまで、GitとGithubの基礎を紹介しました。
この基本の流れはエンジニアを続ける限り、頻繁に利用するのでぜひしっかり身につけてください。

Gitを使い続けていると「こういうときどうしたらいいの？」という事態にしばしば遭遇します。
そういった際のテクニックを次回のコンテンツでまとめているので、慣れてきたら参照してみてください。

Gitをもっと便利に！エンジニア中級者向けgitのテクニック