Chiroru's Diary

日々の学びをちょこちょこメモしていきます

Gitの基本理解

Git

【目次】

gitの基本

ブランチの統合

「今いるブランチに別のブランチの内容を取り込む」には、mergeを使う方法と・rebaseを使う方法の2種類ある。

  • merge
    変更内容の履歴はそのまま残るが、履歴が複雑になる。
  • rebase
    過去のコミット履歴を書き換える操作。リポジトリ全体の状態を変えてしまうことがあるので、原則的にはプッシュ前のコミットについてのみ使うことにするのが良いかも。 競合箇所を修正した場合、--continueオプションを指定して実行(※コミットではない)

参考：サルでもわかるGit入門 ブランチの統合

git rebase

rebaseのイメージは「branchが生えている場所(コミット)を変更する」。
作業中のブランチにgit rebase masterした場合、作業中のブランチにあるコミットを一時的に保存し、リベース先(master)のブランチに git reset --hard する。(→masterと同じ状態にする)
リセットした後、保存してたコミットを作業中のブランチの上にのせる形になる。
このサイトリベースで何が起きた？がわかりやすい

⚠️注意点

リベースは特定のコミットをどこか別のコミットの後ろに移動するだけの作業に見えるかもしれませんが、実際は移動ではなく、新規コミットを作っているので、当然コミットIDも変わります。したがって、他の開発者のローカルにあるコミットをリベースしちゃうと、コミットIDが変わり、すでに存在している同じコミットと区別がつかなくなり、重複してしまいますよね。 ですから、他人のコミットを決してリベースしてはいけないのです。

参考：git rebase とは
参考：git reset (--hard/--soft)ワーキングツリー、インデックス、HEADを使いこなす方法

git実践編

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

$ git branch  
# 確認  

$ git tag <タグ名>    
# タグを追加  

$ git tag -a <タグ名>
# 注釈付きタグ  

$ git tag  
# 確認  

$ git log --decorate  
# タグ情報を含んだ履歴を表示  

$ git tag -d <タグ名>  
# タグ削除

fetch

マージせず、単にリモートリポジトリの内容を確認したい時に使用。
実行するとリモートリポジトリの最新の履歴の取得だけを行い、取得したコミットは、名前の無いブランチとして取り込まれる。(※ブランチはFETCH_HEADでチェックアウトできる)

pull

pullというのは内部でfetch + merge

発展編 コミット書換え

git commit --amend

直前のコミット修正。上書きコミット。
同じブランチの直前のコミットに対して、内容の追加・コメント修正ができる。
利用シーン：コメント修正、コミット漏れしたファイルを追加など

revert

打ち消し。ある特定のコミットだけをなかったことにしたい時に利用。過去に行なった作業の「逆を行う作業」を新たに行なってコミットする。

そのため訂正の経緯が新しいコミットとして記録され、ブランチには過去のコミットが全て残った状態となる。他ブランチとのマージの際も問題が起こらない。

$ git log

$ git revert [打ち消しコミット]

参考：Gitが面白いほどわかる、基本の使い方33(140~142)

reset

resetについてよくわからなかったので調べた。

git reset コマンドは、checkout中のブランチを指定コミットに紐づけ直すという動作をします。

このサイトの説明がわかりやすかった！
git reset 解説

git resetの3つのオプション

こちらのサイトの説明がわかりやすかった！
2. git resetを使いこなす

  • reset --soft：commitのみ 取り消す(順番間違えたときとか)
  • reset --mixed：commit・add 取り消し
  • reset --hard：commit・add・ファイル変更 全て取り消す
$ git reset --soft HEAD^
// 直前のコミット取り消し(コミットのみ)  

$ git reset --hard HEAD^  
// 直前コミットまるっと取り消し

$ git reset --hard HEAD  
// コミット後の変更 全削除

リセットは「ブランチの状態を過去のある時点に巻き戻す」ことのため、中央リポジトリのコミットが残っている場合、リセット前にコミットした分先行きした状態となり、プルするとリセット分が復活してしまうこともある。

またreset前のコミットはORIG_HEADで参照。間違えてresetした場合、ORIG_HEADにresetし、reset前の状態に戻す。

$ git reset --hard ORIG_HEAD

【過去の状態に戻す機能3種まとめ 】

checkout

  • HEADの指すブランチを変更
  • 作業ファイルの状態を変更する機能

revert

  • 指定したコミットで行なった変更の「逆の作業」を行なったことにして、過去の作業を打ち消す

reset

  • ブランチの状態を過去のある時点に巻き戻す
  • ブランチの指すコミットを変更
  • ブランチの状態を変更する機能

参考：Gitが面白いほどわかる、基本の使い方33(132~137)

打ち消し(revert)かリセットか？

過去の作業内容に間違いがあり訂正したい時は「打ち消し」を利用するのが適切。

「リセット」はローカルリポジトリ専用の作業ブランチ(masterとか中央リポジトリに影響しない)などで、ブランチ内容の書き換えが必要な時などに使うと良い。

参考：Gitが面白いほどわかる、基本の使い方33(142)

プルリクエスト編

コンフリクトが起きた際

手動でマージする。ここを参照
ざっくりまとめると以下の流れ。

  • 作業中のブランチに、プルリクをプルしてもらう対象のブランチをマージする。
  • ローカルで競合を確認し、修正する。
  • 再度コミット&プッシュ

参考