Gitについて

Gitは分散型のバージョン管理システムです。

バージョン管理システムは何かしらの成果物（ドキュメントやソースコード）の変化を管理するシステムであり、複数人で作業を進める上で成果物の共有や同期、バックアップを管理するために使用されます。

開発者でなくてもGitの概念と簡単な使い方を学んでおくことで、プロジェクト管理やバージョン管理がスムーズに行えるようになります。

Gitは非常に強力なツールであり、チームでの協力やコードの管理を効率化するために必須と言えるでしょう。まずは基本的なGitの概念を理解し、少しずつ慣れていくことが大切です。そして、定期的に成果物の変化を記録する習慣を身につけることで、プロジェクトの進行状況や変更履歴を確認しやすくなります。

Gitを使うことで、開発効率が向上し、ミスや混乱を防ぐことができます。是非、Gitを活用して効率的な開発を行いましょう。

Gitは分散型のバージョン管理システムですが、中央集権型のバージョン管理システムも存在します。

本ガイドでは、中央集権型のバージョン管理システムには触れませんが分散型との主な違いとして以下の点が挙げられます。

変更履歴を保存する場所の違い
中央集権型のバージョン管理システムでは、中央サーバーに1つだけファイルの変更履歴を保存する場所が存在し、開発者はその中央サーバーからファイルを取得して作業を行います。一方、分散型のバージョン管理システムでは、各開発者がローカルに変更履歴を保存する場所を持ち、必要に応じて中央サーバーから変更履歴を取得し、ローカルで作業を行います。
中央集権型のシステムでは、ネットワーク接続が必須であり、中央サーバにアクセスできない場合は作業ができません。一方、分散型のシステムでは、ローカルに変更履歴が保存されているため、ネットワーク接続がなくても作業が可能です。
中央集権型のシステムでは、すべての開発者がプロジェクトとプロジェクトの履歴の完全なコピーを持たなくてもよいので、ロカールの記憶容量を圧迫しません。

Gitとは

一言で言えば、Gitとはコンテンツの変化を管理するプログラムです。

Gitを扱うときには一般として、GitクライアントとGitサーバーの2つが関わってきます。

また、プロジェクトのすべてのファイル、フォルダ、および各ファイルの変更履歴を含む、Gitプロジェクトの中心的な保管場所のことを「リポジトリ」と呼びます。簡単に言えば、プロジェクトの「倉庫」や「保管庫」のようなものです。

Gitクライアント

自分のコンピューターでローカルリポジトリを操作するシステムのことをGitクライアントと言います。

コマンドラインやGUIツールで操作することができ、ファイルの変更やコピー、変更履歴の検索などその他多くのことを実行します。

Gitサーバー

Gitクライアントを使用してローカルリポジトリに保管した変更などをチームメンバーで共有するためのリモートリポジトリのことを指します。

Gitサーバーに保存された情報がチームメンバーにとって信頼できる正しい情報源になります。

Gitサーバーは自分たちで独自のものをインストールすることも出来ますし、そのような手間を省いてGithub , Gitlab , Bitbucket などの信頼できるクラウドサービスのものを使用することも出来ます。

Gitの特徴

Gitは明示的に命令しなければ何もしない

Gitはローカルリポジトリの変更を自動で記録したりリモートリポジトリに保存された新しい変更を自動でダウンロードしたりはしません。つまり、自分でGitクライアントを操作して明示的にGitに命令を指示する必要があります。

例えば、ローカルリポジトリの特定の時点での状態を保存する（写真のように一瞬を切り取るようなもの）ことをGitの用語ではコミットと呼びます。コミットを保存するためには、コマンドラインでは下記のようになります。

git commit -m 'メッセージがここに入ります'

ブランチングという概念

Gitはメインの保存領域と並行する形で枝を分岐させて作業できるようにして、開発の流れを分岐できる機能があります。これをブランチと言いメインのブランチは一般的に「master」や「main」といった名前が付けられます。

各ブランチは完全に独立しており、他のブランチに影響を与えることなく作業ができます。これにより複数の機能実装やバグの修正を各ブランチで分けて作業することが可能になり、ブランチを切り替えることで作業を途中から始めることも出来るようになります。

Gitの基本的な流れ

