GitM#1に参加してきた。かなり突発的に企画されたせいか、参加人数は控え目だった。けど、逆にそれがいい感じだったかな。
唯一の発表者であるkanaさんのページで発表資料が公開されています。
object周りの話
この辺りは一応知っていた。実際、うまいこと考えられた仕組みだなーと思う。simple is best!
branch周りの話
履歴改変の話が非常にためになった。単に「失敗を隠蔽したい」だけじゃなく、「履歴を見やすくする」ためにもこの作業は重要。
resetはきちんと使えるようになりたい。rebaseはむしろやっておくのは義務な気がした。それくらい重要な機能。
その前に、branchを使うようにしよう。rebase以前の問題。
1人でしか使わないリポジトリではbranchを使う機会がないと言う話が出てふと思ったのだけれど、こういうのはどうだろうか。
branchには名前が付けられる。そして、何か機能を追加したり修正、変更を加えるのに、1コミットでは済まないことは多いだろう。その時、branchを切って名前を付けておけば後から見てわかりやすい。
と思ったけど、masterにmergeしたらbranch名は残らないか。コミットログには残ったかな？
でも逐一branch切っておけば、その機能の実装に飽きて別の機能を追加したくなったら新しくbranchを切れば中途半端な状態でも後からわかりやすいな。この際masterにはmergeしかしないくらいのスタンスでやるのもありかも。
remote周りの話
最近になって一応理解していたつもりにはなっていたけど、それを再確認できた感じ。
以下は独自の解釈。間違ってたら「何を聞いていんたんだお前は」ってことでもう一度勉強しなおさねばならない。
1つのリポジトリにはmasterも含め多くのbranchがあるけれど、remoteはcheckoutできないbranchであると考えるといいのかな。加えて、更新はfetchによる最新の取得のみで行える。あとは通常のbranchと同じで、現在のbranchとmergeできたりする。何か別の空間に分離されてるイメージがあるけれど、通常のbranchと同じ扱いなので構成されるobjectは通常のbranchと同じように.git/objectsにドサッと入ってる。こいつらはfetchした時にできる。*1
あ、そう言えば質問しそびれてたのを思い出した。「ファイルの移動やコピーの情報はどこに記録されているのか」。ここに書いておけば誰かが教えてくれるかも知れないと期待を込めつつ一応今度自分でも調べて見るかー。
*1:相変わらず文章にまとまりがない…
