コードで重要でないタイプミス（たとえば、print（error）ステートメントの誤ったアポストロフィ）に遭遇した場合、そのエラーを解決するためにコミットする価値がありますか、それともそのままにしておくべきですか？

具体的には、これらの重要ではないタイプミスを解決する価値に対して、コミットログのガムアップを比較検討することに興味があります。私はそれらを解決することに傾いています。私はつまらないですか？

私の個人的な感じは、小さな改善であっても、品質を改善することは、追加のコミットログエントリのマイナーな不便の価値があるということです。結局のところ、壊れたウィンドウ効果を考慮に入れると、小さな改善が非常に重要になります。

TRIVIAL:タグをプレフィックスとして付けるか、VCSでサポートされている場合は簡単にマークすることをお勧めします。

あなたはつまらないものではなく、それらを個別に解決する方が良いです。変更がよりアトミックであればあるほど、クラッシュするバグ修正が500のコメント/タイプミスの変更と混同されることは望ましくありません。

一般的な場合：はい

それはだメンテナンス性高めるために、常にそれだけの価値があなたのソフトウェアのを。

ちょうどそれのために行きます。

リリースを出荷しようとしている場合...

...そして、あなたがチームリーダーでない場合は、彼/彼女に確認してください。

コミットログの内容について...

孤立したタイプミスを修正するだけの場合は、少なくとも「機能」関連のコミットとは区別できるような何かを書くべきだということには、他の人たちも同意します。

一般的な方法は、タイムトラッカーと無限の変更を追跡するために、課題トラッカーに死ぬことのないタスクを含めることです。たとえば、次のタスクを実行することは珍しくありません。

• 大規模な自動化された無害なクリーンアップ（ホワイトスペーススイープ）、
• 文法とタイプミスの狩猟
• システムの変更をビルドします。
• 等...

正しく文書化されたチケットを作成するのが面倒になったときに、これらはほとんど何でも捨て可能なタスクIDとして使用されないことに注意してください。特に、IDにリンクされていないコミットを拒否する場合（これは良いことですが、このような大きなタスクは怠beな開発者にとってさらに魅力的です）。

タイプミスはコミットとして追加する必要があります。スペルミスや文法エラーを修正すると、コードが読みやすくなります。

「Fixed typo」または「Fixed typo in file.c」などのコミットメッセージを使用すると、これらのコミットを他の主要なコードコミットと区別するのに役立ちます。

はい、特にプロジェクトの早い段階でこれを絶対に行う必要があります。

どうして？2つのポイント：

1. タイプミスが「クリティカル」であるかどうかは、手遅れになるまでわかりません。誰もが大した問題ではないと考えているため、いくつかの修正はおそらく修正されません。それまでです。

2. 数百行のコード/関数呼び出しが行われた後で修正するよりも、タイプミスを早期に意図的に修正する方がはるかに簡単です。繰り返しますが、一時的なハッキングは驚くほど急速に半永久的になります。これが、「CollapseAll」メソッドと「ColapseAll」メソッドの両方を持つオブジェクトを処理する必要がある理由です。

エンドユーザーに表示される可能性のある文法エラーについては、はい、ユーザーまたはQAがエラーを報告して追跡する必要がある可能性が完全にあるため、必ずコミットする価値があります。既に修正されている場合は、問題の解決にかかる時間を短縮できます。

ただし、コードに関するコメントに文法的なエラーがある場合、実際のコードへの変更の一部である場合を除き、何もしません。その場合、コードのドキュメントを更新します。

コミットログをいっぱいにすることを心配しているなら、あなたは何か間違ったことをしている。:-)頻繁なコミットは良いことです！私は常にタイプミスを修正します。コードベースをできるだけ早く入手して、開発サイクルをスピードアップしてください！

はい、投票します。それらをチェックインします。私は人々が物をチェックインするのが嫌いな会社で働いています。私はほとんど何でも意味します。コードレビューは広範でした。コードの状態を想像できます。実際、コードは恐ろしいものではありませんでしたが、ワインのように流れるのではなく、魔法のようににじみ出ました。

変更管理プロセスで許可されていますか？

私の環境では、コミットするたびに、ビジネスユーザーまたは必須のシステムレベルの変更のいずれかによって要求された変更要求に結び付け、対応するエンドユーザーテストプロセスを完了する必要があります。あなたが説明しているような単純なタイプミスはおそらくそれらのいずれとしても記録されないでしょう（誰も気付かずに4年以上存在していた私のアプリの1つでタイプミスと文法エラーを見つけました）私は自分自身を説明するのは非常に困難な時間を持っていると呼んでいます。

あなたが説明しているような変更を保存します（実際には、実際には変更があります-メソッド名のつづりが間違っているため、それを発見しました）。同様に作成し、ログに「修正されたさまざまなタイプミス」を入れます。

DVCSを使用して履歴を編集する

クリーンなコミット履歴が心配な場合は、機能ブランチで主な作業を行うことを検討してください。たまたま分散VCSで作業している場合は、コミット履歴を簡単に編集してからメインブランチにプッシュできます。SVNを使用している場合は、Gitを試してください-Subversion と双方向でやり取りできます。また、実際にSubversionにコミットする前に履歴を編集することもできます。

そうでなければ常識を保つ

コミット履歴を編集したくない、または編集できない場合、自動テストまたはコンパイルに影響しないマイナーなタイプミスに対して早期コミットまたはアトミックコミットを実行する機能的な理由はありません。この場合、私の意見では、コミット履歴をクリーンに保つことは、本当にアトミックなコミットを行うよりも重要であるはずです。ミキシング1または2「通常」の変更でタイプミスを修正しても、潜在的なレビュープロセスに害を与えないだろう。ただし、大きなコーディングセッションの後に「クリーンアップ」する場合など、いくつかの些細な修正を1つのコミットにグループ化することもできます。

機能的なバグは、アトミックコミットでできるだけ早くコミットする必要があることに注意してください。

ここでの回答の一般的なトーンは、小さなタイプミスでも「すべてを高速にコミットする」戦略を示唆しているようです。私は意見が合わず、議論を歓迎する傾向があります。