2016-06-30 7 views
1

開発者が1つのリポジトリに変更をプッシュ/コミットできるバージョン管理システムをセットアップしたいと思います。私たちのテスト部門は、これらの変更を引き出してテストすることができます。これらの変更がテスト部門によって承認された後、リリース準備が整った第2のリポジトリにコミットされます。2ステップコミットSVN、Git、

私はこのために枝を使うことができると知っていますが、マイクロチェンジがたくさんあり、それぞれのブランチを作成することは私のオーバーヘッドのようです。

要するに、各コミットがブランチのように動作し、個々にマスターリポジトリにマージできるシステムが必要です。

注:Gitのインデックスは、ローカルにしか存在せず、テスト部門からアクセスできないため、カウントされません。

答えて

2

Gitのような分散リポジトリでは、ブランチは必要ありません。複数のリポジトリが必要です。一方は別のリポジトリからゲートキーパーとして機能します。

ゲートキーパーのレポにプッシュすると、そのレポがポスト受信フックでトリガされます。
これらのテストが合格すると、最終的なレポにプッシュされ、すべての開発者が引き出すための恵まれた参照として機能します。

これは "コミットによって"テストするのではなく、プッシュされたコミットのセットごとにテストします。

前に言及したのはfinal repo was actually an svn oneです。
tests or for private buildsについても言及しました。

+0

私は自分の組織の開発にも同じスタイルを使います。 すべての変更は、実際にはマスターからのドライバである「開発」と呼ばれる別のレポで実行され、「開発」のすべてのコミットが検証された後にマスターに移動されます。 – Adeel