新入社員向け：さくっと使えるようになるためのGitメモ


## Git基礎編で覚えるべきこと
- ブランチ
- チェックアウト←紛らわしいもの
- コミット
- プッシュ
- マージ
- プルリク


## そもそもGitとは？
- ソースコードの修正点を管理するためのバージョン管理ツールである
- もともとはLinuxを開発するために作成された
- 一般的なIT企業ではGitが当たり前のように使用されている
- P4Vを使う業界もある。具体的にはゲーム業界。
  - Gitはバイナリデータの管理が苦手である。P4Vであれば、大容量の画像や動画を管理も高速で行えるため、CGデータなど非コードアセットが多いゲーム業界では採用されている[^1]。

## Gitでのバージョン管理の概要
- Gitはブランチとコミットがメインテーマである
- ブランチとは、リリース用のブランチと開発用のブランチがある
- コミットとは、変更内容にコメントをつけて塊にしたもの
- リリース用のブランチ（main）から開発用のブランチ（feature）を作成する
- featureブランチは機能単位で作成する（いくつ作成しても良い）
- featureブランチで開発を行ったあと、コミットを行い、変更内容にコメントをつける
- コミット後はリモートリポジトリにpushして、プルリクを行うことでコードレビューとコードマージを実施する。

## Gitでの開発の全体像
1. 開発用のブランチを作成する
2. 開発する
3. コミットを行う
4. リモートリポジトリへpushする
5. GitHub上でプルリクを作成する
6. プルリクをレビュアーがコードレビューをする
7. 修正内容に問題がなければマージする
8. 問題があれば、差し戻す
9. 修正がマージされれば、開発用のリモートリポジトリを削除する

![OverviewOfGit.excalidraw.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/79967/7315b25b-d062-9861-c9d9-d07b9f240dfc.png)


## Gitでのコミットとは、変更点の塊である
- 変更点に対してコメントをつけることができる。
- それをコミットという
- コミットが変更点の塊である
- コミットは複数存在する
- １機能単位でコミットをつけることが多い。

## ブランチの種類（概念的なもの）
- oursブランチ：自分が作業中のブランチ
- theirsブランチ：自分が作業していないブランチ

![BranchOursTheirs.excalidraw.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/79967/1bf93c91-e32f-908b-a611-4816722bb87e.png)


## Gitのコマンドの使い方
### 基礎編のコマンド
Visual Studio 2019でもGit機能があるので、簡単なことならできますが、コマンドと対応付けて覚えた方がGood。
```
git init
git clone
git add <ファイル名>
git commit -m "コミットメッセージ"
git push origin <ブランチ名>
git fetch
git checkout <oursにしたいブランチ名>
git merge <マージ元のブランチ名>
```

## git init
### 概要
- ローカルにあるフォルダをgitの管理下にしたい場合に実施する。
  - 実施したフォルダ内に".git"フォルダが作成されます
  - gitコマンドを使いたい場合は、.gitフォルダが作成されている必要がある。
- 最初に1度だけ実施すれば良い。
- git cloneをした場合は実施不要。最初から.gitが存在するため。

### 使い方(CLI)
```
cd <gitで管理したいフォルダ>
git init
```

## git clone
### 概要
- リモートリポジトリをローカルにダウンロードする
- SVNでいうところの「チェックアウト」

### 使い方(CLI)
```
cd <ダウンロードしたいパス>
git clone <リモートリポジトリのURL>
```

## git status
### 概要
- gitのフォルダの状態（変更が加えられたファイルがあるかなど）を確認する

### 使い方(CLI)
```
cd <ローカルのリポジトリ>
git status
```

## git add
### 概要
- ファイルをgitの管理下にする

### 使い方(CLI)
- 1ファイルずつ選択して管理対象にする
```
git add <gitの管理下にしたいファイルパス>
```

- 現在のフォルダの配下をすべてgitの管理対象とする
  - 「.」はLinux関連でいうところの現在のフォルダ（カレントディレクトリ）を指す
```
git add .
```

## git commit -m "コミットメッセージ"
### 概要
- git addしたファイルに対して、修正内容を記録に残し、追跡できるようにする
- コミットのイメージは「送り込む」[^commit]。

### 使い方(CLI)
```
git commit -m <コミットメッセージ>
```

## git push origin <ブランチ名>
### 概要
- commitした内容をリモートリポジトリにアップロードする
- SVNでいうところの「更新」
### 使い方(CLI)
```
git push origin <リモートリポジトリのブランチ名>
```

