[git]rebaseがよくわかっていない

もう一度、新規featureをつくって、commitやpushを何回か行って、feature完了処理をした。
今度は期待通りになった。

featureブランチの削除をしたので、ローカルでは消えている。
だが、remoteにpushしたブランチまでは削除しないようで、残っている。

 

よしよし期待通り、と思い、githubの方を見てみた。

あれ、developブランチを見てるのに、featureブランチの方のコミットも出てきている？？
なして？？？

---

うん、rebaseを理解できていないことがわかった。
いくつかのサイトを見たけど、mergeだと「く」の字型に履歴が残るけど、rebaseだと一本線になる、というような説明だったので、そういうものだと思っていたのだが、たぶんもう少し理解しないといかんのだろう。

Gitを使いこなすための20のコマンド 5ページ | OSDN Magazine

これの「コマンド18」がrebaseの説明になっている。
ここの図は、今まで見てきたサイトとは違うな・・・。
一本線になるというよりも、ベースラインが変更になるという感じだ。
だからrebaseという名前なのか。
私のrebaseのイメージは「時間がふっとばされて結果だけが残る」だったけど、そうじゃないんだ。。。

しかし、rebaseした場合、それより以前にブランチしていた人達は大丈夫なんだろうか？
何本か接ぎ木したうちの1本が幹として成長したことになるので、なんか変な気がするけど。。。
でも、それを言うなら「接ぎ木したうちの1本を折って、先っちょに挿した」みたいなことになるのか。
ならば、別に関係ないのか。

---

ただ、「rebaseで複数のcommitをまとめる」という記事がたくさん出てくる。
それと「pushしたものをrebaseするのはよくない」という記事も出てきた。

まだ内容は読めていないのだが、「何度もcommitしたくて、でも最後のコミットだけ見せればいいような場合は、pushせずにローカルでcommitする生活をして、最後にrebaseでまとめてからpushしよう」ということなのかな。

あとはプロジェクトとして、ファイルと担当者がなるべく一意になるようにして、自分の作業はファイル内で収まるように割り振るのがよいだろう。
他のファイルをいじりたくなったら、開発中はその人に依頼をかけるようにするとか。
ホームページとかだとよくわからないけど、組込み系だと機能ごとにファイルを分けることが多いので、そんな感じでもいいんじゃないかね。