未来電子テクノロジーでインターンをしている箕牧和廣です。
今回はGitのmergeとrebaseについて書いていこうと思います。
プログラミング初心者であるため、内容に誤りがあるかもしれません。
もし、誤りがあれば修正するのでどんどん指摘してください。
mergeの特徴
- mergeで結合した場合、ブランチのコミットが全て記録される
- コミットグラフが乱雑
rebaseの特徴
- rebaseで結合した場合コミットグラフは綺麗な一直線になるが、消える情報がある
- pushされているブランチをrebaseするとpushできなくなる
- GitHubなどのオープンソースプロジェクトにプルリクエストを送る場合は、rebaseしてから送るのがマナー
コンフリクトの解消法
変更内容を統合する際に、同じファイルの重複する部分が変更されていると、変更同士が衝突し「コンフリクト」と呼ばれる状態が起こる。
コンフリクトが起きたままだと処理が一時停止になるため、コンフリクトの解消が必要になる。
merge
git merge 『branch名』
でmergeした結果
Auto-merging ???
CONFLICT (content): Merge conflict in ???
Automatic merge failed; fix conflicts and then commit the result.
このような画面が表示されたら、コンフリクトが起きている証拠。
コンフリクトが発生したらgit status
でコンフリクトの箇所を確認。
コンフリクト箇所は、作業ツリーのファイル内で、<<<< HEAD
====
>>>> topic
によってハイライトされているので、ファイル内で>>>>
などと検索すると、問題の箇所がすぐに見つかる。
Unmerged pathにコンフリクトが発生したファイルが列挙されるので、そこでファイルを特定して修正。
インデックスにはmerge前のファイル状態が残されているので、修正したファイルをgit add
する。
git commit
を実行すれば、コンフリクトを解決したマージコミットが完成。
また、一度実行したmergeを途中で取り消したい場合はgit merge --abort
とすれば取り消せる。
rebase
git rebase master
をした結果コンフリクトが発生したら、git diff
でコンフリクトの箇所を確認。
mergeと同じ流れでコンフリクトが発生しているファイルを修正し、git add
する。
最後にgit rebase --continue
を実行すれば、コンフリクトを解決したリベースコミットが完成。
共同開発の側面から見た時
rebaseを使うと「誰かが上げたコミットがなくなってしまう」という危険性がある。
ローカル開発環境であればrebaseしても大丈夫ですが、pushして誰かの目に触れた処理や他の人の手の入っている箇所では、rebaseではなくmergeを使用するのが良い。