Gitコマンド入門::Gitブランチ機能(管理機能)第六十五回
みなさんこんにちは！ まあ～、いまさらここまできて改めて思うのですが、やっぱり基本からですね。で、何が基本なのかといえば、実務ではマージ処理。ここが一番大変な作業です。そして、今回も引き続き、ブランチとマージの学習を行って行きますね！
前回、第六十四回の記事はこちらから！
git本家本元の情報はこちらから！
今回からの課題は、ここを参考にしています！
3.3 Git のブランチ機能 - ブランチの管理
いつもの初期化！
mkdir func0065 && cd $_
# いつもの git init
git init
# README.md を作成！
echo "func0065" > README.md
# add,commit
git add README.md
git commit -m "1st"
# master ブランチから、subブランチ作成
git checkout -b sub
# sub.txt を作成！
echo "3rd sub" > sub.txt
echo "func0065 sub" > README.md
// README.mdを編集して、コンフィクトが発生するようにしました！
# add,commit
git add sub.txt
git add README.md
git commit -m "3rd sub"
git switch master
# ブランチ名を、master から、main に変更！
git branch -M main
# main.txt を作成！
echo "2nd main" > main.txt
echo "func0065 main" > README.md
// README.mdを編集して、コンフィクトが発生するようにしました！
# add,commit
git add main.txt
git add README.md
git commit -m "2nd main"
こちらにも、UPしてあります！
git branch --no-merged, --merged
これ、--no-merged オプションって当たり前すぎて、さらに感慨深いのですが、ローカルでブランチを作成したら、その自己責任を取られる訳なんですよね。当たり前すぎるのですが、きっと、そういった案内や警告をださないと、逆に作業が抜けてしまうことになるのでしょう。散らかしたら、後片付けしなさいって、幼稚園の先生にも、怒られた記憶ありますね～(^▽^;)
$ git switch main
Already on 'main'
$ git branch --no-merged
sub
// マージする以前なので、sub ブランチが表示されました！
// それでは、subに切替えて！
$ git switch sub
Switched to branch 'sub'
$ git branch --no-merged
main
// マージする以前なので、main ブランチが表示されました！
たった、これだけの事ですが、ローカルブランチを複数作成して作業をしていると、おそらく混乱してくるので、マージのし忘れをなくし、敢えて、マージしないなら、ブランチを削除するおうな、お行儀、躾けをしてくれるんでしょうね。（笑）
いよいよマージですが、README.md を、mainとsubブランチで変更しましたので、コンフィクトになりま～す！
$ git switch sub
Switched to branch 'sub'
$ git merge main
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
$ cat README.md
<<<<<<< HEAD
func0065 sub
=======
func0065 main
>>>>>>> main
// それでは、sub 側の編集を採用します！
// viエディターで、以下のように編集！
$ cat README.md
func0065 sub
$ git add README.md
$ git commit // <!-- -m "コメント" を省略して起動！
[sub a58ed69] Merge branch 'main' into sub
// viエディターが起動して、勝手に以下のコメントをお勧めてしてくれます。
// せっかくなので、そのまま、利用しますね。
$ git log --oneline --graph
* a58ed69 (HEAD -> sub) Merge branch 'main' into sub
|\
| * d4b3400 (main) 2nd main
* | c4b0cb1 3rd sub
|/
* 769368e 1st
$ git branch --no-merged
// 何も表示されません。
$ git branch --merged
main
* sub
// main,sub がマージされたと表示されますね。
// では、ローカルmainブランチに切り替えて！
$ git switch main
Switched to branch 'main'
$ git log --oneline --graph
* d4b3400 (HEAD -> main) 2nd main
* 769368e 1st
// main側からみたら、当然ですが、subブランチは、マージしていませんね。
$ git branch --no-merge
sub
では、今度は、main側から、subをマージします！
$ git merge sub
Updating d4b3400..a58ed69
Fast-forward
README.md | 2 +-
sub.txt | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
create mode 100644 sub.txt
// Fast-forward になりましたね。
[shiozumi@ovs-009 func0065]$ git log --oneline --graph
* a58ed69 (HEAD -> main, sub) Merge branch 'main' into sub
|\
| * d4b3400 2nd main
* | c4b0cb1 3rd sub
|/
* 769368e 1st
$ git branch --no-merge
$
// マージされたので、何も表示されず。
$ git branch --merge
* main
sub
// マージされたので、main,sub ともに表示！
$ git branch -avv
* main a58ed69 Merge branch 'main' into sub
sub a58ed69 Merge branch 'main' into sub
// ハッシュ値も同じになりました。
$ cat README.md
func0065 sub
// ちなみに、sub側でマージすると、
// main側では、README.mdは、コンフィクトにならず、
// そのまま、sub側の編集となりましたね。
ここでの、若干の疑問点ですが・・・
sub側でマージしたときに、README.mdを、sub側の方の内容で修正したので、main側でマージしたときに、また、コンフィクトになるかと予想していたのですが、どうやらそうではありませんでしたね。その理由が、sub側のブランチ処理を優先する仕様となっているのか？ その他の理由があるのか分かりませんけど、いまのところ、私には説明できないです。(^▽^;)
ここからは、推測ですが・・・
恐らく、一度、コンフィクトしたファイルを修正してコミットしたら、他のブランチで変更が無い限り、それが最終バージョンだと見なすのでしょう。まあ、少なくても、ローカル作業で、それが自分一人で行うならば、コンフィクト後のファイル修正とマージ処理は、各自がしっかり責任を持って行う作業ですしね。普通に考えたら、それがデフォルト仕様でよさそうですね。
それでは、今回はここまで、お疲れ様でした！
Discussion