ここから以下のような流れでローカルでのGitの基本的なワークフローを学んでいきましょう。

ローカルリポジトリを作成する
Gitを使う前の準備をする
ファイルを変更する
変更を登録（ステージング）する
変更を保存（コミット）する

ローカルリポジトリを作成する

Gitの基本的な使い方の流れを知るために、新しいローカルリポジトリを作り、そのリポジトリで変更を追加してみましょう。

ローカルリポジトリには全く新しいローカルリポジトリを作る方法か、既存のリモートリポジトリのコピーをローカルリポジトリにダウンロードしてくる方法の2通りがあります。またこのリモートリポジトリのコピーをダウンロードしてくる作業のことをGitの用語でクローンと言います。

新しいリポジトリを作る場合でも、既存のリポジトリをクローンしてくる場合でもローカルでする作業は同じです。今回はまだ、リモートリポジトリが存在しないので新しいローカルリポジトリを作成していきます。

git initコマンドを実行することで、ローカルリポジトリを作成できます。

# test-gitというディレクトリを作成
mkdir test-git

# 作成したディレクトリに移動
cd test-git

# 新しいリポジトリを作成
git init

git initコマンドは現在のディレクトリに.gitという隠しディレクトリを作成し、今後するGitの作業がこの.gitというディレクトリの中に保存されていきます。

Gitを使う前の準備

早速Gitを使用していきたいのですが、その前にまず簡単な事前準備を行います。

ローカルリポジトリにコミット（変更を保存）するためには、最低限、自分の名前（ニックネーム）とメールアドレスをGitに知らせてあげる必要があります。この情報はコミットの作者の情報としてコミットの一部として保存されます。こうすることで変更を誰が保存したのかがわかるようになります。

この情報を保存するためにgit configコマンドを使用します。

# 上記で作成したmy-repoディレクトリで作業を進める
git config user.name 'Your Name'
git config user.email 'your-email@***.com'

git config --global user.name 'Yout Name'
git config --global user.email 'your-email@***.com'

ファイルを変更する

それでは早速Gitに変更を登録していきたいのですが、まずはローカルリポジトリ内で何かしらの変更（ファイルの追加や修正）が必要です。

ここまではまだ、Gitリポジトリを作成しただけで、ファイルが無い状態ですので、ローカルリポジトリの直下にindex.htmlというファイルを作成してみましょう。

<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
  </head>
  <body></body>
</html>

変更を登録（ステージング）する

『Gitは明示的に命令しなければ何もしない』というセクションで説明したように、Gitはファイルが追加されたことをまだ知りません。なので明示的にindex.htmlというファイルを追加したことを知らせてあげる必要があります。このGitに変更を知らせる作業をGit用語でステージングすると言います。

ステージングとは、保存前の準備を整えてあげる作業です。この作業はgit addコマンドを使用します。

# index.htmlをステージングする
git add index.html

上記の例では、1つのファイルだけを追加しているのでファイル名を指定してステージングしていますが、複数のファイルを一気にステージングしたいこともあります。その際にいちいち全部のファイル名を指定するのは大変ですので、下記のコマンドを使用することで現在ステージングしていない全てのファイルをステージングすることが可能です。

# すべてのファイルをステージングする
git add .

変更を保存（コミット）する

index.htmlというファイルを追加したことをステージングしたら、次のステップはローカルリポジトリへファイルを追加したことをコミット（保存）します。

コミットする時には、その変化に対してログメッセージを付けます。ログメッセージは、後で特定の変更を見つけるためにコミットを遡って確認する時や、変更の細部を確認せずともどんな変更が行われたか知りたい時にとても役立ちます。

コミットはgit commitコマンドを使用します。

git commit -m 'index.htmlを新規作成'

ここまでで、

リポジトリを作成
事前準備
ファイルを変更する
変更をステージング
変更をコミット

という流れを体験しました。この後は3から5を繰り返していく形になります。

例えば、index.htmlの中身を修正したとしましょう。

<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <!--   Documentというtitleタグの中身を修正   -->
    <title>Git TEST</title>
  </head>
  <body></body>
</html>

修正したあとはステージング→ コミットの流れです。

# 修正をステージング
git add index.html

# 修正をコミット
git commit -m 'titleタグを修正'

