4

小規模なソフトウェア開発の場合、定義されたプロセスに従って変更を行いたいと考えています。これにより、統合ブランチには「完全な」変更のみが含まれます。このアイデアは、Mercurial から有用な履歴ログを取得することに関する私のブログの投稿に由来しています。ただし、これは単にログを生成することではなく、構造化された作業方法に関するものです。

要約すると、リポジトリには直接開発されない「統合」ブランチがあり、代わりにすべての作業が別のブランチで実行され、完了したら統合ブランチにマージされるというものです-以下は大まかな例です、中括弧内のコミット コメント:

  O   {Implemented new feature X}
  |\
  | O {...}
  | |
  | O {...}
  |/
  O   {Fixed bug 002}
  |\
  | O {...}
  |/
  O   {added tag "Release 1.0"}
  |
  O   {Fixed bug 001}
  |\
  | O {...}
  |/
  O  -- integration branch
 /
O  -- default branch

「統合」ブランチは、マージ先とタグ付けのみを許可します。

これは、職場で (サーバーベースの非 DVCS システムで) 開発を行う方法に似ています。この場合、作業ブランチに変更を加え、完了 (およびレビュー、テスト) したら、それらの変更をマージします。正式なテストとリリースのための統合ブランチ。

とにかく、私の質問は、統合ブランチではマージまたはタグ付けのみを許可しているのに対し、作業ブランチでのみ変更を行うというポリシーをどのように適用するのですか?

私の最初の考えは、フックを追加することですpre-commit（not precommit or pretxncommit、たとえば、タグを作成するときにこれらが起動されると思います）。フックは、統合ブランチにいた場合、これがマージの結果であることを意味する 2 つの親があることを確認し、そうでない場合は失敗します。

ただし、私が理解しているように、リポジトリを複製するときにフックはコピーされません。これはプロジェクト固有の設定になるため、ユーザー レベルでは設定しないでください。では、ユーザーがリポジトリのクローンを作成し (したがってフックを失う)、統合ブランチで直接変更を加えてからプッシュするのをどのように停止すればよいでしょうか?

hg clone main_repo
hg update integration_branch
(make changes without starting a new branch)
hg commit -m "I made some changes"
hg push

また、Bitbucket などのシステムを使用する場合、これをどのように強制できますか?

あるいは、これは DVCS を使用する場合のワークフローへの正しいアプローチではありませんか?

4

2 に答える 2

2

「構造化された作業方法」が必要だとおっしゃったと思いますが、代わりに探しているのはコード副官なのだろうか。つまり、ドアは内側から施錠されており、副官だけがドアを開け、コードは副官がドアを引き込んだときにのみ中央リポジトリに到達します。承認プロセスを経たコードは、中央リポジトリまたは権限のあるリポジトリに引き込まれます。それが「構造化された働き方」です。

中央リポジトリ全体への書き込みを拒否するのではなく、リポジトリ内のブランチのみへの書き込みを拒否することについて話すと、DVCS の #1 の優れた属性をどのように取り除くことができるかを尋ねているように思えます。コピーは 1 つだけではなく、各コピーに独自の読み取り/書き込みアクセス ルールを設定できること、必要に応じてこれらのコピーの 1 つが中心的なものであること、(b) コミットは誰かに与えることとは別であることそうしないと。コミットは、ローカルの作業コピー アクションです。DVCS を使用して、この制御されたプロセスの下で実際の変更を行ったことは、これらのコミットが、中央のリポジトリまたはコード担当者によって管理されている信頼できるリポジトリに到達するまではありません。

それとも、ブランチを作成せずに、ユーザーが自分の作業中の DVCS ローカル インスタンスにコミットするべきではないと考えていますか?

要するに、各ローカル マシンの作業コピーはブランチであり、目に見えないブランチであり、コード レビューと変更セット全体の統合テストを行う副官によってポーリングされるまで、誰にも影響を与えず、名前も付けられません。これは、CVCS で「機能ブランチ」と呼ばれるものと機能的に同等です。これらの目に見えないブランチはすべて書き込み可能であり、中央リポジトリ (ブランチではなく、別の REPO) は、その設定方法によって読み取り専用です。ユーザーはそこから同期できますが、新しい変更をそこにプルする副官を除いて、プッシュすることはできません。基本的に安定していますが、それでも誰もが仕事を成し遂げることができます。

于 2011-06-17T02:06:00.903 に答える
1

中央リポジトリにアクセスできる場合は、統合ブランチの着信チェンジセットに2つの親があることを検証hgrcするフックを定義できますpretxnchangegroup（最初の変更セットは統合ブランチにある必要があります）。AFAIK、Bitbucketでは、ブローカーを使用してのみ事後チェックを設定できました。これらのブローカーは、不要なプッシュを防ぐことはできませんが、誰かがルールに従わなかった場合に通知することがあります。

ただし、個人的には@Zhehaoのコメントを2番目にしています。つまり、全員にルールを守らせ、ルールを破った人に1週間同僚にコーヒーを提供してもらうようにします（つまり、あなたはそれを理解します）。

hgrc最後に、すべての開発者が自分のシステムに（一度）セットアップしなければならないいくつかの共有された対応するフックを維持することができます。システム上でグローバルに設定されている場合は、クローンごとに再度設定する必要はありません。

于 2011-06-16T13:01:09.510 に答える