大規模なタスクに適したソース管理チェックイン戦略とは何ですか？

一般的な規則は、チェックインを小さくし、頻繁にチェックインすることです。ただし、場合によっては、基になるフレームワークに大幅な変更を加える必要があります。次に、タスクを完了する前にチェックインすると、完成した作業をチェックインするまでプロジェクトが中断されます。

それで、仕事を失うリスクを減らすために、またはあなたがしていることを決定するために人々がどのような戦略をとっていますか？

可能な場合は、半分完了した作業をコメントアウトしてチェックインします。または、コンパイルして新しいファイルを使用していない場合は、それらをチェックインします。変更が大きいほど、プロジェクトをブランチしてからマージし直す可能性が高くなります。すべてが再び機能するようになったとき。ソース管理システムが許可する場合の別のオプションは、基本的に小さなブランチであるシェルフセットです。そのため、その日のうちに終了するか、決定ポイントに到達したら、変更を保留します。そして、何か壊滅的な事態が発生した場合、またはそのポイントに戻りたい場合は、それを行うことができます。

私はgitを使用しているので、私の答えは「ブランチ」です。分岐し、さまざまな部分を完了しながら少しずつコミットします。

必要に応じてコミットをアップストリームにプッシュし、同僚がトランクを中断することなく変更を確認できるようにします。

誰もがコードに満足したら、マージして完了です！

（私が比較的長期間実行するブランチで行う傾向があるのは、定期的にトランク（git用語ではマスター）を私のブランチにマージするため、2つのブランチが極端に分岐しないようにするためです。）

答えは、使用しているバージョン管理システムの種類（集中型（Subversionなど）または分散型（Gitなど））によって異なると思います。分散ソース管理システムの使用に関する実世界の経験はないので、私の答えは、Subversionで何をするかに基づいています。

進行中の大きな変更があり、一定期間にわたってトランクのビルドが中断する場合、またはそれが他の方法でチームの残りの部分を本当に混乱させる場合は、ブランチを作成します。私はそれを避けるためにできるだけ多くのことをするべきだと言いますが、ほとんどの変更はほとんど労力を費やすことなく残りのコードと並べることができます。たとえば、新しいコードへのコードパスをトリガーできます（単純なifステートメントを使用するか、DIフレームワークを使用している場合は構成設定に基づいて新しいバージョンを挿入できます）。その後、設定を新しいバージョンに変更し、すべてをテストして、未使用のコードを削除し、もう一度テストして、最後に設定を削除します。あなたはいつもそれを行うことができるわけではありませんが、ブランチを維持するオーバーヘッドのため、それが可能かどうか常に確認する必要があると思います。

ブランチを行う場合、私がよく目にする間違いは、ブランチをトランクに合わせて最新に保つことではないと思います。存在する間、トランクからブランチへの変更を絶えずマージする必要があります。そうすれば、すべてのリバースマージが完了したら、再び簡単にマージできます。

私たちのチームではsubversionを使用しており、通常は小さな変更を直接トランクにコミットしています。より大きなタスクの場合、それに取り組む開発者は通常、プライベートブランチを作成し、それが完了するとトランクにマージされます。次に、プライベートブランチが削除されます。当然、プライベートブランチは存在しますが、その所有者は頻繁にチェックインする必要があります。

長期にわたるブランチやトランクからブランチへのマージは、慎重な簿記を必要とするため、避けるようにしています。代わりに、トランクにマージされるのは一度だけで、すぐに削除される比較的短命なブランチがあります。

また、少なくとも1人が変更を確認して承認するまで、トランクに何もコミットまたはマージできないというルールがあります。

SQLサーバーの人々からの通常のコメントと同じように「依存する」

可能であれば、コードにブランチを作成して、作業の小さなチェックインを引き続き適用できるようにすることをお勧めします。完了したら、メイントランクにマージを戻します。

はい、これを実行する作業が重複する可能性があります。しかし、少なくとも、あなたはそれを行き止まりであると証明するそれをロールバックすることができる作業の軌跡を維持するでしょう。