このようにステージングとコミットを繰り返してコミット履歴を積み上げていくことでローカルリポジトリの変更を記録していくことになります。

ブランチの操作

今までは意識をしていませんでしたが、ここまでコミットを積み上げてきたのはデフォルトブランチ（通常はmasterかmainブランチ）です。

一般的に、複数人で同じリポジトリで作業をする場合には、デフォルトブランチに直接コミットすることは避けるべきです。なぜなら、コミット履歴が作業単位の順番ではなくコミットした順番になってしまい、履歴が見ずらくなってしまうからです。

そこで特定のブランチから分岐を作ることで自分がしたい開発を他の人に影響を与えることなく進めることが出来ます。分岐させたブランチ内の成果物は他のブランチと統合されるまで全く別のものとして扱われます。

このブランチ機能を使用することで、同じ開発でも別バージョンのものを同時に開発を進めたり、1つのリポジトリ内に複数の異なる開発ラインが共存することができます。

Gitの作業をする上でブランチは日常的に使用するもので、ブランチを多用することは推奨されています。分岐させたブランチ上で、存分に開発を進めたあとに問題がないことを確認してデフォルトブランチやそれと同等なブランチに統合するというのがベストプラクティスとなっています。またこのブランチを統合する操作のことをGit用語でマージすると言います。

それでは、まず自分がどのブランチにいるのかをgit branchコマンドを使用私て確認してみましょう。

# ブランチの一覧を表示する
git branch

git branchコマンドを実行すると下記のような表示が返ってきたかと思います。

* master

masterの左側にある*が現在いるブランチを表しています。例えばこのリポジトリにmaster , css , jsという3つのブランチがあり現在cssブランチにいる場合には下記のような表示になります。

  js
* css
  master

現在、masterというブランチにいることがわかりました。CSSをリポジトリに追加するためにcssというブランチを作成してそのブランチに移動してみようと思います。

ブランチの作成にはgit branchコマンド、ブランチの移動にはgit checkoutコマンドを使用します。

# cssという名前のブランチを作成する
git branch css

# ブランチの一覧をもう一度見てみる
#（cssブランチを作成しただけでmasterブランチにいることを確認）
git branch
  css
* master

# cssブランチに移動する
git checkout css

# ブランチの一覧をもう一度見てみる（cssブランチに移動しているのを確認）
git branch
* css
  master

現在cssブランチに移動したことが確認できたので、cssブランチにコミットをしていきましょう。

style.cssをリポジトリ直下に作成します。

body {
  background-color: orange;
}

追加したstyle.cssをcssブランチにコミットしていきます。

# コミット前に自分がどのブランチにいるのかを確認する
git branch
* css
  master

# cssブランチにいるのを確認したのでステージングとコミットをする
git add style.css
git commit -m 'style.cssを新規作成'

これでcssブランチにはstyle.cssが追加されたことが保存されました。しかしmasterブランチには影響を与えないのでここでmasterブランチに切り替えてしまうとstyle.cssというファイル自体が消えてしまいます。（実際にはcssブランチに保存されているのでブランチを切り替えても問題ありません。）

このように分岐したブランチでは他のブランチに影響を与えることなく開発を進めることが出来ます。

それではこのcssブランチをmasterブランチにマージ（統合）していきましょう。

ブランチをマージするには、マージ元（cssブランチ）とマージ先（masterブランチ）を意識する必要があります。実際の手順は

マージ先（master）のブランチに移動
git merge マージ元コマンドを実行

となります。

# マージ先（master）ブランチに移動
git checkout master

# 自分がどのブランチにいるのかを確認
git branch
  css
* master

# masterブランチにいることが確認できたらマージコマンドを実行する
git merge css

マージコマンドを実行することで、masterブランチにcssブランチで追加したコミットが統合されます。

実際の開発では、それぞれのチーム内でマージ前に他人のレビューが必要だったり、独自のルールがあることが多いです。最初のうちは自分でマージ作業をすることが少ないかもしれませんが、自分が予期していないブランチにコミットしてしまうことは多分に考えられます。まずは自分が今からコミットしようとしているのはどのブランチなのかを確認する癖をつけるましょう。

Gitサーバー（リモートリポジトリ）について

ローカルリポジトリでの作業を終えたら、最後に共有をするためにリモートリポジトリに自分が積み上げたコミットを送信します。

