Git入門#10(マージをしてみよう)




cocomaru
じゃあ前回、作成したブランチをマージして取り込んでみよう!
hiromin
うん!お願いします!
cocomaru
あ、後、マージにはいくつか種類があって、「Fast forward(早送りになるマージ)」と、「Auto merge(基本的なマージ)」があるんだ。今回はその両方を教えていくね!
hiromin
へ〜違いとかあるんだね〜?!じゃあ頑張って覚える〜!ι(`・-・´)/

featureブランチのマージの前に…?!

どうも、cocomaruです。
今回はマージについて説明していきます。

前回から実際に進めて頂いている方は、今のブランチの状態は以下のようになっています。

この状態から、featureブランチの内容を取りこんでいきたいと思います。
しかし、取り込もうとした際、あなたは上司から「index.htmlに不備があったから急いでなおしてくれ」といった指示を急遽頼まれたとしましょう。

今、あなたはmasterブランチにいるので、そこから修正用のブランチ「hotfix」を作成します。以下のように実行してみてください。

# 修正用のブランチを作成して移動も同時に行う。 
$ git checkout -b hotfix
Switched to a new branch 'hotfix'
プログラムの修正を行う際、よく「hotfix」という名前でブランチが作成されます。「hotfix」とはソフトウェアに不具合があった際に修正されたプログラムの事を言います。

hotfixブランチを作成後の状態は以下になります。

ブランチを作成したら、次はindex.htmlの修正ですね。

今回の修正内容は「git」の文字を「Git」と大文字に修正する、という内容としましょう。

~/Desktop/WorkDir/index.html
<!DOCTYPE html>
<html lang="ja>
<head>
  <meta charset="utf-8">
  <title>Git入門</title>
</head>
<body>
<p>Git statusの練習</p> <!-- 大文字に変更 ※これはコメントですので記載しなくて大丈夫です。 -->
<p>Git diffの練習</p> <!-- 大文字に変更 ※これはコメントですので記載しなくて大丈夫です。 -->
</body>
</html>

修正したら、ステージング・エリアに追加してコミットしましょう。

# ステージング・エリアに追加 
$ git add index.html

# 修正をコミット 
$ git commit -m "gitをGitと大文字に変更"
[hotfix 3754deb] gitをGitと大文字に変更
 1 file changed, 2 insertions(+), 2 deletions(-)

現在のブランチの状況は以下の図のような構成になっています。

hotfixブランチをマージしてみよう

さて、ここまで出来たらいよいよ、masterブランチに修正内容を取り込みます。

git merge <ブランチ名>

変更内容を取り込むにはマージする必要がありますが、マージは「git merge <ブランチ名>」で実行できます。

ではマージを実行してみましょう!

# masterブランチへ移動 
$ git checkout master
Switched to branch 'master'

# hotfixブランチをmasterブランチへマージ 
$ git merge hotfix
Updating e033a11..3754deb
Fast-forward
 index.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

# index.htmlはhotfixの修正が反映されていること確認できた 
$ cat index.html
・
・ 中略
・
<p>Git statusの練習</p>
<p>Git diffの練習</p> 
・
・

マージした際、「Fast-forward」というワードが表示されたかと思います。

Fast forward

masterブランチから、hotfixブランチが分岐され、分岐後に元のブランチ(master)に変更がないときにマージを行うと「Fast forward」がされます。

文章だとイメージしにくいと思うので、図で見てみましょう。

上図のように、masterブランチへhotfixをマージした際、実際にはmasterブランチに修正情報を取り込むのでなく、masterブランチのポインタをhotfixで修正した時のコミットに対して進めているだけなのです。

このマージのことを「Fast forward」と言います。

featureブランチをマージしてみよう

では無事にhotfixブランチの内容がマージされましたので、次は前回作成したfeatureブランチの内容をマージしてみましょう。
前回は「new.html」ファイルを作成して保存しましたね?!

# 今いるブランチがmasterブランチかどうか確認 
$ git branch
  feature
  hotfix
* master

# masterブランチにいることを確認できたので、featureブランチの内容を反映 
$ git merge feature
Merge made by the 'recursive' strategy.
 new.html | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 new.html

# 「new.html」があることを確認 
$ ls
index.html new.html

# ログから「hotfix」と「feature」ブランチの編集内容が反映されていることを確認 
$ git log --oneline
f6bc3d0 (HEAD -> master) Merge branch 'feature'
3754deb (hotfix) gitをGitと大文字に変更
66ddb3b (feature) 新規ファイル作成
e033a11 git diff練習用に1行追加
dec7055 git status練習用に1行追加
577fbc4 index.htmlを追加

マージを実行したら、以下の画像の表示がされませんでしたでしょうか?

先ほどの「Fast forward」と違い、コミットログの画面が表示されました。

これは一体、なぜでしょうか?

Auto Merge

「Fast forward」は分岐元のmasterブランチに変更がない時にマージするとされるものでした。

しかしfeatureブランチをマージする時は、hotfixの修正内容が反映されたため、featureブランチをmasterブランチから作成して分岐した時から、masterブランチの内容は変更されてます。

この時にマージを行うと実行されるのが「Auto Merge(基本的なマージ)」と言います。

図に表してみましょう^^

これで今まで作業してきたブランチがmasterブランチへマージされました。

ではもう「hotfix」と「feature」ブランチは不要となったので削除しましょう。

git branch -d <ブランチ名>

以下のコマンドを実行してください。

$ git branch -d hotfix
Deleted branch hotfix (was 3754deb).

$ git branch -d feature
Deleted branch feature (was 66ddb3b).
削除する際にmasterに分岐されていないとエラーが起きます。
「マージはしたくないけど削除はしたい」という時は
git branch -D <ブランチ名>
と大文字の「-D」を指定すると強制的に削除ができます。

このようにマージ済みのブランチは、もう不要になったので削除するという事を意識してみましょう!

ポイント
  • マージとは、ブランチを統合すること
  • マージには「Fast forward」と「Auto merge」という仕組みがある
  • マージ後、不要になったブランチは削除する

不要ブランチ削除後の状態


cocomaru
今回、マージしてみたけど、これでブランチの作成・移動・マージの一通りの説明は終わったかなっ!
hiromin
cocomaruお疲れー!なんかね、ブランチを知ると、Gitのよさが分かった気がする。
cocomaru
それはよかった♪こういった感じで、機能の追加や改修の時に、ブランチを作って、masterにどんどん取り込んでいく、という流れで開発を進めていけば良いかなと思うよ^^
cocomaru
だけど、これでは終わりじゃないんだなー!次はコンフリクト(競合)について教えないとねっ。
hiromin
コンフリクト?!なにそれ?!
cocomaru
簡単にいうと、自分の修正と、他の人の修正が被ってしまって、マージができない状況の事を言うんだ。コンフリクトの解決方法を知らないと開発が進めれないから、解消方法は知っておかないとね!
hiromin
はーいぃぃ!わかりました!

さて、ブランチの講習も2回目ですが、みなさん如何でしょうか?

まだまだブランチについては続きますが、分からないところがあればご質問くださいね♪

では、また次回もお願いします!

Git入門#11(コンフリクトを解決してみよう)

2018.08.12








コメントを残す

メールアドレスが公開されることはありません。