BLOG

gitメモ④

完全に個人用思い出しメモなのであしからずm(_ _)m

プルリクエストの流れ

プルリクエストとは、自分の変更したコードをリポジトリに取り込んでもらえるよう依頼する機能である。

プルリクエストを使うと、

・まず自分がコードを変更する

・変更した分をリポジトリに取り込んでと依頼する。

・依頼を受けたチームメイトがコードレビューをして、オッケーならリポジトリに取り込む、NGなら取り込まない。

プルリクエストの手順

①masterブランチを最新に更新(ワークツリー→ローカルリポジトリ/ローカル内)

②ブランチを作成(ワークツリー→ローカルリポジトリ/ローカル内)

③ファイルを変更(ワークツリー→ローカルリポジトリ/ローカル内)

④変更をコミット(ワークツリー→ローカルリポジトリ/ローカル内)

⑤GitHubへプッシュ

⑥プルリクエストを送る(GitHub(リモートリポジトリ))

⑦コードレビュー(GitHub(リモートリポジトリ))

⑧プルリクエストをマージ(GitHub(リモートリポジトリ))

⑨ブランチを削除(GitHub(リモートリポジトリ))

実際にやってみる

git branch
git pull origin master
git status
git checkout -b pull_request

index.html一行挿入する

git add index.html
git commit -m "pull requestを追記"
git push origin pull_request

GitHubへ移動し、

Pull request → New pull request

base:master、compare:pull_request

これはcompareのほうがプルリクエストするブランチになる。

今回はpull_requestの方からbase:masterへプルリクを送るよということになる

create pull requestを押す。

内容を書く。

Reviewerを選択して、レビューして貰う人を選択する。

選ばれた人はプッシュ通知がメールで来る。

レビュアー側の手順

Pull requestを押す。

タイトル選択→Files changed

ここには変更したファイルの中身が書かれている。

修正お願いしたい時は、行の左端にプラスボタンが出るから、そこでコメントを残せる。

一通りレビューが済んだら、Review changesを押す。

Approve→Submit reviewを押す。(プルリクエストを承認する)

conversationに戻る。

GitHub Flowの流れ

master→branch→プルリクエスト→masterのループ

①masterブランチからブランチを作成(ワークツリー→ローカルリポジトリ/ローカル内)

②ファイルを変更しコミット(ワークツリー→ローカルリポジトリ/ローカル内)

③同名のブランチをGitHubへプッシュ

④プルリクエストを送る

⑤コードレビューし、masterブランチにマージ(リモートリポジトリ)

⑥masterブランチをデプロイ(リモートリポジトリ)

実践する上でのポイント

・masterブランチは常にデプロイ出来る状態に保つ

・新開発はmasterブランチから新しいブランチを作成してスタート

・作成した新しいブランチ上で作業しコミットする。

・定期的にPushする

・masterにマージするためにプルリクエストを使う。

・必ずレビューを受ける。

・masterブランチにマージしたらスブにデプロイする←テストとデプロイ作業は自動化

リベースで変更履歴を修正する

リベースとは変更を統合する際に、履歴をきれいに整えるために使う

git rebase ブランチ名

ブランチの基点となるコミットを別のコミットに移動する。

リベースの一連の作業の流れ

git checkout feature
git rebase master
git checkout master
git merge feature

これでコミットの流れを一直線にすることができる(Fast Foward)

リベースとマージの違い

リベースとマージの違いは履歴が一直線(リベース)か枝分かれ(マージ)しているか。

他のブランチの内容を取り込む際に、履歴を一直線に綺麗に取り込みたい場合はリベースを使う。

実際にやってみる

masterとfeatureブランチのそれぞれで新しいファイルを作ってコミットしておく(git checkout featureしておく)

git rebase master
git log

確認して見れる通り、masterブランチの内容を取り込んで履歴を一直線にできる。

次にmasterブランチにfeatureブランチの内容を取り入れる。

git checkout master
git merge feature

※git merge でコミットメッセージを出来るようにする(任意)

git config --global merge.ff false

最後にpushする

git push origin master

featureブランチを削除する

git branch -d feature

リベースでしてはいけないこと

GitHubにプッシュしたコミットをリベースしてはいけない。

git push -fは絶対NG(-fはforce:強制するの略)

マージかリベースの使い分け方

マージかリベースかは考え方次第

▼マージ

+コンフリクトの解決が比較的簡単

−マージコミットがたくさんあると履歴が複雑化する。

→作業の履歴を残したいならマージを使う

▼リベース

+履歴をきれいに保つことが出来る

-コンフリクトの解決が若干面倒(コミットそれぞれに解決が必要)

→履歴をきれいにしたいならリベースを使う

マージとリベースのコンフリクトの違い

▼マージ

コンフリクトが一度しか発生しない

▼リベース

コンフリクトが各コミットごとに発生する

プッシュしていないローカルの変更にはリベースを使い、プッシュしたあとはマージを使う。

コンフリクトしそうならマージを使う

プルにはマージ型とリベース型がある

▼プルのマージ型

git pull リモート名 ブランチ名
git pull origin master

マージコミットが残るから、マージしたという記録を残したい場合に使う

