はじめに
2月からマイスターギルドに入社しました！
技術的な部分もQiitaもまだまだひよっこのため、
研修の内容をこれからアウトプットしていきたいと思います。
よろしくお願いします。
今回は「Gitについて」書いていきたいと思います。
学んだこと
Gitとは
編集した内容、履歴を管理することができるツール
○○を表示されるようにした
××を修正した
などの記録を残して管理することができる
ローカルとサーバーの違いは？
ローカルは自分のみの作業場所
サーバーはみんなで共有できる作業場所（GitHubなど）
Git用語
commit
編集内容をリポジトリ（保管場所）に記録する
なぜcommitの前にaddが必要なのか？
addをすると、リポジトリとワークツリー（作業場所）の間にあるインデックスという場所に保管される
これを経由することで必要のない変更を含めずにcommitできたり、一部の変更のみを指定してcommitすることができる
push
ローカル上にコミット3つ サーバー上にコミット2つ
「ローカルのコミットをサーバーに反映させたい！」
→ pushするとサーバーに反映される
pull
ローカル上にコミット2つ サーバー上にコミット3つ
「サーバーのコミットをローカルに反映させたい！」
→ pullするとローカルに反映される
pull request
push後、GitHub上でpull requestを投げてレビューしてもらう
意識することはreviwersが見やすいpull request！
何のために書いたのか作業内容・目的を明記する
- タイトル、本文の記載
- 変更概要、タスクへのリンクを貼る
- 変更箇所へのコメントの記載
merge
作業内容を取り込む時に使う
今までのbranchを統合する
fast merge
進行度合いが同じだった場合、merge、commitがそのまま取り込まれる
non-fast merge
進行度合いに違いがあった場合、元commitのあとにmerge commitという修正内容は同じだが違うcommitがつくられる
進行度合いに違いがあるときにもfast mergeできる？
rebaseを使うとbranchの進行度合いが揃う ＝ fast mergeできる！
fetch
リモートの最新情報をローカルにもってくる
origin / ブランチ名（リモート追跡ブランチ）が更新されるだけで、ローカルブランチ自体は更新されない
fetch：リモートのmasterブランチからローカルのorigin / masterブランチに最新情報がくる
merge：ローカルのorigin / masterブランチからローカルのmasterブランチに最新情報がくる
このfetchとmergeを合わせたものが pull
rebase
ブランチを生やし直す
変更内容は同じで新たなcommitがつくられる
GitHub上で使うmerge（3種類）
どういうmergeするのか決まりをつくって開発していく
create a merge commit
何をmergeしたのかcommitが残る
rebase and merge
編集内容は同じだけどcommitとしては別のものがつくられる
履歴が一本化されて見やすくなる
squash and merge
merge元の複数のcommitをまとめて完全に新たなcommitをつくる
まとめすぎるとmergeが戻せなくなるので、機能単位でsquashするのがよい
コンフリクト
複数人で作業していて同じ行で異なる修正をしてmergeした場合などに起こる
手動で変更が必要
conflictが起きないように意識できること
- プランニングの段階でコンフリクトは予見できるので作業が平行しないように調整する
- コードの責務が明確な状態になっている
- タスクの範囲とcommitの変更内容を一致させる
- フォーマッタのルールを統一する
Git Bashを使ったrebase
git rebase -i ＜commit位置＞
commit位置に入るもの
- branch名
- commit hash
- HEADからの相対位置
- 「HEAD~~~」とするとHEADから3commit前という意味になる
補足：HEADとは？
現在作業している場所、作業ブランチのこと
※commit自体を指すこともある
branch運用の考え方 ～git flow～
4つのフェーズに分けて考える
開発フェーズ
新しい機能が追加される
使うブランチ：develop、feature(feat)
親ブランチ：master
運用フェーズ
本番環境でアプリが動いている
使うブランチ：master
保守フェーズ
バグを修正する
リファクタする
使うブランチ：fix(hotfix)
親ブランチ：master、release（開発後relaseブランチで修正するとき）
テストフェーズ
（開発は終わっている状態）
新しい機能やバグの修正、リファクタを加えた状態の動作確認をする
使うブランチ：release
親ブランチ：develop
まとめ
今まで深く考えずにGitを使用していたため、研修という形で学ぶことで理解が深まりました。
実際に手を動かして操作する際に、今回SourceTreeを利用したことで、インデックスという場所があることも視覚的に確認でき、コミットの動きなどがイメージがしやすくなりました。
Git bushでのvimの操作だったり、rebaseなど初めて使うコマンドも多かったのでこれから使いながら覚えていきたいと思います。