Git基礎編で覚えるべきこと

ブランチ
チェックアウト←紛らわしいもの
コミット
プッシュ
マージ
プルリク

そもそもGitとは？

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

Gitでのバージョン管理の概要

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

Gitでの開発の全体像

開発用のブランチを作成する
開発する
コミットを行う
リモートリポジトリへpushする
GitHub上でプルリクを作成する
プルリクをレビュアーがコードレビューをする
修正内容に問題がなければマージする
問題があれば、差し戻す
修正がマージされれば、開発用のリモートリポジトリを削除する

Gitでのコミットとは、変更点の塊である

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

ブランチの種類（概念的なもの）

oursブランチ：自分が作業中のブランチ
theirsブランチ：自分が作業していないブランチ

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したファイルに対して、修正内容を記録に残し、追跡できるようにする
コミットのイメージは「送り込む」²。

使い方(CLI)

git commit -m <コミットメッセージ>

git push origin <ブランチ名>

概要

commitした内容をリモートリポジトリにアップロードする
SVNでいうところの「更新」

使い方(CLI)

git push origin <リモートリポジトリのブランチ名>

git fetch

概要

リモートリポジトリの内容を別のローカルブランチにダウンロードする
ローカルでは、「origin/リモートリポジトリのブランチ名」というブランチ名で存在することになる

使い方(CLI)

git fetch

git checkout

概要

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からブランチを切っても良い。³

main
feature
hot-fix

featureブランチの作り方

feature-function-name
feature/#

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で表示される情報が記載されている
- リモートリポジトリの情報などが含まれている