3

Mercurial とプライベート開発サーバーを使用して開発プロセスを改善しようとしていますが、現在の状況でのベスト プラクティスについてアドバイスが必要です。

  • すべての開発者がアクセスできる一元化された Mercurial リポジトリがあります。
  • 各開発者は Windows マシンを持ち、NuSphere IDE を使用して開発します。
  • 各開発者は、通常はローカル ネットワークで使用できるプライベート Linux 開発サーバーを持っていますが、VPN 経由でリモート アクセスする必要がある場合が半定期的です。

今、私は、各開発者が開発作業を行い、プライベート開発サーバーで結果を確認し、ブロックに満足したら、素敵なコミット メッセージで中央リポジトリにプッシュできるようにしたいと考えています。これは、ステージング サーバーでテストされてから、ライブになります。

ただし、各開発者は、Windows マシンで行った変更を、IDE を介して自分の開発マシンと共有する必要があります。開発マシンで SAMBA 共有を設定しようとしましたが、リモート接続では非常に遅くなります。

プロセスのこの部分にも Mercurial を使用する必要があると言われました。ただし、すべての開発者がすべての変更をローカル リポジトリにコミットし、これをプライベート dev サーバーにプッシュして、変更を中央リポジトリにプッシュすると、非常にマイナーなコミットが大量に発生します。これにより、コミット メッセージの品質が低下します。たとえば、「不足している } が追加されました」、「タイプミス x が修正されました」、コミット メッセージが完全に欠落しているなどです。

コミット履歴の統合に関してさまざまな hg 拡張機能を見てきましたが、コミットが 2 つのリポジトリ (開発マシンと開発サーバー) に存在し、そのうちの 1 つからコミットを削除すると問題が発生するように思われるため、問題が発生すると考えています。次のプッシュの問題。

Mercurial を使用して、共有リポジトリの履歴を混乱させずに、継続的な開発/開発サーバーへのコミットというこの目標を達成するにはどうすればよいですか?

4

2 に答える 2

3

で Rebase 機能が必要なようです--collapse。これにより、ブランチを 1 つのコミットにまとめることができます。RebaseExtension のドキュメント、特に の機能を見てください--collapse。

于 2012-04-26T16:16:44.803 に答える
1

あなたが言及したような粒度の細かいコミットの問題は見当たりません。「よりクリーンな履歴」のために複雑なワークフローを導入するのはなぜですか? 粒度の細かいコミットには、変更の流れが理解しやすく、コードのレビューが容易であるなど、多くの利点があります。また、他の人にも役立つ修正を簡単に選ぶことができます。

メイン リポジトリにプッシュするときに、開発者がマージ コミットで行われた作業の明確な説明を入力した場合、メイン ブランチのマージをたどり、すべての開発者ブランチを無視するだけで、比較的クリーンな開発ラインに従うことができます。さらに詳細が必要な場合 (コード レビューや特定の問題のデバッグなど) は、ブランチに飛び込むことができます。

再。コミット メッセージが空の場合、Mercurial は不足しているコミット メッセージのチェックインを拒否し、同僚が「.」を入力してそれをバイパスしようとすると、または「-」の場合、おそらくそれらを叱る必要があります;p。または、それらが本当に頑固な場合にそれらをブロックする受信フックを追加します。

于 2012-04-27T08:48:46.257 に答える