未来電子テクノロジーでインターンをしているりくです。
gitとやらが共同開発するのには必要だそうなので、gitのmergeとrebaseの定義をしてみました。
#mergeとrebaseの比較
##merge
-非破壊的操作である。
-既存のブランチは変更されない
メリット
- 非破壊的なので、情報が消えることはない
デメリット - 頻繁にブランチしたりMasterが動いたりする場合だと、コミットグラフが乱雑する
- 他の開発者が履歴を閲覧しにくい
##rebase
コミットグラフは一直線にきれいになるが、消える情報がある
メリット
- コミットのグラフがきれいになる、不要なmergeコミットが除去される
- GitHubなどのオープンソースプロジェクトにプルリクエストを送る場合はrebaseして送るのが基本(マナー)
デメリット - pushされたブランチをrebaseするとpushできなくなる
- 「マージした」事実がなくなる(情報が消える)
- mergeと比較するとコンフリクト(エラー)解消が面倒
- 中身は同じだが、別物として作成される
#コンフリクトした場合の違い
##mergeの場合
Auto-merging ???
CONFLICT (content): Merge conflict in ???
Automatic merge failed; fix conflicts and then commit the result.
が表示されたら git mergeの処理は一時停止される(mergeの中断状態)
競合した相手と相談しようね。
修正する側は、
git status
で情報を確認する
するとコンフリクト(エラー)の箇所が分かる
Unmerged pathにコンフリクトしたファイルが列挙される
コンフリクトしているファイルが分かれば直接修正する
インデックスにはマージ前のファイル状態が記録されているので、
git add ???
後は、commitすればマージコミットが作成された。
ちなみに、git merge --abortでgit mergeを取り消して中止できる
新たにマージコミットをコミットするか上のことをしないと他のGit操作できないからね。
##rebaseの場合
git rebase master
をしたらコンフリクト発生してもうたら、
git diffでコンフリクトしている部分を確認。
確認後、コンフリクトを修正したらgit add .して、
git rebase --continue
んで、rebase成功。
#まとめ
gitは共同開発以外にも、以前まで使用していたデータを保存できるのも強みだと思うので、これからが楽しみです。