## git fetch
### 概要
- リモートリポジトリの内容を別のローカルブランチにダウンロードする
- ローカルでは、「origin/リモートリポジトリのブランチ名」というブランチ名で存在することになる
### 使い方(CLI)
```
git fetch
```

## git checkout <oursにしたいブランチ名>
### 概要
- Ours(作業中)ブランチを変更するときに使う
- 別のブランチに入るので、チェックインじゃないの？と思うことかもしれないが、名前の由来は「本を借りる（Check-Out）」から来ている。ホテルのチェックインのように理解しても差し支えない。
### 使い方(CLI)
```
git checkout <Oursにしたいブランチ名>
```

## git merge <マージ元のブランチ名>
### 概要
- マージさせたいローカルのブランチが異なる場合は、必ずgit checkoutでOursを変更する必要がある
### 使い方(CLI)
```
git merge <ブランチ名>
```

git fetchでリモートから取得したブランチをローカルブランチにマージするときは、「origin/」の追加が必須。
```
git merge origin/<ブランチ名>
```

## Pull Request（プルリク）とは？
- GitHubなどのリポジトリサービスではレビュー依頼をするために、Pull Requestという仕組みがある

## プルリクのやり方
- まずはリモートリポジトリにpushする
- レビュアーを指定してプルリクを作成する

### プルリクのコツ
- プルリクは小さい単位で実施する（1機能単位など）
  - レビューする側がコードを読む負担を下げるため


## ブランチ運営
ブランチの運営については、大きく２種類が存在する
- Git-flow
- GitHub-Flow


## Git-Flow
Git-Flowの方がより細かくブランチを切って運用するスタイルであり、リリースバージョンを管理するうえで活躍する。
- main：リリースされているもの
- develop：mainからブランチを切られたもの
- feature：developからブランチを切られた機能開発用のもの。機能毎に作成されるため、複数のfeatureブランチが存在する。必ずdevelopからブランチされ、mainからはブランチを切ってはいけない。
- hot-fix：不具合修正用のもの


## GitHub-Flow
Git-Flowよりもブランチの種類が少ない。
featureはmainからブランチを切っても良い。[^github-flow]
- main
- feature
- hot-fix

## featureブランチの作り方
- feature-function-name
- feature/#<issue番号>

## issueとは、開発ネタをまとめておくもの
- 改善ネタ
- 不具合報告
などが挙げられる。
issueにはissue番号が自動で割り振られるため、feature/#1のようにブランチ名に使用することもある。


Githubの場合、ブランチ名に使用しておけば、プルリクを行ってマージされたタイミングで、issueも自動でcloseすることが可能。

以下は、自分が好きなOSSのissue。
https://github.com/logseq/logseq/issues

## 用語集
- リポジトリ：git管理下のフォルダ
- コミット：変更点をひとかたまりで記録すること
- プッシュ：コミットをリモートリポジトリにアップロードすること
- フェッチ：リモートブランチの変更点をダウンロードすること（マージはしない）
- プル：リモートブランチの変更点を自動的にローカルでチェックアウトしているブランチにマージすること（fetch & mergeと同じこと）
- マージ：他のブランチの変更を現在チェックアウトしているブランチに合体させること
- プルリク：プッシュしたコミットをmainブランチにマージしてもらうときに、コードレビューの依頼を出すこと

## 「.git」フォルダの中身の例
- hooks
  - commitの前後で実施したいスクリプトなどがある
  - pre-commitファイルにスクリプトを記載すれば、コミット前に実行される
  - コミット時にコミットファイルに対してチェック処理を実行するなど自由に可能。
- config
  - ```git config --list```で表示される情報が記載されている
  - リモートリポジトリの情報などが含まれている


[^1]:https://www.perforce.com/blog/vcs/git-vs-perforce-how-choose-and-when-use-both
[^github-flow]:https://www.kagoya.jp/howto/it-glossary/develop/githubflow/
[^logseq]:https://github.com/logseq/logseq/issues
[^commit]:https://bookclub.japantimes.co.jp/news/n22494.html#:~:text=%EF%BC%A1%EF%BC%9Acommit%E3%81%A8%E3%81%AF%E3%80%81%E3%80%8C%E9%80%81%E3%82%8A%E8%BE%BC%E3%82%80%EF%BD%A3%E3%81%93%E3%81%A8%E3%80%82&text=commit%20a%20poet%20to%20memory,%E3%80%81%E6%9A%97%E8%A8%98%E3%81%99%E3%82%8B%EF%BD%A3%E3%81%A8%E3%81%AA%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82