概要
先ページでは自分がよく使う(沼らなければ使わないコマンドが多数)コマンドの一覧を紹介した。本ページでは、職場の上司から「これやっといて!」って言われた時にできずに沼ってしまったシーンを再現し、どのように振る舞うべきかを(自戒の念を込めて)書いていく。
自分がミスした状況
- ローカル上でmasterからブランチを切って作業をしていたが、リモートリポジトリのmasterブランチが更新され、そこから枝を生やすように言われた時。
- 気づいたら変なところからブランチを切っていて、元に戻そうにもようわからなくなってしまった時。
1つ目の事象について
状況をもう少し細かく説明すると、複数人で同時に開発していたが、他者が開発していた部分がクリティカルパスとなっており、masterブランチが自身の生やした部分ではなく、新しいバージョンから生やしてほしいと言われた。具体的には以下のようにするべきである。
ブランチの生やす場所を変えるコマンドはgit rebase
を用いる。(git rebase
に関して知りたい方はこのページを参照したい)
方針としては以下の通りである。
- developブランチにチェックアウトする
- rebaseを行う
- このとき、コンフリクトが起こる(可能性がある)ためコンフリクトを一つずつ解消していく
- rebaseができたら、リモートリポジトリにプッシュする
以上が大まかな流れである。それを表したコマンドが以下のようになる。
> git checkout develop
> git rebase master
> git rebase --continue
> git branch
> git add .
> git commit -m "comment"
> git push -f origin master
となる。git branch
を行なった理由として、筆者は現在いるブランチが予定通りのところにいるか心配で確認したくなるからである。(念には念を押している)上記コマンドが分からなかった人は、ぜひこのブログを見て確認してほしい。
2つ目の事象について
自身でも何が起こったかよくわからない状況だったが、タスクごとにブランチを切って作業をしており、何回かのコミットの後で切った元のブランチ(下図だとmaster)にマージをしようとしたがなぜかうまくいかなかった。(再現不可能のため説明能力はかなり低い。。。)求められていたことは、自身が行ったタスクが今後のクリティカルパスになり得るため、「developブランチをmasterにマージ」もしくは「developブランチで回収した情報をmasterブランチにも反映させる」ことであった。
問題点として、何故かdevelopブランチからマージを試みた時に(恐らくコンフリ等が起こり変な操作を自分がしたことによる、もしくは別のブランチから間違えてdevelopブランチを生やした可能性もある)ブランチがグチャグチャになってしまったことで、元に戻すのが厄介になってしまったことである。
非常に簡潔に書いたが、前提としてdevelopブランチのログがグチャグチャになっていたことである。このタイミングで私はgitの強者にcherry-pick
という技を学んだ。行いたい流れは以下の通りである。
- developブランチにチェックアウト
- logを確認し、masterブランチに反映させたい部分のハッシュ値をメモする
- resetを行い、developブランチを切るタイミングまで遡る
- cherry-pickを用い、メモしたハッシュ値を用いてdevelopブランチで改修していた部分を反映させる
cherry-pick
の本来の使い方とは異なるかもしれないが、非常に便利だということを学んだ。上の流れを踏まえたコマンドが以下の通りである。
> git checkout develop
> git log --oneline
# メモするのはAのハッシュ値(a_hashとする)とZのハッシュ値(z_hashとする)
> git reset --hard a_hash
> git checkout master
> git cherry-pick a_hash..z_hash
git checkout master
を行なった理由としてgit reset --hard a_hash
を行った時にその時点でいるブランチがどうなっているか不安だからである。上記コマンドが分からなかった人は、ぜひこのブログを見て確認してほしい。
終わりに
一通りgitに関することを書いてきたが、今回触れたのはコマンドのほんの一例で自分が用いていないコマンド(GUIに頼ってしまっていたりする)があるため、そこの部分についてはまた別の機会に学習してまとめていこうと思う。
gitの初歩的なところからこのブログまでは実務において自身が役に立った部分にとどめており、少しでも多くの人がgitで苦しまないようになってほしいという思い(+自分の備忘録として)から書いている。役に立つことを望んでいる。