1

以前の仕事では、各開発者が自分のブランチで作業することで、安定したプレリリース ブランチ (またはセットアップに応じてメイン) の管理と維持が容易になることがわかりました。実稼働インスタンスは 1 つしかないため、同じアプリの複数のバージョンをサポートする必要はありません。

この「プレリリース」ブランチは、ステージングおよび本番リリースを作成する別のブランチ (メイン) があったため、そのように名付けられました。ブランチは、プレリリース ブランチのコードのみをリリース ブランチにマージできるようにセットアップされました。これらのマージは、コード レビューのチェックポイントでした。CI ビルドもこのプレリリース ブランチから作成されており、その一連の作業の開発が完了したときに複雑なマージの問題を軽減するために、「プレリリース」から独自のブランチにマージするのは各開発者次第でした。

開発者がペアを組んで特定の機能の 1 つを共同で作業する必要がある場合、開発者自身のブランチのアクセス許可以外に、他の開発者との作業を妨げるものは何もありませんでした。これは、各チーム内の個人が個別/複数の機能に取り組んでいる分散チームを管理する場合にうまく機能しました。

頻繁な (週に 1 ～ 2 回) 30 分間のステータス更新ミーティングの助けを借りて、私たちはチームとして、特定の QA リリースで何を QA に入れ、何を入れないかを決定しました。

このシステムは機能しましたが、このトピックを検索すると、開発者ブランチに対する多くの憤りが見つかりました。git のローカル リポジトリ機能には多くの熱意があるようです。それでも、それらは同じ問題に対処するための異なる方法にすぎないようです。チェックインの遅延など、ローカルリポジトリが対処するクロスネットワークの問題を考慮していません。

4

3 に答える 3

3

主な違いは 3 つあります。

  1. ローカル リポジトリとは、システムに対してローカルであることを意味します。インターネットに接続されていない無人島で立ち往生していることに気付いた場合でも、変更をコミットすることができます。Git の優れた点の 1 つは、バージョン管理システムを利用するためにリポジトリに接続する必要がないことです。開発者は、メイン リポジトリにアクセスできずにリモートで作業することがあります。これは、Subversion、Perforce、または別のタイプの集中型リポジトリ バージョン管理システムのようなシステムを使用している場合、通常は面倒です。GitとBitKeeperを使用すると、オフラインで簡単に作業できます。

  2. 開発者ブランチの状況では、通常、統合ブランチから開発者ブランチに分岐し、統合ブランチにマージします。Git では、マージはしませんが、パッチを送信すると、最初にパッチをマスター リポジトリに送信しなくても、マスター リポジトリだけでなく他の開発者にも変更を送信できます。これにより、開発者はマスター リポジトリに触れることなく共同作業を行うことができます。

  3. 開発者/統合ブランチのセットアップでは、開発者ブランチはリポジトリにあり、他のユーザーがそれを見ることができます。Git では、開発者が変更を配信するまで、開発者の変更は利用できません。

于 2011-04-29T04:23:43.890 に答える
2

Git や Mercurial などの DVCS では、分岐とは直交する公開ワークフロー (プッシュ/プル) が導入されています。

つまり、次のことを意味します。

  • すべての開発者が同じブランチで作業している場合でも、自分のリポジトリで「プライベートに」作業を行うことができます。公開しない限り (つまり、上流のリポジトリにプッシュする)、その共通ブランチは実際には自分のものです。彼らは定期的にプル (フェッチ + マージ) を行って、同じトピックに関する他の作業から大きく逸脱しないようにすることができますが、準備ができたらプッシュします。

  • 開発者は自分の作業を決してプッシュしないかもしれませんが、インテグレーターは上流の「統合」リポジトリから、インテグレーターが必要とする多くの開発者のリポジトリから（同じ名前の）多くのブランチを取得できます。各ブランチは保存されます独自の名前空間 ( dev1/branch、dev2/branch、dev3/branch、...)
    内の統合レポ。そこから、インテグレータは、各開発者のブランチが導入しているコミットを見て、統合レポでそれらの変更をマージするかどうかを決定できます。
    注: これは Mercurial では少し異なります。名前付きブランチにはグローバル名前空間に名前があるためです ( 「 Git と Mercurial - 比較と対照」に関するJakub Narębskiの回答を参照してください。「個人的な意見: 私は個人的に思う」部）

したがって、git の「ローカル リポジトリ」は、開発者のブランチ内の任意のブランチを変換します (これは、開発者が共通のリポジトリからのブランチの上に独自のプライベート ブランチを作成することを妨げません)。
これらのブランチは、アクティブ パブリケーション (開発者によるプッシュ) またはパッシブ パブリケーション (開発者からの直接の介入なしに、アップストリーム リポジトリからプルまたはフェッチ) に利用できます。

David Wの答え（賛成）がより明確にするのは、次の違いです。

  • 新しいブランチのブランチから作業する (開発者にリンクすることもできますが、開発作業を分離するために、タスクまたはタスクのセットにリンクされたブランチを好みます。「いつブランチする必要があるか」を参照してください)
  • 独自のレポのレポから複製されたブランチから作業する:同じブランチで作業できますが、上流のレポから上記のブランチのクローン (コピー) である場合を除きます。
    インテグレーターが開発者リポジトリにアクセスできない場合は、David が言うように、「Git では、開発者が変更を提供するまで、開発者の変更は利用できません。」
    開発者のリポジトリにアクセスできる場合 (ネットワーク共有のような単純な「ローカル プロトコル」を介しても)、開発者の変更を下流のリポジトリから統合の上流のリポジトリにプルできます)。

ブランチを使用する集中型 VCS の方法とリポジトリを使用する分散型 VCS の方法を対比する別の方法については、 「バージョン管理 (VCS または DVCS) を使用するワークフローについて説明する」も参照してください。

于 2011-04-29T04:15:00.660 に答える
0

それがあなたのために働いたなら、素晴らしい。DVCS を使用すると、現在行っているすべてのことをサポートできるため、さらにうまく機能すると思います。

開発者ブランチに対するローカル リポジトリの利点の 1 つは、必要な数のブランチをローカルに持つことができることです。クイック ブランチをスピンアップして、興味のあるものをテストできます。ブランチをスピンアップして、お気に入りのライブラリの最新バージョンへの移行をテストできます。おそらく日の目を見るべきではないもので集中型サーバーを「汚染」する必要はありません。

于 2011-04-29T04:24:48.467 に答える