私の現在の環境では、「クリーンな」ビルドマシンがあり、コミットされたすべての変更の正確なコピーがあり、それ以上でもそれ以下でもありません。
そしてもちろん、私は自分のマシンを持っており、数十のファイルが「進行中」の状態になっています。
多くの場合、1つの変更だけでアプリケーションを構築する必要があります。たとえば、タスクABCを終了し、その変更のみでEXEを作成したいとします。
しかしもちろん、テストされるまでリポジトリに変更をコミットすることはできません。
分岐はこれにはやり過ぎのようです。テストビルドとリリースの変更を分離するために、環境で何をしますか？
@Matt b：では、変更に関するフィードバックを待つ間、何をしますか？あなたはいつもただ一つのことに取り組んでいますか？
一度に複数の「タスク」を処理する方法を尋ねていますよね？分岐以外。
作業中のチケットの名前をディレクトリ名の末尾に付けて、ローカル マシン上でソースの複数のチェックアウトを行うことができます。タスクに応じて、適切なディレクトリに変更を加えてください...
複数のタスクを 1 つの作業コピー/コミットに混在させると、特に誰かが後で作業をレビューする必要がある場合に、非常に混乱する可能性があります。
変更をコミットまたはプロモートする前に、ローカルマシン/環境でビルドを作成してテストすることを好みます。
特定の例では、タスクABCを開始する前にソースのクリーンコピーをチェックアウトし、ABCを実装した後、それを含むビルドをローカルに作成しました。
そのようなもの：git stash && ./bootstrap.sh && make tests :)
私は、各「コミット」操作が単一のまとまりのある変更を表すように努めています。バグ修正全体または機能全体である場合もあれば、より大きなものへの途中での単一の小さなリファクタリングである場合もあります。ユニットが何であるかを直感で判断する簡単な方法はありません。また、チームメイトにも同じことをお願いしています。
これが適切に行われると、次のような多くのメリットが得られます。
このように作業することで、小さなブランチの必要性を減らすことができます。これは、自信を持って小さな一歩を踏み出し、それを検証し、コミットしてから繰り返すためです。ステップを小さく自信を持って行う方法について説明しましたが、これが機能するためには、検証フェーズも迅速に進める必要があります。高速できめ細かい単体テストと、高品質で高速なアプリケーション テストの強力なバッテリーを持つことが重要です。
チェックインする前にコードレビューが必要になる前に私が取り組んだチーム。これによりレイテンシが追加され、私の小さなステップの作業スタイルが妨げられます。コード レビューを緊急性の高い割り込みにすることは有効です。ペアプログラミングへの切り替えも同様です。
それでも、私の脳は重いマルチタスクを好むようです。それを機能させるには、複数の進行中の変更が必要です。複数のブランチ、複数のローカル コピー、複数のコンピューター、および保留中の変更のバックアップを作成するツールを使用しました。それらのすべてが機能します。(そして、それらはすべて同等であり、さまざまな方法で実装されています。) 複数のブランチが私のお気に入りだと思いますが、サーバーに負担をかけることなく、新しいブランチをすばやく簡単に作成できるソース管理システムが必要です。BitKeeper はこれが得意だと聞いたことがありますが、まだ確認する機会がありませんでした。