🏹

Gitコマンド入門::Gitブランチ機能(管理機能)第六十五回

4 min read

みなさんこんにちは! まあ~、いまさらここまできて改めて思うのですが、やっぱり基本からですね。で、何が基本なのかといえば、実務ではマージ処理。ここが一番大変な作業です。そして、今回も引き続き、ブランチとマージの学習を行って行きますね!

前回、第六十四回の記事はこちらから!

https://zenn.dev/shiozumi/articles/fb5c76c2f7e2af

git本家本元の情報はこちらから!

https://git-scm.com/book/ja/v2

今回からの課題は、ここを参考にしています!

https://git-scm.com/book/ja/v2/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してあります!

https://gist.github.com/2e918daa8819860b2a8fe90d8e6a0ae3.git

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側のブランチ処理を優先する仕様となっているのか? その他の理由があるのか分かりませんけど、いまのところ、私には説明できないです。(^▽^;)

ここからは、推測ですが・・・

恐らく、一度、コンフィクトしたファイルを修正してコミットしたら、他のブランチで変更が無い限り、それが最終バージョンだと見なすのでしょう。まあ、少なくても、ローカル作業で、それが自分一人で行うならば、コンフィクト後のファイル修正とマージ処理は、各自がしっかり責任を持って行う作業ですしね。普通に考えたら、それがデフォルト仕様でよさそうですね。

それでは、今回はここまで、お疲れ様でした!

https://zenn.dev/shiozumi/articles/c9a40a20c9b7f7
https://twitter.com/esmile2013

Discussion

ログインするとコメントできます