4

他の開発者のコ​​ードを中央リポジトリにプッシュする前に確認できるようにしたいと思います。開発者は離れた場所にいるので、自分のデスクに行くことはできません。

現在、彼らはプッシュするだけで、問題がある場合はロールバックします。しかし、誰かがロールバックする機会を得る前に引っ張ることができるので、これは良いアプローチではありません。

4

5 に答える 5

9

Mercurial は分散されているため、あらゆるワークフローに適応できるはずです。誰かを統合マネージャーとして指定するか、独裁者と副官のワークフローを使用してみてください。

于 2011-02-04T14:43:19.077 に答える
3

開発者とメインリポジトリ間のレビューリポジトリはどうですか?そこからメインにプッシュするのはあなただけです。

于 2011-02-04T14:39:16.973 に答える
1

私の最後のプロジェクトでは、非常にブランチの多い開発モデルに従いました。すべてのタスクには、タスク番号で名前が付けられたブランチがありました。指定されたブランチに対してコード レビューが実行されました。これらを中央リポジトリにプッシュし、開発者がそれらをプルすることを明示的に望んでいました。

ただし、ブランチという名前のタスクは、コード レビューに合格するまで、統合ブランチ (この場合はデフォルトですが、任意の機能ブランチである可能性があります) にマージされませんでした。

多くの Mercurial 開発者は、リポジトリに残る短命のブランチを使用することを好みませんが、特に 1 つの変更の履歴を見る場合は、履歴をたどるのが簡単になることがわかっています。特定のタスクは、関連付けられた名前付きブランチにあります。

于 2011-02-05T06:37:33.127 に答える
1

これは単なる拡張であるため、kellotiの回答に賛成しましたが、リポジトリの層を使用しただけです。レビューされていない変更セットをニーズ レビューの中心的なリポジトリにプッシュし、レビュアーにそこからレビュー済みの作業をニーズ QA の中心的なリポジトリにプッシュさせ、QA 担当者にリリース候補の中心的なリポジトリをプッシュさせます。

分散バージョン管理システムを使用すると、複数の開発者リポジトリを作成するのと同じくらい簡単に、複数の集中リポジトリを作成できます。

于 2011-02-04T16:05:03.280 に答える
-2

おそらく、シェルフエクステンションを使用することは良い解決策ですか?私はMercurialにあまり詳しくありませんが、これはあなたのために働くかもしれません。

https://www.mercurial-scm.org/wiki/ShelveExtension

于 2011-02-04T14:37:57.443 に答える