gitコミット頻度
Svnからgitに切り替えたので、再コンパイルするたびにコミットを増やし始め、テストに合格すると作業をコミットします。結局、私は関数ごとにコミットすることになります。
また、emacs、wordpressなどのgitを使用して他のいくつかのプロジェクトを追跡しています。それらはそれほど頻繁にコミットしていないことがわかります。だから私はあなたがどのようにコミットするのだろうかと思っていますか？
Gitプロジェクト自体（およびLinuxプロジェクトのAFAIK）のガイドラインは、「論理的に分離されたチェンジセット」ごとに1つのコミットです。
これは少し曖昧ですが、プロジェクトに絶えず取り組んでいる場合はおそらく数日ごとにコミットしたくないでしょうし、おそらく関数が変更されるたびにコミットしたくない-ifいくつかの異なるファイルでいくつかの関数を編集した場合、可能であれば、関連するすべての機能を一緒にコミットし、有用なコミットメッセージを提供する必要があります。各コミットで変更されたすべてのコードは関連している必要がありますが、確かに複数のファイルにまたがることができます（おそらくそうすべきです）。
おそらく覚えておきたいのは、コードレビューです。誰かがあなたの作業をマージするかどうかを決定しようとしている場合、各コミットが論理的に含まれ、互いに分離されていれば、導入された作業を処理するのがはるかに簡単になります。これにより、あなた（または他の人）のチェリーピックが効果的に機能します-それぞれに1つの関数が変更された3つのコミットがあるが、それらがすべて何らかの形で結合されている場合-コードベースを壊さずに他の2つなしで1つを適用することはできません-おそらく1つのコミットに押しつぶされます。
また、emacs、wordpressなどのgitを使用して他のいくつかのプロジェクトを追跡しています。それらはそれほど頻繁にコミットしていないことがわかります。
Gitの優れた点の1つは、何度でもコミットできることです。アップストリームコミットを実行する場合は、git-rebaseを使用して複数の関連するコミットを1つの素敵なクリーンコミットにまとめることができます。
結局、私は関数ごとに関数をコミットすることになります
むしろ「git add "関数ごとに、コミットを1つだけ行います。
- 特定のタスクに対してすべての関数が記述または修正されたら
- または、現在の関数が大きすぎて複雑すぎてすぐにコミットに参加できないことに気付いたら、現在「ステージ上」にあるもの（「gitadded」）をコミットできます。これには、現在の変更が作業に含まれません。ディレクトリ。
次に、コミットの数をブランチの目的に関連付けることができます。
- ローカルブランチ：夢中になり、いつでもコミットできます
- 「パブリック」ブランチ（プッシュするブランチ）：
- ローカルリポジトリの場合（選択したグループの人々の場合）：少なくとも非常に小さな「中間」コミットを再グループ化できます
- パブリックリポジトリの場合（すべての開発者、または他のプロジェクトが表示できるように）：コミットを「アクティビティ」または「タスク」で再グループ化して読みやすくするために、インタラクティブなリベースを作成できます。
要するに、「publication考慮事項」は、[〜＃〜] d [〜＃〜] VCS（ "Distributed"のように）で、作成するようにガイドすることができます適切な理由による適切な数のコミット。
コミットすればするほど、 git bisect のバグを見つけやすくなります。
テストに合格するとすぐに、または機能の単位が追加/削除/変更されたとき。
それは本当に依存します。
私がしていることは、あなたがしているように聞こえるので、ローカルで頻繁にコミットすることですが、影響力のあるものをいくつか獲得した場合にのみ、変更をプッシュします。
これにより、作業を確実に保存できますが、他のユーザーのリポジトリが乱雑になることもありません。
私たちのビジネスニーズでは、プログラムのコンパイル時に不安定なブランチにコミットし、単体テストに合格して顧客によってレビューされたときに安定したブランチにコミットする必要があります（不安定なブランチの下にあったとき）。
機能を追加または変更してテストに成功した後、コミットします。または、デスクトップからラップトップに切り替えてコードをプルダウンしたい場合は、コミットしてプッシュします。
あなたがしていることは、私にとって正しいことのように聞こえます。 workingセットアップがあり、何かを台無しにした場合に戻ることができるようにしたいときはいつでも、コミットするのに良い時期です。回帰テストの実行が迅速かつ簡単であるNiceセットアップがある場合、それはかなり頻繁に行われていることがわかります。私にとっては、週に1つ作ることができれば幸いです。
1-コミットは頻繁に行う必要があります。コードを（ローカルだけでなく）リモートリポジトリにコミットすることは、コードが何らかの理由で失われた場合に備えてコードがバックアップされるように、頻繁に実行する必要があります。これは予想よりも頻繁に発生するため、1日の終わりまでに変更をプッシュすることは、潜在的なやり直しを回避し、リモートリポジトリを常に最新の状態に保つために必須です。
2-コミットはきめ細かくする必要があるため、コードベースへの変更が多すぎないようにする必要があります。変更が多すぎるコミットは元に戻すのが難しく、全範囲をカバーするにはコミットメッセージが長すぎる必要があるため、「履歴」の観点からの参照として使用することはできません。
3-コミットには適切なタイトルが必要です。タイトルは大文字で始まり、ピリオドで終わることはできません。一般的に、タイトルは短く、要領を得たものにする必要があります。
4-コミットの説明はオプションですが、持っておくと便利です。