個人的リマインド用

ブランチとマージ、プルリクとか

ブランチ

ブランチは並行して複数機能を開発するためにある(他の人の影響を受けない)

gitのデータの持ち方
コミット1ができる
→コミット2ができると、コミット1の情報をもつ
→コミット3(最新)ができると、コミット2の情報をもつ
各ブランチは最新のコミット3を指し示している(ブランチとはコミットファイルを指し示した、ただのポインタ)
HEADとは
今自分が作業しているブランチを指し示したポインタ
新しいコミットができたら
今masterブランチにいる時にコミット4ができた場合、今までコミット3を指していたポインタ(masterブランチ)はコミット4を差し直す
コミット3でバグを発見
subブランチをコミット3から分岐させ、コミット4'を作成。その後さらにコミット5'を作成する(現在のHEADはsubブランチ)

このようにブランチを使うことで、並行的に分岐して開発を行える

ブランチを新規に追加する

git branch <ブランチ名> 作成するだけで切り替えは行わない

ブランチの一覧を表示する

git branch 今いるブランチを表示

git branch -a 全てのブランチを表示する

ブランチを切り替える

git checkout <既存ブランチ名>
※ git checkout - これでmasterブランチに戻れる

git checkout -b <新ブランチ名>

マージ

マージとは、他の人の変更内容を取り込む作業のこと

変更履歴をマージする

git merge <ブランチ名>
git merge <リモート名/ブランチ名>
git merge origin/master

マージには3種類ある

Fast Forward: 早送りになるマージ
ブランチが枝分かれしていなかった時、元々のmasterブランチのその先にsubブランチがってそれをmergeしただけの時、ブランチのポインタが前に進むだけ
Auto Merge: 基本的なマージ
masterブランチの内容をベースにして、その内容にsubブランチの変更文を取り込んだ内容をスナップショットとしてコミットで記録している(元のコミットとsubが指してたコミットの2つを親コミットとしてもつ)
コンフリクト
複数の人が同じ箇所で別々の変更をした時、どの変更を優先したらいいか分からない状態

コンフリクトの解決の仕方

コンフリクトしたファイル
<h1>Gitチュートリアル</h1>
<<<<<<< HEAD
<p>git addについて学ぼう</p> HEADの変更分
=======
<p>git commitを知ろう</p> subの変更分 
>>>>>>> sub

解決したファイル
<h1>Gitチュートリアル</h1>
<p>git addについて学ぼう</p>
<p>git commitを知ろう</p>

1.ファイルの内容を書き換える
2.「<<」「==」「>>」の記述を削除する

コンフリクトが起きないようにするには
・複数人で同じファイルを変更しない
・pullやmergeをする前に変更中の状態を無くしておく(commitやstashをしておく)
・pullする時は、pullするブランチに移動してからpullする
・コンフリクトしても慌てない

ブランチを変更・削除する

変更
git branch -m <ブランチ名>
git branch -m new_branch
自分が作業しているブランチの名前を変更

削除
git branch -d <ブランチ名>

強制削除
git branch -D <ブランチ名>

開発の流れ
masterブランチをリリース用ブランチに、開発はトピックブランチを作成して進めるのが基本
→masterブランチを最新の状態に保てるから、今リリースされているものがどういう状態なのか1目でわかるし、リリース後にバグが起こっても1つ前のバグのないものに切り替えればOK

リモートブランチ

リモートのブランチの状態へのポインタ

イメージ
1.ローカルリポジトリとリモートリポジトリを比較した際、ローカルにリモートにないコミットがあり、リモートの方が進んでいる状態
2.git fetchを実行すると、リモートのmasterやsubをローカルに持ってくる。その際ローカルでのポインタ名はorigin/masterだったりorigin/subになる

Githubを利用した開発の流れ

プルリクエスト

バグを発生させないためや、コードの質を担保するために誰かが変更したコードをGitHubに取り込む前には必ずレビューを挟むようにして開発していく(OKだったら取り込む、NGだったら拒否)

プルリクエストの手順
1.masterブランチを最新に更新
2.ブランチを作成
3.ファイルを変更
4.変更をコミット
5.GitHubへプッシュ
ここまでローカル
6.プルリクエストを送る
7.コードレビュー
8.プルリクエストをマージ
9.ブランチを削除

詳しい手順に関してはudemyで確認

GitHub Flowの流れ

GitHub社のワークフロー
開発フローをシンプルにすることで誰でも迷わずジョインできる

1.masterブランチからブランチを作成
2.ファイルを変更しコミット
3.同名のブランチをGitHubへpush
4.プルリクエストを送る
5.コードレビューし、masterブランチにmerge
6.masterブランチをデプロイ

ポイント
・masterブランチは常にデプロイできる状態に保つ
・新開発はmasterブランチから新しいブランチを作成してスタート
・作成した新しいブランチ上でコミットする
・定期的にpushする(他のチーム状況を確認するため)
・masterにマージするためにプルリクエストを送る
・必ずレビューを受ける
・masterブランチにmergeしたらすぐにデプロイする
　そのためテストとデプロイは自動化

すぐにデプロイすることで、リリースされているものと開発中のものの進捗状況が同じになるためわかりやすい

3/30 git part3