ワークフローにgitを使用しており、リモートテストサーバーがあります。これを行うための最良の方法は何でしょうか。
現在、ワークステーションで変更を加え、変更をコミットしてからサーバーにプッシュします。しかし、これはすぐに多くの小さなコミットにつながります。ワークステーションにテストサーバーをセットアップすることは避けたいです。
そして、コミットのリベースは問題ありません。他の人がアクセスできるベアリポジトリ（テストサーバーである作業ディレクトリにそれをプルするフックがあります）にプッシュするからです。
ありがとう
ここでの本当の問題は、「[your] ワークステーションにテスト サーバーをセットアップするのを避けたい」ということだと思います。
A key philosophy in QAM is that every host can be as much like the production system as possible, so that we minimize the amount of work to be done to move from development to testing to production.
Deployment is not a trivial process, and the more your developers have to deal with it, the easier it will be to get the application (and the inevitable updates thereof) rolled out.
So you really should be thinking, "how closely can I replicate the production environment on my development machine?"
小さなコミットには何の問題もありません。実際、大きなブロブパッチよりもレビューが簡単なため、これらの方が適しています。彼らはあなたの思考プロセスをよりよく示し、仕事を小さな塊でレビューすることを可能にします。また、レビュー担当者は常に多くの小さなコミットを1つの大きなコミットに変えることができますが、その逆はできません。これは、コミットが論理チャンクの形式であることを前提としています。
しかし、プッシュするまでテストを行っていないので、コミットは「おっと、最後のコミットを壊した」という形になっていると思います。それらは良くなく、レビューを妨げるでしょう。理想的には--amend、前のコミットに合わせて編集する必要があります。
コード化してコミットし、テストするとTDDが妨げられます。あなたがしたいことは、既知の良好な状態から始めて、コードを書き、テストを実行し、失敗を見て、それがあなたの非常に小さくてデバッグしやすい差分の何かによって引き起こされたことを知ることです。
また、壊れた変更をマスターにプッシュしていることも意味します。これにより、チームの他の全員が台無しになります。
そうです、開発マシンにテスト環境が必要です。ボタンを押すだけで実行され、すぐに完了するもの（数分、トップスを話している）。完全なスイートが遅すぎるか面倒であることが判明した場合は、スイートの一部、おそらく変更に最も関連性があると思われる部分を実行し、プッシュした後にテストサーバーに完全なスイートを実行させます。これは、テストの効率と徹底性の間の適切な妥協点です。
何らかの理由で開発マシンでテスト環境を実行できない場合は、独自のブランチで作業し、それをプッシュしてテストできます。その後、それが機能しない場合は--amend、修正することができます。機能が完了したら、変更をマスターにマージできます。これにより、「おっと、私はそれを破った」コミットが排除され、小さくてレビューしやすいコミットを作成しながら、他のすべての人のマスターを破ることができなくなります。
テストサーバーを使用する必要があるのは、本番環境のシミュレーションにできるだけ近い状態でテストを実行することです。開発者のマシンは異種であることが多く、正常です。誰かがだらしなくなった場合に備えて、テストの実行を自動化します。
開発ブランチで小さなコミットを作成してから、サーバーにプッシュされるメイン ブランチにマージされる単一のコミットにそれらを押しつぶすことができないのはなぜですか? 私は頻繁にプライベート開発ブランチを使用しています。