commit をどう分割すべきか 〜コードレビューの観点から〜
普段の開発の中で git の commit の単位に気を遣っている人もいると思うんですが、どういう単位で commit すべきかみたいな話をあまり見かけない気がします。自分自身 GitHub の Pull Request（以降 PR）ベースのチーム開発を何年か経験してみて、「こうすると良さそう」というものが見えてきた気がするのでまとめてみました。 なお、小さい単位で PR を出す方針にしている場合は、以降の内容に出てくる commit を適宜 PR で読み替えてもらうと良いかもしれません。 そもそも commit の単位に気を遣った方が良いのか？ コードレビューを行う場合など、他者がコードを読む場合はある程度気を遣った方が良いと思っています。理由は次のとおりです。 コードレビューにおいてレビュアーのレビュー時間が短縮できる コードレビューの精度が上がる 変更の経緯を追いやすい 自分にとって
Linus Torvalds氏によるGitの内部構造の解説 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 初めに LinusによるGitのinitial commitのREADMEの訳です。 社内のSVNからの移行を促すために資料を整備していたのですが、SVNでやっていたことを移し替えたりコマンドを覚えたりするより内部構造を知ったほうが早いことに気づきました。 それで、gitの内部構造についての解説資料を色々見ていたのですが、データ構造については原作者のこのREADMEに言い尽くされている気がします。のみならず、gitを使うものが抱くべき精神性のようなものが示されており、深い感銘を覚えました（ヒャッハー）。 README: ”GIT - 馬
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
