2

現在、非オープンソース プロジェクトに取り組んでおり、約 50 人のチームで、毎日平均 20 ～ 30 件のコミットを行っています。これらの人々の一部はジュニア開発者であるため、メイン リポジトリに全員がコミットできないようにするシステムを実装する必要がありました。

これまでは、次の構造で SVN を使用していました。

  • トランク - すべての開発者コードが含まれていました
  • ブランチ - すべての検証済みコードが含まれていました

ときどき、上級開発者の 1 人がトランクに「入り」、それをブランチとマージし、承認されていないコードをすべて拒否します (元に戻す承認されていないコードがたくさんある場合、これはおかしなことになります)。最後に、トランクに承認済みのコードしかない場合は、両者が完全にマージされます。

最近、Git と GitLab を使っていくつかのテストを開始し、Git 承認システムが SVN から移行する価値があるかどうかを確認し、この統合の狂気すべてを和らげました。

最初は有望に見えましたが、しばらくして、魔法の公式は存在しないという残念な結論に達しました。私たちは上級開発者だけが変更をプッシュするためのアクセス権を持つ保護されたマスター ブランチを作成しましたが、後輩開発者に問題が生じました。

おそらく私たちは SVN のやり方に慣れすぎているため、見つけた唯一の解決策は"ジュニア ブランチ"を作成することでした。

何か足りないものがある場合や、問題の処理方法が間違っている場合はお知らせください。

編集 私が承認されたコードと言うとき、私はすべてのクラス構造の検証、正しいオブジェクトのインスタンス化を指しています...改行、タブ(および同様のもの)が正しい場合ではありません。

4

1 に答える 1

0

この種のポリシーは、VREF のおかげで、GitLab が Gitolite を使用していたときに簡単にセットアップできました。

「ジュニア」と呼ばれるユーザーのグループ (GitLab のチーム) に対して定義できる gitolite ルールに更新フックを関連付けて、必要なポリシーを適用することができます。

しかし、GitLab 5.x 以降、gitolite は使用されなくなり、gitlab-shell代わりに権限を管理します。
うまくいけば、Issue 14が解決されるでしょう。
それまでの間、特定のブランチにプッシュするジュニア開発者にポリシーを適用するために、更新フックを自分で実装してデプロイする必要があります。

コメントしたように、他のアプローチは次のとおりです。

  • そのジュニア開発者をプロジェクトに追加しないでください
  • プロジェクトを fork (サーバー上でクローン): その機能は GitLab V5 向けに現在開発中です (問題 3382 )
  • とりあえず、プル リクエスト (「マージ リクエスト」と呼ばれます) を作成します。

GitLab の現在の開発状況を考えると、Git 管理ソフトウェアだけでは、必要なものすべてを提供する準備ができていません。

これらのリポジトリ (メインのリポジトリとジュニア開発者向けのリポジトリ) をGerritのようなレビュー システムと組み合わせることは、より賢明なアプローチかもしれません (この組み合わせに対する興味深い批判があります)。

于 2013-04-15T15:43:14.430 に答える