##基本は右クリック＞競合を解決
警告マーク⚠️（三角にビックリマーク）が付いているコミットを右クリック＞競合を解決で以下の選択肢が出る。
- 自分の変更を使って解決
- 相手の変更を使って解決
マージする時には基本はmaster、develop、releaseブランチなどの元のブランチに自分の変更を加えて機能追加しているはずだから、基本は「自分の変更を使って解決」を選ぶことになるが、それによって該当コードが変になったり、自分のブランチのベースとなるコミットから、他のチームメンバーが別の変更を加えていて先にマージ済みの時にそれを壊してしまったりするので、右側ウィンドウのgitの差分表示（diff）でキチンと確認する必要がある。
<<<<<< HEAD
someMethod() {
print("hoge")
}
=====
someMethod() {
print("fuga")
}
master >>>>>>
ここでいう<<<<<< HEAD ~ ====が自分の変更で、==== ~ master >>>>>>がマージ先である相手の変更となる。後の方で説明するリベース時も「上段（HEAD）が自分、下段が相手」という原則は変わらない。
##コード自体を修正したいとき
自分と相手、どっちかで解決するかではなく、そもそもコードを手動で修正したいときはSourcetreeのコミットをダブルクリックしてもその該当ファイルをエディタで開いてくれる。ここでコードを修正してその後（コミットをステージにあげて）コミットしようとすればOK。「マージの途中です」といったメッセージが出て「マージを続ける」を選択すれば無事にマージできるはずだ。
##リベースの時は自分と相手が逆になるので注意
ただ初心者エンジニアだとマージを担当することはほぼなくGitHubなどにPRを送って、上司や先輩エンジニアにマージしてもらうことになるだろう。なのでどちらかというとマージよりもリベースすることの方が圧倒的に多いはずだ。注意が必要なのはリベース時は上記の「自分」と「相手」が逆になってしまうことである。
<<<<<< HEAD
someMethod() {
print("fuga")
}
=====
someMethod() {
print("hoge")
}
hot-fix/print-fuga-to-hoge >>>>>>
リベース、すなわちベースとなるコミットを変更するので、視覚的に例えるなら一度生やしてきたブランチの上を根元（木の幹から分岐したところ）まで歩いて戻って、幹の上の方にあるリベースしたいコミット（新しいベース）まで進んで、そこからこれまで変更してきたコミット（コード）を見る感じだ。なのでリベース時は「自分」はリベースしたいコミットであり、「相手」は自分が変更してきたコミットとなる。