# Git入門

<br>

**本記事のゴール : 共同開発、Gitの用語についてやんわり理解する**

<br>

## 目次

[**共同開発のイメージ**](#共同開発のイメージ)

[**リポジトリ (Repository)**](#リポジトリ-repository)

[**プル (pull) と プッシュ (push)**](#プル-pull-と-プッシュ-push)

[**ブランチ (Branch)**](#ブランチ-branch)

[**コミット (commit)**](#コミット-commit)

[**マージ (merge)**](#マージ-merge)

[**プルリクエスト (pull request)**](#プルリクエスト-pull-request)

[**その他**](#その他)

<br>

# **共同開発のイメージ**

よく私はみんなでプラモデルを作るようなものというイメージでいます。ガンプラとか

共同開発では、それぞれの開発者がガンダムの胴体をつくったり、腕を作ったりします。そして、合体させる前に「他のパーツと干渉しないか」、「ちゃんと合体できそうか」などをチェックしてから合体させていくって感じでみんなでガンダムを作っていくイメージです。

<br>

**イメージ**


ここからの用語解説でたまにプラモデルでのたとえをいれていきます。

<br><br>

# **Gitの用語解説**

<br>

# **リポジトリ (Repository)**

プロジェクトのデータベース。

プロジェクトに関連する全てのファイルと、それらの変更履歴が保存されています。

このリポジトリ上でコードの共有や作業を行います。

先のたとえでいうとリポジトリは作業台です。

作業台にはタイトル( ガンダムなのかエヴァなのかみたいな )やプラモデルのパーツがすべて入っています。この中でみんながパーツを作ったり組み立てたりします。


**ローカルリポジトリ**

開発者が直接作業を行う場所です。開発者個々の作業台といってもいいかもしれません

ローカルリポジトリは個々の開発者のコンピュータ上に存在するリポジトリで、開発者はこのローカルリポジトリで自由に変更を加え、**コミット(後述)** を重ねます。

<br>

**リモートリポジトリ**

インターネット上またはネットワーク内に存在するリポジトリです。みんながアクセス**できる**中央の作業台群です。

各人が作業したプラモデルの部分（ローカルリポジトリでの作業）を持ち寄り、全体の作品を完成させる場所です。

ここで、プロジェクトのコード、ドキュメントなどのバージョン管理を行います。プロジェクトメンバーはこのリポジトリを通じてコードを共有し、協力して作業を進めます。


開発の一番最初に共有リポジトリの完全なコピーをローカルマシンに作成するプロセスを**クローン(clone**)といいます

また、リモートリポジトリの内容をローカルリポジトリに取り込む操作を**プル(pull)**、ローカルリポジトリの変更をリモートリポジトリに反映する操作を **プッシュ(push)** といいます。

<br>

# **プル (pull) と プッシュ (push)**

**プル (pull)**

リモートリポジトリの内容をローカルリポジトリに**取り込む**操作です。

中央の作業台の内容を自分の作業台に持ってくるようなイメージです。

**プッシュ (push)**

ローカルリポジトリの変更をリモートリポジトリに**反映する**操作です。

自分の作業台の内容をみんなが見れる作業台群に持っていくようなイメージです。


<br>

# **ブランチ (Branche)**

みんなの作業スペースの内容から分岐させた自分の作業スペース

このブランチ内では腕の作成や胴体の作成を個々で行います。

**メインブランチ**とそれ以外の**ブランチ**に分けられ、元となるブランチ(通常メインブランチ)からブランチを分岐させて新しい開発を行います。

ブランチを作成することで元のブランチに影響を与えずに自由にコードの**修正や追加、実験**を行えます。

**メインブランチ(Default Branche)**

テスト済みかつ確実に動作するコードのみが含まれる…ようにするのが理想です。

**他ブランチ**

個々の作業スペース

分岐したブランチを作ることを**ブランチを切る**と言ったりします。


ブランチ例(defaultってなっているのがメインブランチ)


<br>

# **コミット (commit)**

ファイルやディレクトリの変更履歴を記録すること

部品を組み立てるたびにその状態を写真に撮って記録しておくようなものです。

ファイルに加えた変更(追加、変更、削除)をコミットしておくことでなにかあったときにその時に戻ることができる。

**こまめにコミットしましょう**


コミット例


<br>

# **マージ (merge)**

変更の統合

ブランチからの変更点や開発内容を一つのブランチに**統合する**ことをマージといいます。

コアフレーム(メインブランチ)から分岐させて作った胴体の部分をコアフレームに合体させる動作です。

たとえば「AからBに**マージ**する。」という場合、AとBの**差分**をBにくっつけるということです。


共同開発では後述する**プルリクエスト**を行いレビュワーなどからの**承認後**マージされます。

<br>

# **プルリクエスト (pull request)**

マージ(ブランチから別のブランチへコードの変更を統合)するためのリクエスト。

**誰かのコードをみんなのコードにする作業**

このリクエストでは、**レビュー**を行います。

**レビュー**とはマージ時に競合(コンフリクト)などが起こらないようにチームの中の第三者による確認や自動テストを行う工程です。ここで、**レビュアー**はレビューする人、**レビュイー**はレビューされる人です。

レビュイーは、このレビューやテストの結果を基にブランチのコードを**修正**、コミットを行い、レビュワーからの **承認(approve)** をもらいマージします。

合体させる前に「他のパーツと干渉しないか」、「ちゃんと合体できそうか」などをチェックする工程です。

共同開発の中では**一番大切**な工程です。



レビュアーとなった人はそのコードが**みんなのコード**になるにふさわしいかを考えてレビューをしましょう！逆に レビューイはプルリクの差分が**みんなのコード**にふさわしいか考えながら実装しましょう！

<br>

# 実践

**とにかくやってみよう！**

gitコマンドの学習アプリ(web)

[Learn Git Branching](https://learngitbranching.js.org/?locale=ja)

コマンドライン操作の講義

[The Missing Semester of Your CS Education](https://missing.csail.mit.edu/)

<br>