Gitについて_2
目次
概要
昨年、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ハッシュ値(リビジョン)が異なってしまうというデメリットが有る。
他にも細々したデメリットが有るため、使用する際は要注意。