目次
概要
昨年、Gitの基本ついて下記記事を社内勉強会で発表した。 daisukeinoue.hatenablog.com
今年も続編としてGit基礎を発表をすることにしたので、Conflict・cherry-pick・rebase辺りについて以下に纏める。
Conflict（コンフリクト）
Conflictとは？
- Merge先ブランチとMerge元ブランチにおいて、同じファイルの同じ行を互いに改修する事で、相反する内容になってしまっている状態の事。
- Gitからすると「どっちが正しいの？」な状態。
- Mergeする際に起こる。
- なお、パワポやエクセル等のバイナリファイルの場合は、
step（行数）という概念が無いため、同ファイルを改修した時点で改修箇所に依らずConflictを起こす。
解決方法は？
- 手動でファイルを書き直し、再度CommitすればOK。
cherry-pick（チェリーピック）
cherry-pickとは？
- 任意のブランチの任意のCommitを、別ブランチに反映する事。
- 下記図の状態の場合に、ブランチBのCommitA・BだけをブランチBに反映した際、ブランチBをブランチAにMergeしてしまうと、不要なCommitCも反映されてしまう。このような場面で
cherry-pickを利用すれば、CommitA・Bだけ反映する事が可能。
- ある版数（Ver）に対してパッチしたバグ改修を、別版数へ反映（横展開）したい際などに有用。
rebase（リベース）
rebaseとは？
- Mergeと同じく、Commitをあるブランチから別のブランチに統合する事。
- Mergeとはその方法が異なる。
Mergeとの違いは？
下記状況の場合で説明。
Mergeを実行すると
MergeCommitが打たれる。
2本の枝が1本に纏まるイメージ。
rebaseを実行すると
featureブランチがmainブランチの先頭から生えている形になる。
featureの生え元を、mainブランチの先頭に移動させ、1本の綺麗なブランチに整えるイメージ。
rebaseのメリット
主なメリットは、MergeCommitが打たれない事や、ブランチが1本線になる事により、ブランチ履歴が非常にすっきりして綺麗になる事。
rebaseのデメリット
rebaseの正体（裏側での動きは）は、featureブランチで打ったCommitを、mainブランチの先頭から生やした新規ブランチにcherry-pickをしている。
そのため、元CommitとCommitハッシュ値（リビジョン）が異なってしまうというデメリットが有る。
他にも細々したデメリットが有るため、使用する際は要注意。