リモートリポジトリにはURLを指定しますが、このURLはGithub上に用意されたサーバーだったり、BitbucketやGitLabなどの他のGitリポジトリホスティングサービスでも構いませんし、ホスティングサービスを使わない自前のサーバーのこともあります。

GitではURLを毎回入力しなくてもよいようにリモートリポジトリには別名を付けることができ、デフォルトのリモートリポジトリの別名は通常、originと呼ばれます。

リモートリポジトリを設定する

それでは、リモートリポジトリを設定してみましょう。

Gitにリモートリポジトリを設定するには、git remote addコマンドを使用します。

git remote add origin リモートURL

このコマンドを実行することで、originという別名でリモートURLをGIt上で扱うことが可能になります。

リモートリポジトリにコミットを送信する際には、ローカルリポジトリとリモートリポジトリとで同期を取る必要があります。

このリモートリポジトリの最新をローカルリポジトリに反映する作業をプルと呼びます。

git pull リモートURL ローカルブランチ名というコマンドを実行することでローカルリポジトリのブランチにリモートリポジトリの最新の状態を反映させることができます。

下記のコマンドではoriginというリモートURLのmasterブランチの最新の状態をダウンロードすることになります。

git pull origin master

リモートリポジトリの該当ブランチの最新の状態をローカルリポジトリの該当ブランチに取り込むことができたら、いよいよ自分が作業したブランチをリモートリポジトリに送信できます。

この送信する作業をプッシュと言います。

プッシュとは、ローカルリポジトリの変更をリモートリポジトリにアップロードする作業です。

リモートリポジトリに変更をプッシュする際には、自分が変更を加えたブランチを指定してプッシュする必要があります。例えば、masterブランチに変更をプッシュする場合には以下のようにコマンドを実行します。

git push origin master

これにより、ローカルリポジトリのmasterブランチにある変更がリモートリポジトリのmasterブランチに反映されます。

プッシュを行う際には、いくつか気をつけるべき点があります。

まず、他の人の作業を誤って上書きしないよう注意が必要です。強制的に自分の変更を押し込むオプション（--force）がありますが、これは他のチームメンバーの努力を台無しにする可能性があるので、極めて慎重に扱うべきです。

次に、大きなファイルや秘密の情報を共有スペースに送らないよう気をつけましょう。大きなファイルを送ると、みんなが作業するのに時間がかかるようになります。また、パスワードなどの大切な情報を誤って共有してしまうと、安全性の問題が起こる可能性があります。

自分の変更を送る前に、その内容をよく確認することも大切です。何を変更したのか、それが本当に共有したいものなのかを見直すことで、間違いや未完成の作業を送ってしまうのを防げます。

最後に、小さな変更を頻繁に共有することをおすすめします。長い間変更を手元に溜め込んでいると、後で他の人の作業と合わせるのが難しくなります。小刻みに共有することで、みんなで円滑に協力して作業を進められます。

これらの点に注意してプッシュをすれば、みんなでスムーズに、そして安全にプロジェクトを進めることができます。

リモートリポジトリを設定していないとプルやプッシュなどのリモートリポジトリと通信するようなコマンドは使用することができません。しかし、リモートリポジトリを設定したあとに実際に接続するには、各Gitホスティングサービスによって設定手順が異なるため、本ガイドでは詳細な手順を割愛しています。実際の設定を行う際は、使用するサービスの公式ドキュメントを参照することをお勧めします。

以上がGitの基本的な使い方とワークフローでした。

Gitは強力なツールですが、その力を十分に活用するには練習と経験が必要です。ここで学んだ基本的な概念や操作（リポジトリの作成、ブランチの使用、コミット、プッシュ、プルなど）は、Gitを使う上での基礎となります。これらの操作を日々の作業の中で繰り返し行うことで、次第にGitの扱いに慣れていくでしょう。

初めは複雑に感じるかもしれませんが、Gitを使いこなすことで、プロジェクトの管理が格段に楽になり、チームでの協働がスムーズになります。エラーを恐れず、積極的にGitを使っていくことが上達への近道です。さらに、オンラインの豊富な資料や、チームメンバーとの知識共有を通じて、徐々にGitの理解を深めていくことができます。