サイドスリーブログ

【Git超初心者入門】Gitの基本的な知識をみにつけよう編


                【Git超初心者入門】Gitの基本的な知識をみにつけよう編

おひさしぶりです、ほーりーです。

最近Gitについてようやく慣れてきたな~と感じたため、記事にまとめてみました。
これからGitを学習される方、Gitの基本的な復習をされたい方のひとつご参考になれば嬉しいです。
読了後、Gitの特徴などの概要をざっくり掴んでいただけるような内容となっております。

Gitってなに

ひとことで表現すると「バージョン管理システム」のひとつです。
バージョン管理とは、ファイルの変更内容や変更履歴を残しておいて、必要な時に辿れたり過去の内容に戻せたりする神ツールです。

Gitはなぜ開発現場で必須技術なのか

現場ではGitの操作スキルが必須になっていたりする場合が多いようです。
重要である理由は、主に下記2点が挙げられます。

  • 編集履歴の管理が簡単になる(過去の編集内容の復元も可能)
  • 複数人で同時開発が可能になる
Gitを使うと管理が簡単になる

複数人で同時開発が可能になるのはなぜ?

なんとなくGitが重要なのはワカッタ!という読者の方がでてきたところで、Gitができた背景について軽く触れてみたいとおもいます。

リーナス・トーバルズ

Gitを作った人:リーナス・トーバルズ

2002年にリーナス氏は、既存のバージョン管理システムが不十分であると感じ、自分自身で分散型のバージョン管理システムを作成しました。

リーナス・トーバルズについての詳細はこちら

分散型のバージョン管理システムとは

リーナス氏はGitを開発するために、分散型の構造を採用しました。
分散型構造のおかげで、開発者それぞれのマシンに完全なリポジトリのコピーを保持することが可能となりました。

※リポジトリとは?について「Gitの仕組み - 重要用語一覧」で説明しています。

コピーを保持できることで、複数の開発者が独立して作業することができ、また、他の開発者との変更をすばやく合わせることができるようになりました。

分散型バージョン管理システムの図
コピーしたリポジトリに対してある程度作業した後に、共同リポジトリへと同期できる。

余談:分散型と対義語である集中型バージョン管理システムの特徴は?

集中型バージョン管理システムの図
共有リポジトリを複数人で作業する。

変更履歴を記録するための共有リポジトリ(=中央リポジトリ)を持ち、複数人でこの1つのリポジトリを扱います。

開発者は常に共有リポジトリと同期する必要があり、変更履歴を追加するには共有リポジトリへの接続が必要です。

しかし、単一リポジトリであることによって開発者全員で同じリポジトリを編集するため、競合が起こりやすくなります。

Gitの重要キーワード

まずは、重要用語をおさえておくことでGitの理解がスムーズとなるため最初におさえておきましょう。

(注)重要用語は下記以外にもたくさんありますが、ここでは個人的に最低限必要と思ったものをピックアップしております。

★Keyword

  • リポジトリ(repository)
    変更履歴やソースコードなどを保存するためのストレージのこと。
  • コミット(commit)
    その時のファイルの状態(修正した内容等)をリポジトリに送ること。
    また、コミットする際に「コミットメッセージ」を付けてファイルの変更点等を分かりやすくします。
    他の開発者にも作業内容が伝わりやすいように、わかりやすく簡潔に書くことがよいです。
  • プッシュ(push)
    コミット内容を共有リポジトリ(=リモートリポジトリ)にアップすること。
  • クローン(clone)
    共有リポジトリ(=リモートリポジトリ)の内容を丸っとローカル環境にコピーすること。
  • マージ(merge)
    各ブランチの内容を1つのブランチにまとめること。

Gitの仕組み

ここからGitのおおまかな仕組みを解説していきます。
普段気を付けて作業をしていても、予期せぬ競合でうまく動作しない場合が多々あります。
仕組み自体をイメージができると、回避策を見つけやすくなるため、ぜひ図解などでつかんでいきましょう!

Gitの流れの図

Gitには大きく4つのエリアがあります。

★4つのエリア

  • リモートリポジトリ
    ネットワーク上のサーバで運用されている共有のリポジトリ。
  • ローカルリポジトリ
    ローカル環境のリポジトリ。
  • ステージング(インデックス)
    ローカルリポジトリへコミットするファイルを一旦保存しておく場所。
  • ワークツリー
    ローカル環境で実際に作業する場所。

Git更新一連の流れの例

  1. ① git clone

    既に動いているプロジェクトにアサインされた際、なにはともあれGitをコピーするところから始まります。
    「git clone リポジトリURL 保存先ディレクトリ」コマンドで保存先を決めてクローンができます。
    $ git clone https://github.com/example/example.git C:\Users\hori\test

    リモートリポジトリから共有リポジトリをPCにクローンした後、クローンしたファイルを修正するとワークツリーのみ差分が生まれた状態となります。
    ためしに、test.htmlを追加してみました。
    「git status」コマンドで、現状のファイルやディレクトリの状態を確認できるため、確認してみましょう。

    $ git status
    Untracked files: (use "git add ..." to include in what will be committed)
    test.html

    Untracked filesとメッセージが出てきました。
    表示されているファイル(今回はtest.html)が変更されている可能性があることを示唆しています。
    それと同時に、変更ファイルをコミットにまだ含めていないという意味も含まれています。

  2. ② git add

    修正が完了したら、ステージングへ移動させます。
    「git add 変更したファイル名」コマンドで、指定したファイルの変更内容がステージングエリアへ追加(移動)されます。

    $ git add test.html

    現状の状態を確認してみましょう。

    $ git status
    Changes to be committed: (use "git restore --staged ..." to unstage)
    new file: test.html

    Changes to be committedというメッセージに変わっています。
    以降のメッセージでは、test.htmlファイルがステージングエリアに追加されたことを示しています。

  3. ③ git commit

    ステージングに移ったところで、ローカルリポジトリへ変更内容を追加します。
    「git commit -m "変更内容を記載"」コマンドで、コミット履歴のメッセージを一緒につけてコミットをします。
    $ git commit -m "gitのテスト"

    現状の状態を確認してみましょう。

    $ nothing to commit, working tree clean

    nothing to commit, working tree cleanというメッセージに変わっています。
    コミットする変更がないことを示しています。つまり、Gitのリポジトリには、まだコミットされていない変更が存在しないことを意味します

  4. ④ git push

    最後に、「git push」コマンドで、リモートリポジトリへとアップされました!
    $ git push

余談:なぜステージングが必要なのか?

ステージングが必要な理由として、ファイルを選別するためにあるといえます。
複数ファイルを編集してしまったが、一部のファイルだけをコミットしたい...!そんな場合は、コミットしたいファイルだけを選別して、ステージに移動して、コミットすることができます。
ステージングのおかげで、コミットしたいファイルを選別することができ、全く関係のない履歴を残してしまうことを防ぐことができますね。

まとめ

いかがだったでしょうか。
今回は実践的な内容よりも、基本的な前提知識の概要がメインでした。

Gitは現場でミスると大変なことになる場合があるため、初めに重要度を知っておいたほうがよい分野ではあります。(体験談)
Gitスキルをガンガン伸ばして快適な開発スタイルを作り上げていきましょう!