動機
git戦略でよく見かける、main, develop, hotfixというブランチがあります。
その運用について特に異論はないのですが、hotfixでの作業をdevelopブランチへ反映する方法を変えてみた場合、versionアップリリース時 main に develop の変更を反映する際どのような挙動になるのか気になったため、簡単に作業してみようと思います。
主に、cherry-pickでコミットハッシュが別となる場合の挙動を調べるモチベーションです。
<前提>
- mainから3つほど作業が進んでいるdevelopブランチがある
- → ver1.0としてmainがリリースされ、developで時期リリースに向けた開発を進めている想定
- リリース後、早急に対応したいバグが発見されたので、main ブランチ から hotfixブランチを切ってバグ修正作業をする
- 作業後、hotfixの作業をmain, developに反映する ← このdevelop反映で merge or cherry-pickを選択する
<テスト内容>
- hotfixをdevelopにもmergeする
- developから、hotfixの変更をcherry-pickする
作業開始
① main, develop双方にmergeする場合
1.まずはブランチを用意、初期コミットをします。
今回はindex.htmlを作成するのみです。コードは以下だけ。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
<h2>first commit</h2>
</body>
</html>
ブラウザでは画像のように見えています。
2.developブランチを作成、作業をしていきます
コードはこんな感じ
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
<h2>first commit</h2>
+ <h3>second commit</h3>
+ <h4>third commit</h4>
</body>
</html>
履歴は画像の通り
3.hotfixを切る
mainで早急に対応したいことがあり、hotfixで作業します。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
<h2>first commit</h2>
+ <p>hotfix commit</p>
</body>
</html>
さて、これで準備ができました。
現在の状態としては、
main: first commit
dev : first commit -> second commit -> third commit
hot : first commit -> hotfix commit
この太字部分で差異が発生しています。
よって、hotfix commit を main および developに反映してみます。
まずはmainにマージします。特に問題ないです。
developにマージしようとしますが、やはりコンフリクト発生します。
エディタで直します。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
<h2>first commit</h2>
<!-- 両方の変更を取り込みました -->
<p>hotfix commit</p>
<h3>second commit</h3>
<h4>third commit</h4>
</body>
</html>
コミットしてリモートのdevelopにpushします。
これで、マージが完了しました。マージの場合、hotfix commitのコミットハッシュはdevelop / mainで同じことがわかります。
↓main(再掲)
では、developブランチからmainに対してプルリクエストを作成してみます。
少しわかりにくいですが、コミットハッシュが同じhotfix commitについて差分は出てきません。
githubがその辺をよしなに解決してくれています。コンフリクトも起きません。
マージを完了すると、以下のような履歴になりました。
cherry-pickをする
さて、次はhotfix -> develop への反映を、developからcherry-pickするという流れで行ってみましょう。先ほどのhotfix作成、mainへマージまでの流れは同じです。
mainにはhotfixをマージしており、developでは別の変更が進んでいます。
では、hotfix commit の コミットハッシュをcherry-pickしてみましょう。
(develop)> git cherry-pick ff8085b5e09982eba78b2747f0e2dc8f4c7627e9
先ほどと同様、コンフリクトが発生しました。
両方の変更を保持したいので、今回も組み合わせを受け入れます。
すると、以下のような履歴になります。
hotfix commit というコミットはなさそうです。
マージした時は以下のようになっていました。
cherry-pick時と比べてみると、mergeコミットは多いですが、hotfix commitはhotfix commitのまま履歴に残っていました。
中身はこんな感じです。
どうやら、cherry-pickをすると新しいコミットとして履歴に追加され、mergeをするとそのままのコミット + merge コミット という履歴になりそうです。
さて、ここでdevelopからmainに向けたプルリクエストを作成してみましょう。
main, develop双方にマージした場合、特にコンフリクトは起きませんでしたが、今回はコンフリクトが起きてしまっています。
エディタで確認してみましょう。
(main)> git merge develop
やはりコンフリクトが起きています。
とりあえず変更を取り込み、mainにpushしてしまいます。
最終的な履歴は以下のようになりました。
mergeした方(再掲)
正直あまり履歴に大きな差はなさそうです。変更が簡単だったこともあると思いますが。
ただ、cherry-pickを利用すると同じ変更内容なのに違うコミットハッシュで履歴に残ります。
その結果、mainとdevelopではほぼ確実にコンフリクトが発生することになり、次回リリース時にその解決をすることになりそうです。
特に問題なければいいのですが、リリース時にコンフリクト解決などデリケートな作業は避けたい気持ちがあり、個人的には特に理由がない限りmain, develop双方にmergeで良いのではと思いました。
同じコンフリクト解消作業を2度行っている気もしますし。
※間違った認識であればコメントください！自信はありません。。
また、今回はmainにdevelopを反映する際マージをしましたが、rebaseする場合でもまた挙動が変わってきそうです。（developをmainにリベースする感じでしょうか？）
その場合、hotfixの上にdevelopの変更が乗っかるのかなと思いますが、今度試してみようと思います。（が、force pushをすることにはなるので、develop全体のコミットハッシュが変わるの怖いかもですね。。）
最後に
というわけで、雑ですがgit branchの管理について実験してみました。
安全なgit操作を身につけ、自身を持って作業できるようになりたいものです。
何かの参考になれば幸いです。