gitについて

■Gitの概要

Gitは、プログラムソースなどの変更履歴を管理する分散型のバージョン管理システムである。
分散型でないバージョン管理システムでは、サーバー上にある1つのリポジトリを利用者が共同で使用していた。このため、利用者が増えると変更内容が衝突したり、整合性を維持することが大変だった。

Gitでは、ローカル環境にもコードの変更履歴を保存(コミット)することができるので、リモートのサーバーに常に接続する必要がない。このため、ネットワークに接続していなくても作業を行うことができる。

GitHubの概要

GitHubは、Gitの仕組みを利用して、世界中の人々が自分の作品(プログラムコードやデザインデータなど)を保存、公開することができるようにしたWebサービスである。
GitHubのようなGitを利用したWebサービスは、他にもBitbucketやBacklogなど複数存在する。


■Gitの基本用語・コマンド理解

ディレクト
どちらもファイルを分類するための容れ物であり、複数のファイルを保管する場所という意味では「ディレクトリ = フォルダ」と考えて問題ない。
一般的にWindowsMacなどのGUIではフォルダと呼ぶことが多い。一方で、UNIXLinuxなどのCUIでは、フォルダという概念がないのでディレクトリと呼ぶことが多い。

リポジトリ
リポジトリとは、ファイルやディレクトリの状態を記録する場所である。保存された状態は、内容の変更履歴として格納されている。変更履歴を管理したいディレクトリをリポジトリの管理下に置くことで、そのディレクトリ内のファイルやディレクトリの変更履歴を記録することができる。

・リモートリポジトリ
専用のサーバに配置して複数人で共有するためのリポジトリである。

・ローカルリポジトリ
ユーザ一人ひとりが利用するために、自分の手元のマシン上に配置するリポジトリである。

・ワークツリー
Gitの管理下に置かれた、実際に作業をしているディレクトリの領域のことをワークツリーと呼ぶ。

・インデックス
インデックスとは、リポジトリにコミットする準備をするための場所のことである。リポジトリとワークツリーの間に存在する。インデックスがなぜ必要か。

・コミット
ファイルやディレクトリの追加・変更を、リポジトリに記録するにはコミットという操作を行う。コミットを実行すると、リポジトリの内では、前回コミットした時の状態から現在の状態までの差分を記録したコミット(またはリビジョン)と呼ばれるものが作成される。

このコミットは、次の図のように時系列順につながった状態でリポジトリに格納されている。このコミットを最新の物から辿ることで、過去の変更履歴やその内容を知ることができるようになっている。

・リビジョン
コミットによって作られる状態の単位のこと。変更セットをコミットするたびに、新しい「リビジョン」がローカルリポジトリに作成される。厳密には異なるが、"バージョン"のようなもの。

・git clone
指定されたディレクトリに元のリポジトリと同じものを複製するコマンドである。例えば、開発現場に新しく入った人がGithubからソースをコピーして来たい時など、cloneコマンドを使うことになる。

・git fetch
リモートリポジトリで更新された最新情報をローカルリポジトリに持ってきてorgin/masterを更新する。

・git pull
リモートリポジトリから最新の変更履歴をダウンロードしてきて、自分のローカルリポジトリにその内容を取り込む。git pullは、git fetchとgit merge origin/masterまでをまとめて行う。

・git diff
作業ツリーに行われた変更の表示をする。

引数に「比較元」を指定できるがもし比較元を指定しない場合は、デフォルトで「インデックス」を比較元とし、 [インデックス] → [作業ツリー] と比較した際の差分を表示する事になる。

・git checkout -b
作業ブランチを切ってそのブランチに移動する

・git merge
https://nullnote.com/web/git/merge_rebase/#merge

・git tag
git tagの使い方まとめ


f:id:wanwan_bowbow_ilovecat:20180716164245j:plain

■git reset , git checkoutでcommitを戻した時の状態の違い

resetを使うと変更した内容や追加したファイルが付いてくるので、現在の状態を保持したまま前のcommitに戻りたい時に使える。checkoutを使うと変更した内容やファイルは付いてこないので、完全に前のcommitの状態を再現したいときに使える。

ただ、resetでも--hardオプションを使えば完全に前のcommitの状態(ファイルが付いてこない状態)を再現できるが、両者には大きな違いがある。

git checkout
指定されたコミットIDのリビジョンに作業ディレクトリ内のファイルが変更される。ブランチは detached HEAD状態となり、この状態ではコミットなどを行ってもリポジトリに保存されない。元のブランチに戻したい場合は、"git checkout [ブランチ名]"とすればいい。

git reset --hard
現在のブランチのまま、指定されたリビジョンに作業ディレクトリ、ステージング環境、HEADが変わるので、もし作業ディレクトリに編集中のファイルがあったという場合にもその情報は失われてしまう。

また、元々のHEADの状態に戻る場合、git reflogを使うかORGI_HEADを使う必要がある。