▼プルのリベース型

git pull --rebase リモート名 ブランチ名
git pull --rebase origin master

マージコミットが残らないから、GitHubの内容を取得したいだけの時は–rebaseを使う

GitHub上のマスターブランチの最新の内容を取得したいだとか、GitHubの内容を単純に取得したい時はリベースがおすすめ

プルをリベース型に設定する

–rebaseオプションを付けなくてもgit pullの挙動がリベース型になる

git config --global pull.rebase true

git config branch.master.rebase true

masterブランチでgit pullするときだけ

ちなみに

~/.gitconfig

~/.config/git/config

は–globalをつけるとPC全体の設定になる

project/.git/config

は今の自分のプロジェクトだけの設定になる。

リベースで履歴を書き換える①

▼直前のコミットをやり直す。

git commit --amend

リモートリポジトリにpushしたコミットはやり直したらダメ

▼複数のコミットをやり直す

git rebase -i コミットID
git reabase -i HEAD~3

pick gh21f6d ヘッダー修正
pick 193054e ファイル追加
pick 84gha0d README修正

-iは–interactiveの略。対話的リベースといって、やり取りしながら履歴を変更していく。

やり直したいcommitをeditにする
edit gh21f6d ヘッダー修正
pick 193054e ファイル追加
pick 84gha0d README修正

やり直したら実行する
git commmit --amend

次のコミットへ進む(リベース完了)
git rebase --continue

HEAD~

1番目の親を指定する。HEADを基点にして数値分の親コミットまで指定する。

HEAD^

HEAD^2とすると、マージした場合の2番目の親を指定する。

rebase -iコマンドの一連の流れ

①git rebase -i コマンドで対話的リベースモードに入る

②修正したいコミットをeditにしてコミットエディタを終了する

③editのコミットのところでコミットの適用が止まる

④git commit –amendコマンドで修正

⑤git rebase –continueで次のコミットへいく

⑥pickだとそのままのコミット内容を適用して次へいく

リベースで履歴を書き換える②

コミットを並び替える、削除する

git rebase -i HEAD~3

pick gh21f6d ヘッダー修正
pick 193054e ファイル追加
pick 84gh0d README修正

履歴は古い順に表示されるので注意。git logとは逆。

①84gha0dのコミットを消す
②193054eを先に適用する
pick 193054e ファイル追加
pick gh21f6d ヘッダー修正

コミットを削除したり、並び替えしたりできる。

コミットをまとめる

git rebase -i HEAD~3

pick gh21f6d ヘッダー修正
pick 193054e ファイル追加
pick 84gh0d README修正
コミットを1つにまとめる
pick gh21f6d ヘッダー修正
squash 193054e ファイル追加
squash 84gh0d README修正

squashを指定するとそのコミットを直前のコミットと1つにする。

コミットを分割する

git rebase -i HEAD~3

pick gh21f6d ヘッダー修正
pick 193054e ファイル追加
pick 84gh0d READMEとindex修正
コミットを分割する

pick gh21f6d ヘッダー修正
pick 193054e ファイル追加
edit 84gh0d READMEとindex修正

git reset HEAD^
git add README
git commit -m "README修正"
git add index.html
git commit -m "index.html修正"
git rebase --continue

タグの一覧を表示する

git tag

パターンを指定してタグを表示
git tag -l "202010"
20201018_01
20201018_02
20201019_01

git tagコマンドはアルファベット順にタグを表示する。

▼タグには、注釈付き(annotated)版と軽量(lightweight)版の2種類がある。

・タグを作成する(注釈付きタグ)

git tag -a[タグ名] -m"[メッセージ]"
git tag -a 20201018_01 -m "version 20201018_1"

-aオプションをつけると注釈付きタグを作成する。

-mオプションを付けるとエディタを立ち上げずにメッセージを入力できる。

・タグを作成する(軽量版タグ)

git tag [タグ名]
git tag 20201018_01

後からタグ付けする
git tag[タグ名][コミット名]
git tag 20201018_1 8a6cbc4

オプションをつけないと軽量版タグを作成する

タグのデータを表示する

git show [タグ名]
git show 20201018_01

タグのデータと関連付けられたコミットを表示する。

タグをリモートに送信するにはgit pushコマンドで別途指定する。

git push [リモート][タグ名]
git push origin 20201018_01

タグを一斉に送信する
git push origin --tags

–tagsを付けるとローカルにあってリモートリポジトリに存在しないタグを一斉に送信する。

作業を一時避難させる

作業が途中でコミットしたくないけど別のブランチで作業しないといけない。そういうときに作業を一時避難する。

git stash
git stash save

stashは「隠す」という意味

避難した作業を確認する

git stash list

避難した作業の一覧を表示する。

避難した作業を復元する

最新の作業を復元する
git stash apply
ステージの状況も復元する。
git stash apply --index

特定の作業を復元する
git stash apply [スタッシュ名]
git stash apply stash@{1}

applyは適用するということ

避難した作業を削除する

最新の作業を削除する
git stash drop

特定の作業を削除する
git stash drop[スタッシュ名]
git stash drop stash@{1}

全作業を削除する
git stash clear