目次
概要
Gitの基本ついて社内勉強会で発表することになったので、説明に使えるメモを下記に纏める。
Gitとは
何者？
- 分散型バージョン管理システム。
- バージョン管理が可能。
- 分散型なので、複数人開発に最適。
- リーナスさんがLinux開発時のバージョン管理の為に作った。
そもそもバージョン管理とは？
ファイルの変更履歴を保存・管理する事。
GitやSubversionが代表的なバージョン管理システム。
バージョン管理する事で下記のような事が可能。
- 過去バージョンに戻す。
- いつ誰かどんな変更を実施したのか把握。
どんな課題を解決する為のモノ？
下記サイトのGitが生まれた理由を参照。
【絶対理解できる】Gitとは？特徴やできることまとめ！ | 侍エンジニアブログ
基本用語（イメージつきやすい言葉でのザックリ解説なので、詳細・正確な解説は別サイトをご確認ください。）
- リポジトリ：
- GitのCommitが管理されている領域。
- リモートリポジトリ：
- ローカルリポジトリ：
- 皆のローカル環境上に構築されたリポジトリ。
- ブランチ：
- Merge：
- ブランチとブランチを統合する事。
全体像
Gitの操作と、その時起こっている事
上記全体像の画像内の開発着手中と開発後の部分にフォーカスし、流れに沿って一部操作について纏める。
なお、共有資材への反映_MergeRequest以外、下記全てローカルリポジトリ上での操作です。
①開発用ブランチ作成
mainブランチ等から、自分の開発用のブランチを作成する。
git checkout -b <ブランチ名>
②開発
先ほど作成した自分のブランチ上でコーディングやDoc修正等を実施する。
修正内容は、Git内のワークツリーという場所上で行われる。そのため、ファイルを保存してもGit（ローカルリポジトリ）にはまだ反映されない。
③開発内容の保存_ステージング
自分の内容をローカルリポジトリに反映する為にこの後Commitを行なうが、Commit対象のファイルを宣言し、対象ファイルをワークツリーからインデックスに反映する。
この操作をステージングと呼ぶ。
git add <ファイル名>
④開発内容の保存_Commit
先ほどステージングしたファイルをローカルリポジトリに反映する。
この操作をCommitと呼ぶ。
git commit -m "<コミットメッセージ>"
【参考】⑤バグ改修
新規ファイルを実装中に既存ファイルのバグを見つけたので、バグ改修。
【参考】⑥バグ改修の保存_ステージング
新規実装とバグ改修のCommitは分けたい。そのため、バグ改修ファイルのみを指定してadd。
git add <ファイル名>
【参考】⑦バグ改修の保存_Commit
バグ改修ファイルのみCommit。
git commit -m "<コミットメッセージ>"
⑧リモートリポジトリ（共有資材）への反映_push
先ほどローカルリポジトリに保存した開発内容を、リモートリポジトリ（共有資材）へ反映する。
git push origin <ブランチ名>
⑨リモートリポジトリ（共有資材）のmain資材への反映_MergeRequest（PullRequest）
mainブランチ等へ、自分の開発用ブランチの開発内容を反映する為に、mainブランチへのMergeRequestを作成する。
その後、RV権者によるRVが完了したらmainブランチへMergeされる流れ。
【参考】コマンドメモ
- git ls-files
- ステージにaddされているファイルを確認。
- git log --stat
- 各Commitでどのファイルが修正されたかも併せてCommitLogを表示する。
- git log --graph
- ブランチツリーをグラフィカルに表示する。
【参考】rebaseについて
- rebaseを使うウマミは大きく下記2つ。
- Commit履歴が綺麗にできる。（ブランチがなるべく1本の流れになるようにできる）
- 切り出し元ブランチ（mainブランチ等）のCommitを切り出しブランチ（featブランチ等）に取り込める。
- rebaseは、ブランチ切り出し元（mainブランチ等）に対して、切り出しブランチ（featブランチ等）のCommitのCherry-pickを繰り返す事で実現されている。
- そのため、featブランチにmainブランチのCommitを取り込む際、Mergeを実施するとConflictの解消は1度で良いが、rebaseを実施した場合はcherry-pickの回数分だけConflict解消が必要となる。
- rebaseすると、featブランチ上のCommitハッシュ値が変わるので、同featブランチを複数人で使用している場合は、他開発者がPushできなくなってしまう等の迷惑がかかる。
- featブランチにmainブランチのCommitを取り込む際、Mergeではなくrebaseを使用するのは、下記基準を全て満たしている場合にした方が良さそう。
- Conflict解消の手間よりもCommit履歴の綺麗さを優先したい。
- 対象のfeatブランチを他開発者が使用していない。
