コミット間の待機時間が長すぎる場合はどうすればよいですか？

私はいたずらだった...あまりにも多くの「カウボーイコーディング」、十分なコミット。さて、ここで私は多大なコミットをしています。はい、ずっとコミットしていたはずですが、今は遅すぎます。

何が良いですか？

1. 私が変更したすべてのものをリストする1つの非常に大きなコミットを行う
2. ファイルには複数の修正、変更、追加のメソッド名などがあるため、コンパイルできない可能性のある小さなコミットに分割してみてください
3. 適切なコミットのためだけにファイルの部分的な復元を行ってから、新しい変更を元に戻します。

注：現時点では、このプロジェクトに取り組んでいる唯一のプログラマーです。少なくともより多くのプログラマを雇うまで、これらのコミットコメントのいずれかを見るのは私だけです。

ところで：私はSVNとSubclipseを使用しています。これらの変更を行う前に、新しいブランチを作成しました。

詳細：そもそもどうやってこの状況に陥ったのかということに関して、別の質問をしました。アプリケーションの接着剤を書き換える準備をする方法

回答するには、これらのコミットの結果を将来どのように使用するかを自問する必要があります。最も一般的な理由は次のとおりです。

• バグが導入されたリリースを確認するには。
• 特定のコード行が存在する理由を確認します。
• 別のブランチにマージします。
• 顧客またはテスターがそのバージョンで見ている問題のトラブルシューティングのために以前のバージョンをチェックアウトできるようにするため。
• 特定のパーツをリリースに含めたり除外したりできるようにするため。

最初の2つの理由は、変更されたコードの各行に等しく適用されるチェックインメッセージを作成できると仮定すると、1回の大きなチェックインでも同様に処理できます。あなたが唯一のプログラマである場合、小さなコミットでマージが簡単になるわけではありません。未提出の変更の一部のみでリリースまたはテストを行う予定がない場合、最後の2つの理由は当てはまりません。

小さなコミットを行う理由は他にもありますが、それは変更の途中であり、その時間が過ぎているためです。これらの理由は、間違いや実験的な変更をバックアウトしやすくし、大きな恐ろしいマージをせずに同僚と同期しやすくすることです。

あなたが説明したあなたの状況の私の理解から、この時点であなたのコミットを分割することはほとんどまたはまったく利益がないようです。

何をするにしても、コンパイルできないことがわかっているコードのチェックインを避けるようにしてください。

3番目のオプションが実行可能だと思う場合、コミットのシーケンスがコンパイルできないシステムを作成しないことを保証できる限り、それはそれを行う良い方法かもしれません。それ以外の場合は、1つの大きなコミットを実行します。いですが、簡単で迅速で、完了します。今後、より頻繁にコミットします。

頻繁に、小さく、意味のあるコミットを行う最も重要な理由は、コードの履歴の理解を支援することです。特に、理解できる差分を生成することが難しい場合、コードがどのように変更されたかを理解することは非常に困難です。

オプション1は、行った変更の履歴を難読化しますが、それ以外の場合は問題は発生しません。

オプション2は、行った変更の履歴を難読化しますが、オプション1よりも多少小さいかもしれませんが、コミットが明確であると仮定または結論付けた場合、他の問題を引き起こす可能性があります。これがオプション1よりも好まれる強い実用的な理由がない限り、これはそれよりも理想的ではありません。

オプション3は最良であり、他のすべては同等ですが、他の場所で説明したように、「極端な」時間を必要とするか、他の重要なコストが発生する場合、予想される利益とそれらのコストを比較する必要がありますよりクリーンなコミットを作成します。

提供された情報に基づいて、オプション1を選択します。変更をコミットするように促すリマインダーを設定する必要があるかもしれません。

プロトタイピングと書き換え

特に唯一のプログラマーであることについてのあなたのメモと、比較的新しいコードベースで作業しているという私の疑いに照らして、覚えておくべきもう1つの考慮事項は、おそらくあなたが「既存のコードを維持または拡張するのではなく、新しいコードのプロトタイプを作成しています。おそらく、この2つの間にそれほど鋭い区分はありませんが、それでも有用な区別だと思います。

新しいコードのプロトタイプを作成するときは、変更を保存するときはいつでも、ほぼ確実にブランチでコミットしますが、おそらく別のプロジェクトでコミットします。または、バージョン管理の範囲外で作業することもできます。代わりに、検討しているさまざまな仮説または設計の実行可能性に関する証拠の収集に集中できます。C＃コードのVisual Studioの代わりにLINQPadなど、さまざまなツールを使用して小さなプロトタイプを作成することがよくあります。

特定の仮説または設計を検証したら、メインプロジェクト、理想的にはブランチでそれを書き直し、変更の性質に関して他の人（将来のあなたを含む）の理解に最も役立つ小さな有意義なコミットを行います。あなたが作っています。

唯一の合理的な答えは、決してtrunkを壊さないことですが、不可能な場合もあります。たとえば、コミットが多すぎるとsvnがコミットを中断する可能性があります（オプションか機能かどうかはわかりません）。このような特別な場合には、チェックインするだけです。あなたは一人のプログラマーなので、誰も邪魔することはありません。

