gitでコミットするタイミングがわかりません

質問

gitやsubversionでコミットするタイミングというのがイマイチよくわかりません。
githubであがってるようなやつは、どのコミットも機能追加はバグ修正を行った後の「動くもの」ばかりです。
私は今日追加した分とか、バックアップ代わりにちょっとコミットとか、作りかけで動かないものもコミットしてしまいlogをみても汚いなーと思ってしまいます。
このような使い方は間違ってるのでしょうか？
githubにあるようなやつは新機能やバグ修正が終わるまでコミットしないようにしてるのでしょうか？それだと「今日の分」とかのバックアップはどうしてるのでしょうか？

ご教示頂けますと幸いです。

回答No.3

RyoSuzuki

trunkにはビルドが通るものを入れるのが基本的なマナーです。
trunkは製品となる最新版のものを入れておくものです。

個人用のbranchや個人用のレポジトリにはできるだけ高い頻度でコミットしたほうが良いです。
間違えて消してしまった時やリファクタリングに失敗して戻したくなった時の保険になるからです。

グループで開発するときは最低1日1回はマスターのtrunkにコミットしましょう。

回答No.2

Wr5

個人で使っているなら好きに使え。というのに賛成…ですね。

私自身はGitではなくSubversion使っています。
リポジトリの使用者も私一人なので、好きに使っていますが…

一応、「ビルドが正常に通る状態」で区切りがついたときにコミットすることが多いですね。
たまに「ビルド未確認」でコミットすることもありますが。
その場合は、コミットログにビルド未確認とコメント入れておきますね。
で、後ほどビルド確認したものをコミット…です。(修正ナシでビルド通ればコミットしようもありませんけど)
# ン週間後とかの自分に向けたメモみたいな扱いです。
# まぁ、見やすいようにある程度のフォーマットでコミットログ書いていますが。
# Tracも入れてあるけど…連携意識して居ないので片手落ちです。

機能追加…とかの場合は都度都度ブランチ切ってそっちで作業しています。
# 大規模なバグ修正の場合も気合い入れるつもりでブランチ切ることがあります。
目処がついたらマージしてコミット。
作業に使っていたブランチはそのまま放置です。
マージしたあとで不具合があった場合は…トランクの方でそのまま修正しています。
# ブランチ側で修正して、再マージ…の方が本当はいいんでしょうけどねぇ…。
# 機能ブランチが複数になると不具合箇所も分散されるので…。
まぁ、ブランチ側でなるべく動作検証して不具合を潰しておくように努力はします。

そんなワケで……日にち日にちでのバックアップはあまり意識していませんね。
一人で使っているから別に問題になりませんが、複数人で使う場合は「ビルドも出来ない状態」でコミットすると他のメンバーが困る可能性がありますし。
# そうならないようにチーム内で運用ポリシーがある………はずです。

回答No.1

LOHA

一応、集約型と分散型は分けて考えたほうがよいかと思います。
特に分散型ならcommitとpushを使い分けることもできるので。

私の場合、git（と言うか分散リポジトリ）であれば、pushするのは一応ちゃんと動くときにしてます。
commitは、一日の終わりとか、キリが良い時とかにもしてますね。
＃そもそも個人の適当なプロジェクトなら、ある程度形が見えるまではバージョン管理してなかったりしますが（せいぜい日付zip）。
＃Subversionは殆ど使ったことないので略。

＞このような使い方は間違ってるのでしょうか？
企業の場合はおそらくポリシーとかあるのだと思いますが、個人の場合は好きに使えば良いと思いますよ。

＞githubにあるようなやつは新機能やバグ修正が終わるまでコミットしないようにしてるのでしょうか？それだと「今日の分」とかのバックアップはどうしてるのでしょうか？

以下を参考にすると良いかもしれません。
http://d.hatena.ne.jp/ikeike443/20101128/p1