0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

Gitのコマンド一覧(4) -rebase, cherry-pick, reset-

Posted at

概要

Gitのコマンド一覧(3)ではfetchpullに関して説明したが、本ブログでは、rebasecherry-pickなど、gitのログを改編する(実際にはそのログも残るため改編ではないが)コマンドについて説明をする。本ブログの内容までを理解することで、一通りの基礎を学ぶことができ、あらゆる場面に対応できる知識を身につけることができるはずである。

主に使っているコマンド

  • init
  • add
  • commit
  • push
  • clone
  • status
  • log
  • reflog
  • branch
  • checkout
  • remote
  • fetch
  • merge
  • pull
  • rebase
  • cherry-pick
  • reset
  • rm

rebase

git rebaseはブランチの根元を修正する時に用いるものである。具体的には以下のような修正をしたい時に用いる。

git_rebase.png

過去の歴史を改編するわけだからコンフリクトが起こる可能性が極めて高い。以下にコマンドの手順を載せる。

  1. git checkout developでブランチの根元を変えたいブランチにチェックアウトする。
  2. git rebase masterで幹のブランチ(master)を指定する。(この時点ではrebaseされない)
  3. (恐らく)コンフリクトが生じるため、1ファイルずつ解消していく。
    1. 表示されているコンフリクトが解消できたらgit rebase --continueでrebaseを継続する。
    2. もしrebaseを中断したい場合はgit rebase --abortを実行すると、1の状態まで戻る。
  4. 全てのコンフリクトが解消されればローカルリポジトリでのrebaseは完了である。
    1. リモートリポジトリに反映させる場合には、add -> commit -> pushをするのだが、この際にgit push -f origin masterとオプション-f(force)をつける必要がある。

-fをつける理由として、ローカルリポジトリとリモートリポジトリでブランチの生える場所が異なるため必ずコンフリクトが生じてしまうためである。(試しにgit push origin masterを実行すると、エラーを吐き、git pullを要求されるが、当然git pullをしてしまっては意味がない)

このrebaseを用いる理由として、ブランチの整理をするが大きな理由だと筆者は考えている。例えば複数人が同時に様々な部分の回収をそれぞれブランチを切って行なっており、masterブランチがv0からv1になった場合、v0から生えてるブランチをv1にマージするのは運用・管理するには非常に見づらく一貫性のないgit運営に見えないだろうか。

cherry-pick

git cherry-pickはあるブランチのコミットの内容を別のブランチに反映させることである。(筆者は初めこのコマンドを教えてもらった時、急に美味しそうなコマンドが出てきたな、と不覚にも思った。)主に以下のようなことを行える。

git_cherry_pick.png

以下にコマンドの手順を載せる。(途中でログのハッシュ値に関して出てくるが、その詳細は本ブログの後半で述べる)

  1. git checkout developでコミットの情報を取りたいブランチにチェックアウトする。
  2. git log --onelineでそのブランチのログとそのハッシュを確認する。(qを押すことで確認を終了する)
  3. 情報を取りたいコミットの開始点の一つ前(ここでいうA)から終点(ここでいうY)のキャッシュを取得する。
  4. git checkout masterでコミットの情報を付与したいブランチにチェックアウトする。
  5. git cherry-pick [Aのハッシュ値]..[Yのハッシュ値]を実行する。

上記で気をつけたいことは情報を取りたいコミットの開始点の一つ前である。次の章では触れてこなかったlogとそのハッシュに関して説明する。

ログの確認

Gitでプロジェクトを管理していると、過去にどのようなコミットをしてきたかを確認することができる。また、上記のcherry-pickで出てきたログのハッシュ値についてもこのログを確認することで取得することができる。

log

筆者が用いているコマンドは主に以下の二つである。

> git log

git logは現在いるブランチのHEAD(最先端の部分、上記developブランチにいる場合、Zの部分)から親元を再起的にログを見ていくコマンドである。すなわち上記の例だとZ -> Y -> X -> Aとログが出力されることになる。git logでは誰が(Author)いつ(Date)何を(commit等)を行なったかを確認することができる。

また、qを押すことで閲覧モードを解除できる。

> git log --oneline

--onelineオプションをつけることで、git logの一つずつのログを一行ずつ表示することができる。

git_log_oneline.png

この左側の黄色の部分がログのハッシュ値である。このハッシュ値を用いてgit cherry-pickgit resetを行うことができる。

reflog

> git reflog

上記のgit logとは異なり、あらゆる(他ブランチも含め)歴史を見ることができる。また、本ブログの最後で詳細に述べるがgit reset --hardで過去の状態に戻った場合にも、git reflogコマンドを実行することで、リセットしたログまで残るため('git log'では確認できない)、リセットする前の状態まで戻すことも可能である。

元のバージョンまで戻す

git管理のメリットとして、過去のバージョンに戻れることにある。例えば、新規で開発したものに重大なバグを見つけた場合や、ブランチ管理が正しく行われなかった場合に過去の状態に戻ることができる。

reset

git reset --hard [hash値]

上記のコマンドが筆者が(たまに)行うコマンドである。git log --onelineで取得したハッシュ値を入れることで、その状態まで戻すことができるコマンドである。正直な話--hardオプションは結構危ないコマンドとの認識なので、git resetを行うことがないように慎重にgit管理をしたいところである。

git reset --soft

上記のコマンドでコミットの情報を戻すことも可能だが、筆者はあまりコミットの情報だけを元に戻すことはしないため詳細までは把握できていない(完全に勉強不足)。
詳細を知りたい方は筆者が読んでいて参考になった以下のサイトを確認してほしい。

次のブログでは

次のブログでは筆者が困ったことのある場面別に、解決方法と実行すべきコマンドについて紹介しようと思う。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?