したがって、オプション1に進みます。不可能な場合は、オプション2を選択します。

オプション3には多くの労力が必要であり、それだけの価値はありません。

ファイルには複数の修正、変更、追加のメソッド名などがあるため、コンパイルできない可能性のある小さなコミットに分割してみてください

同様の状況に陥ったとき、次の手法を使用しました。

1. 特定の機能に関連するコードのみを追加します。 git add --patch
2. 他のすべての変更を隠します： git stash save --keep-index
3. テストの実行/コンパイルの試行
4. すべてに問題がない場合は変更をコミットし、そうでない場合は1に進みます

私はSVNに精通していないので、これが特定の状況に当てはまるかどうかはわかりませんが、基本は同じである必要があります-コードの小さな部分を分離し、個別にテストします。

方法4の方法：リポジトリの現在の状態を一時的な場所にバックアップし、リポジトリを元の状態に戻し、行ったすべての変更のリストを作成し（一時バックアップを引き続き確認できます）、手動で再実装（およびコンパイル）そしてテスト！）別々のコミットとして。

これは簡単です。コードをすでに作成しているので、一時バックアップからコピーして貼り付ける部分を把握するのはほんの少しです。

すべての変更をきれいに再実装し、コミットが自己完結型、小規模、およびコンパイルであることを確認したら、一時バックアップを削除できます。すべてが（コミットの時刻/日付を除く）ほぼ正確になります。あなたが最初からそれをやったならそうだったでしょう。

あなたは唯一のプログラマです。あなたがしたことの重要な部分を詳述する単一の大規模なチェックインを行うだけです。

あなたがしたことの「部分」をロールバックする可能性がありますか？そうでない場合は、絶対にオプション1に進みます。

バージョン管理システムにコードをチェックインする理由はいくつかあります。そして、それらすべてが、あなたが唯一の開発者である場合、安全性を中心に展開します。つまり、ねじを締めたり、機械が死んだりした場合、いつでも最後のチェックポイントに戻ることができます。

後でプロジェクトに参加するプログラマーは、コンパイルされていないバージョンにロールバックしたくないでしょう。だから、私見、オプション2は狂気です。

オプション3は時間の無駄遣いのように聞こえます。もし私があなたの上司であり、あなたがこれを何時間も無駄にしているのを見たら、あなたの時間の価値について少し話をするでしょう。

反復するには：コードをチェックインすることにより、マシンで障害が発生した場合に、お尻をカバー/保存します。ワンマンチームでは、それ以外はすべてウィンドウドレッシングです。

私のルールは次のとおりです。深刻なコードレビューなしにチェックインしない。私は自分でだ場合、私はコードを自分で確認する必要がありますが、それはなります見直されます。他の人がレビューできないほど多くのコード変更があるため、自分でレビューすることはできません）。

誰もが完全に破ることのできないルールは次のとおりです。ビルドさえしないコードはチェックインせず、機能しないコードのチェックインを真剣に避けます。

解決策：変更したコードをコピーして、元のポイントに戻ります。一度に1つの変更を元のコードにマージし、レビューし、テストし、チェックインします。説明したプログラミング方法では、そのようにしていくつかの重大なバグを見つけることができます。

また、良いプログラミング習慣を身につける良い方法でもあります。

心配しすぎていると思います。あなたが唯一のプログラマであり、あなたが反対する仕様書を持っていないなら、それはあなたが何をするか完全にあなた次第です。大規模なコミットを行ったとしても、誰もあなたを罰することはないと思うので、あなたが遭遇する唯一の問題は、コミット内の個々のファイルの変更をロールバックできないなどの技術的な問題です。ただし、現時点ではレポジトリを単独で管理しているため、これも大きな懸念事項ではありません。

実用主義と独断主義の間には線が引かれます。チームであなたがしたことは良い考えではなく、おそらく今後も繰り返されるべきではありませんが、あなたの状況では、私は大規模なコミットを提出するだけです。

問題は、コミット間の長い遅延ではなく、コードをコンパイルできない状態に長時間保持しているという事実にあります。まず、「長い」の定義は何ですか？一部の人にとっては、移行状態の5分間は多すぎますが、コンパイラを実行しなくても数日間コードを磨くことができます。

実際、それは問題ではありません。重要なのは、コードの制御を失い、コードが管理不能になったことです。これは正常なことです。技術的な負債があることを意味し、リファクタリングを検討する時が来ました。あなたはイライラしていますか？コードはコンパイルされず、ユニットテストさえありませんか？この場合のリファクタリングについてどう思いますか？心配ない。「カウボーイコーディング」を終了し、クリーニングを開始します。理想的には、いくつかのテストを書いてみてください。時間がありませんか？さて、小さな改善から始めましょう。

一部の変更はテストを必要としません。変数の名前をより適切なものに変更したり、繰り返しコードを別の関数に移動したりするなど、コードをよりよく理解できます。その後、より大きな変更を行うことができます。繰り返しますが、可能であればテストを作成してください。コードを管理しやすくします。

その後、次の変更が「長すぎる」ことを意味しないことがわかります（それが何を意味するにせよ）。