【Git】オレならこう説明する！Git初心者への用語説明

[初心者なりのGitの記事](https://qiita.com/nnahito/items/565f8755e70c51532459)を書いて半年経ちました。
意外とQiitaで人気だったので、あれから成長した私がまた記事を書きます。

**オレならこう説明する！Git初心者への用語説明**



# はじめに
「勝利にコミットせよ！」「結果にコミットせよ！」
……は？
何を言ってるかさっぱりわかりません。
コミットって何？つーかコミットって日本語で言うと何？言ってみろよ！！！
そんなアナタに送ります。
Git用語入門！

苦情は一切受け付けません！！！！



# バージョン管理とは？
GitHubなどを「バージョン管理システム」とよく説明があります。
いや、それはわかる。でもバージョン管理ってなんやねん！！

↓　これです

![download.jpg](https://qiita-image-store.s3.amazonaws.com/0/63338/9a1393a5-e8bf-4e90-9539-9e733d0352b6.jpeg)

はい、過去の私の開発物です。
過去のデータをこんな感じでフォルダに分けて保存しているとかなり不便です。
でもバージョン管理システムがやってくれているのはこういうことなんです。


他にも、複数人で開発を行っている時に、適当にフォルダ分けされて適当に突っ込まれたら、
もう何が何かわかりませんよね？

![download.png](https://qiita-image-store.s3.amazonaws.com/0/63338/0d0089c1-8a60-6d7e-85e3-cf57220e8070.png)

バージョン管理システムはそれをキレイに管理してくれるんです。
ちょっと便利に思えてきました？

ここまでまとめると、

- ファイルの変更（更新）を自動で管理してくれる
- だれが、いつ、どこを変更したかを記録してくれる
- 過去の状態にすぐに戻すことができる



# バージョン管理の用語

な～んでわざわざ難しい言葉を使うんですかね？意識高いんですかね？
そんな用語をできるだけ身近な言葉に置き換えて説明していきます。
全てはニュアンスでなんとかなる！！

あ、後、コマンドなんて使わなくても[SourceTree](https://ja.atlassian.com/software/sourcetree)という無料ツールで、GUIでバージョン管理システムを動かす事ができるので興味があればどうぞ。


## GitとGitHub
違いなんなの？ねえ、違いなんなの？

はい。
Gitはバージョン管理システムの仕組みです。
GitHubは、Gitの仕組みを使って動いているサービス名です。
このサービスはGitHubの他に、BitBucketやGitBucketなどがあります。


## リポジトリ
その作品の入っているフォルダの一番上のことです。

![download.png](https://qiita-image-store.s3.amazonaws.com/0/63338/f2ca6ab0-18d5-db42-7ba6-fcae6a3d824d.png)

上の図で言うと、「作品A」「作品B」「作品C」というフォルダがそれぞれリポジトリになります。
その中に作られるすべてのフォルダ、ファイルがバージョン管理の対象になります。
ちなみにGitHubなどでは、リポジトリに「.git」というフォルダが作成されます。


また、リポジトリには以下の2種類あります。

- ローカルリポジトリ
- リモートリポジトリ

ローカルリポジトリは、アナタのPC上に作られるものです。
リモートリポジトリは、GitHub、BitBucket、GitBucketなどのWebサービス上に作られるものです。

ローカルリポジトリだけでもバージョン管理はできますが、バックアップや共同制作のためにリモートリポジトリに、
自分のローカルリポジトリをコピー（アップロード）することが多いです。
このローカルリポジトリをリモートリポジトリにアップロードすることを「プッシュ」と言います。（あとでもう一回説明します）



## クローン（clone）
![download.jpg](https://qiita-image-store.s3.amazonaws.com/0/63338/8ec239c1-bc25-1f63-0bc5-73d016634203.jpeg)
もうこれは一言。
**ダウンロード**です。

あえて用語を使うと、リモートリポジトリを、ローカルリポジトリとして保存します。
それだけです。
まあ、ダウンロードしてんだなーと思ってください。



## インデックス（index）
![download.jpg](https://qiita-image-store.s3.amazonaws.com/0/63338/b0501fa7-18fc-dd1f-bc69-c05ccc63e0a6.jpeg)

アナタが以前の状態からどれだけファイルを編集したかを記録しています。
その変更点を記録しているもののまとめです。


## コミット(commit)
![download.jpg](https://qiita-image-store.s3.amazonaws.com/0/63338/bef515ab-96be-5c86-51e1-bb201f541dd1.jpeg)

おそらく一番聞き馴染みのある言葉でしょうか？
ただし、gitでのコミットの意味は、

「ローカルリポジトリにファイルを保存する」

という意味です。
別にコミットしたところで痩せません。

インデックスとの違いですが、
インデックスはファイルの「変更点」だけを保存します。
コミットは、その変更点と一緒に、ファイルを保存するという感じです。

まあ、ざっくりいうと、
「どこどこを変更したよ」というファイルと、「その変更したファイル」を分けて保存しているイメージですね。


## プッシュ（push）
![download.jpg](https://qiita-image-store.s3.amazonaws.com/0/63338/6554f6bf-6fc7-bda2-e582-049f7505456d.jpeg)

リモートリポジトリ（サーバ上のやつ）に、
ローカルリポジトリ（アナタのPCのフォルダ全体）を送信して保存します。
アップロードです！アップロード！！

この時、誰かと編集しているファイルがかぶったりすると、怒られます。
その怒られることを、「コンフリクト（競合）」といいます。


## プル（pull）
![download.jpg](https://qiita-image-store.s3.amazonaws.com/0/63338/2157bc1f-e84e-8c89-e145-d3d1e4c8a746.jpeg)

リモートリポジトリ（サーバ上のフォルダ）のうち、
ローカルリポジトリ（アナタのPCのフォルダ）に無いものとか誰かが更新したものをダウンロードしてきます。

クローンとの違いは、全部ごそっとダウンロードしてくるのと、持っていないものだけを持ってくるのの違いですね。
（クローンはリモートリポジトリをローカルリポジトリとして持ってくることですが、そんなことわかってる人がこんな記事読んでもしかたないので、ツッコミは来ないはず。）

ちなみに、サーバー上にあるファイルをローカルでも編集していて、
それをプッシュ（サーバにアップロード）せずにプルしようとすると怒られます。


## フェッチ（fetch）
![download.jpg](https://qiita-image-store.s3.amazonaws.com/0/63338/1a6cf8cb-2991-7a77-187a-7c4983a14688.jpeg)

リモートリポジトリ（サーバー上のフォルダ）に、更新がないかを確認します。

「プルでいいじゃん！」と思いますが、もし自分が編集中のものが更新されていた場合エラーが出ますよね？
それが回避できます。
もし、コンフリクト（他人と同じファイルをいじっていた）した場合は、そのファイルを退避させてプルし、
もう一度編集し直すこともできます。

後は、複数人で共同開発していたときに、ブランチの作成・削除などの情報も取得できます。


## ブランチ（branch）
![download.jpg](https://qiita-image-store.s3.amazonaws.com/0/63338/aaef05b6-5564-1e0f-d99c-bdd31058a706.jpeg)

対象と、全く同じフォルダ・ファイル構造を作成します。
要はコピーを作ってるんですね。
図で表すとこんな感じです↓

![download.png](https://qiita-image-store.s3.amazonaws.com/0/63338/31af2bb4-5e15-9dfd-e8c5-5a00fc8ccb3b.png)

これで、コピー元とおんなじ環境で作業が行なえます。
基本それぞれ各々がブランチを作って作業します。
複数人で作業するのに便利！スタートがみんな一緒だから！！

なおブランチを作ることを、「ブランチを切る」と言います。



## マージ（merge）
![download.jpg](https://qiita-image-store.s3.amazonaws.com/0/63338/98835937-9ad8-f78d-19df-1ba7c8b270ad.jpeg)

ブランチ同士を結合します。
図にすると、こんな感じです。

![download.png](https://qiita-image-store.s3.amazonaws.com/0/63338/83ef9daa-3856-f10a-3f64-bc628d17acee.png)

端から元で作業しろや！と思いますが、複数人で作業するとこっちのほうがやりやすいんです。
また、元ファイルは基本的に「master」と言われ、ここは「動くもの（完成版）」となります。

なので、確認なしにmasterに結合してしまい、バグが出るとシステム全体に影響してしまうという、
重大なエラーが発生してしまうことがあるため、原則ブランチで作業を行うのが普通です。



# おわりに
いかがでしたでしょうか？
一人でもバージョン管理システムの苦手意識から開放されることを祈っております！


あ、後、ブログ始めました。
よかったらみてください！！！
https://nnahito.com/