3

職場では、Perforce を使用してバージョン管理を行っています。これには問題があります。1) この集中型モデルでは、回帰の準備が整うまで変更をチェックインできません。これは、開発プロセス中に改訂管理がないことを意味します。2) デポのクライアント ビューをバックアップしないので、チェックインするまで作業は安全ではありません。 3) 統合ブランチを設定しない限り、コードを共有するのに問題があります。これらの問題を克服するために git を使用したい開発者向けに、オプションの git ワークフローをセットアップしようとしています。

計画では、git-p4 を使用して perforce サーバーとやり取りし、プライベート git リポジトリを作成します。これで 1) が処理されます。Git Pro ( http://progit.org/book/ch5-1.html ) に示されている統合マネージャーのワークフローを使用して、開発者に公開リポジトリを公開させ、3) を処理する予定です。

祝福されたレポ

最後に、開発者が変更をプッシュして夜間バックアップ/オフサイト バックアップに取り込めるようにする場所が必要です。現在、クライアント ビューをバックアップしない理由は、全員のクライアント ビューのアーカイブ バックアップを毎晩行うのはスペース効率が悪いからです。多くの開発者がいて、彼らは多くのコードを作成しています。全員のクライアント ビューを重複してバックアップすることはできません。彼らが行っている固有の変更のみを保持したいだけです。

omni-backup私の考えでは、誰もがすべてのブランチをプッシュできる (そして自由に代替案を提案できる) 1 つの裸の git リポジトリを と呼びます。これは、git のスペース効率の良い sha-1 ハッシュを利用し、各ファイルの一意のバージョンのみがバックアップされるようにします。トリックは、スペース効率を得るために、すべてのバックアップ リポジトリが同じリポジトリの一部である必要があることです。

問題は、まったく異なるブランチを持つ 2 人がブランチに同じ名前を選択した場合です。EG Bob にはfeatureブランチがあり、Jane にはfeatureブランチがありますが、それらは異なる機能のためのものです。Bob が omni-backup にプッシュした場合、Fastforward マージではないため、Jane はプッシュできません。

ここで理想的に実現したいことは、Bob が機能ブランチをプッシュすると、ブランチの名前がリモートで に変更されることbob-featureですomni-backup。そして、 から機能を引き出すとomni-backup、 に戻りbob-featureます。

これを git で実現するのはそれほど簡単ではないようです。http://www.kernel.org/pub/software/scm/git/docs/git-receive-pack.html post-receive フックに記載されているプッシュ フックを使用して、直後に参照の名前を書き換えることができるようです。それが書かれていて、帰り道でプロセスを逆にするために何かをすることができましたが、それは壊れやすいと感じています. 誰でも良いアイデアがありますか?


編集:VonCの場合(コードがコメントを吸うため)VonC、あなたのやり方は有望に聞こえますが、それがフェッチであるという事実が名前空間の問題をどのように打ち負かすかわかりません。ブランチの名前を変更する方法を知っているcronjobを提案していますか?

のように(本当に汚い):

foreach my $user (@users) {
    my @branches = split(/s/,cat `$LDAPSERVER/$USER/$REPO/.git/refs/heads`);
    foreach my $branch (@branches) {
        system "git fetch $LDAPSERVER/$USER/$REPO/$BRANCH:+$USER$BRANCH"
    }
}
4

2 に答える 2

2

開発者に特定のガイドラインに従うようにさせることができれば、git pushそれを正しく行うことができます。

このコマンドを実行すると:

git push omni-backup feature:bob-feature

ここで、omni-backup はリポジトリのリモート参照であり、bob の機能ブランチは omni-backup の bob-feature にプッシュします。しかし、それを開発者に委ねることが望ましくない場合は、フローの方向を切り替えて、VonC が示唆するようにオムニ バックアップに開発者のリポジトリをプルさせることがより良い解決策です。

于 2010-07-13T20:06:26.753 に答える
1

開発者がリポジトリにプッシュする必要があるのはなぜomni-backupですか?

バックアップの目的で、別の開発者のリポジトリをリモートとして登録し、すべてのリモートリポジトリで(サーバーgit fetchから)毎晩実行します。 そうすれば、支店名の共謀はありえません。そして、より自動化されたプロセス(開発者は、直接作業していないリポジトリに何かを明示的にプッシュする必要はありませんが、バックアップのみを検討します)omni-backup

それから私は素敵な小さなものを作り、git archiveそれomni-backupを保管します.

于 2010-07-13T20:01:53.377 に答える