8

特定のブランチからの分岐とマージを禁止する git フックまたはその他の方法はありますか。「汚れた」統合ブランチをクリーンなデプロイメント ブランチにマージしないようにする必要があります。

主な目標は、人々が次のようなことを実行できないようにすることです。

git checkout integration
git checkout -b major_problem_branch

また

git checkout deployment_or_hotfix_or_feature_branch
git merge integration
4

7 に答える 7

4

これをベアリポジトリの構成ファイルに追加することにより、サーバーでブランチ権限を使用できます。

[hooks]
        allowedtomerge = user1,user2,user3
        protectedbranches = master

これにより、user1、user2、および user3 は master ブランチにマージできますが、それ以外はマージできません。

または、pre-commit フックを作成することもできます。

#!/bin/bash

if [[ `git symbolic-ref HEAD` == "refs/heads/master" ] -a ["$USER" != "user1"]] then
    echo "You cannot commit in master!"
    exit 1
fi

次に、評価して変更を進めることを許可する人がいます。

理想的には、gerrit、assembla、github など、お好みのシステムを使用します。マージ リクエストを通じてマスター ブランチを制御する優れた方法があります。

于 2012-11-09T02:45:52.780 に答える
3

一般に、誰かがローカル リポジトリに変更を加えるのを確実に防ぐことはできません。開発者が間違いを犯さないと信頼していない限り (その場合、これは必要ありません)、サーバーのフックでチェックを実行する必要があります。

つまり、人々が分岐するのを防げるとは期待できないということです。あなたができることは、何らかの形で「承認」されていない作業をサーバーの展開ブランチ (これを と呼びますdeploy) にプッシュしないようにすることです。

さて、最初の質問は、その承認をどのように表明するかです。

承認された人が作業をデプロイする前にレビューする必要があるワークフローが必要な場合、作業が現在 という名前のブランチにある場合、レビュー担当者に次の手順を実行してもらいますreview。

  1. deployが に完全にマージされていることを確認してreview、後でdeployに早送りできるようにしreviewます。
  2. で適切な検証を行いreviewます。
  3. git tag -sのコンテンツに対して、承認されたキーを使用して、署名付きタグ ( ) を作成してプッシュしますreview。
  4. ( , ) まで早送りdeployして押します。reviewgit checkout deploygit merge --ff-only review

代わりに、誰でも展開できるようにしたいが、最初にそれについて考える必要があるようにしたい場合は、同じことを行うことができますが、署名の要件を緩和することができます. または、特定のブランチ (たとえば ) を bless し、すべての作業を にプッシュする前にtestedマージしてプッシュするように要求することもできます。testeddeploy

deploy保護されたブランチに対してこの承認が与えられたことをサーバーはどのように確認できますか? 基本的な計画は、フックを使用して、決定した受け入れ基準に従ってupdateref-updates を受け入れるか拒否することです。refs/heads/deploy

承認されたキーによって署名されているなど、特定の基準を満たすタグが必要な場合は、git for-each-ref refs/tags. いずれかのタグが基準を満たしている場合は更新を受け入れることを忘れないでください。さもないと、遅かれ早かれ誰かがデプロイをブロックする不適切なタグをプッシュすることになります。正しいキーが使用されたことを確認することは、読者の課題として残されていますが、gpg --no-default-keyring --keyring=approved.gpg役立つ場合があります。

誰かがタグ付けしている限りコミットを行う場合は、git describe --exact-match <object>. 特定の名前パターンのタグに限定したい場合は、 を追加し--match <pattern>ます。注釈なしのタグを受け入れる場合は、--tags.

デプロイメントにマージされる前に作業を Blessed ブランチにマージする場合は、 の出力がgit rev-parse tested提案された新しいオブジェクトと等しいことを確認できます。

いずれの場合も、プッシュが早送りプッシュであることを再確認する必要があります。git merge-base <old> <new>と等しいことを確認できます<old>。

于 2012-11-04T20:56:08.680 に答える
1

Git はブランチ単位の許可をサポートしていないと思います。そのような要件にはgitoliteの使用を検討する必要があります。

GitLabと呼ばれる、見た目が github に似た非常にクールな gitolite Web インターフェイスもあります。

于 2012-11-02T14:07:08.903 に答える
1

中央レポ レベルでアクセス権を制御したい場合は、現在 (2013 年 3 月) 保護されたブランチを許可する git ホスティング サービスの 1 つであるAssemblaに注意してください。

「Put Down Your Forks - 保護されたブランチの紹介」を参照してください:

保護されたブランチは、書き込みアクセスが制限されたブランチです。
コードをブランチに送信できるチームのメンバー (またはグループ) を指定します。

グループ

Masterこれで、ブランチにプッシュできるのはこれらの人々だけになります。
それ以外の人は、マージ リクエストを通じてコードを提供する必要があります。リポジトリ内の他のブランチにプッシュすることはできますが、Master.

保護されたマスター ブランチ

于 2013-03-21T11:50:39.520 に答える
1

ダーティな統合ブランチからクリーンなデプロイメント ブランチにマージしたくない場合は、デプロイメント リポジトリのクローンを作成し、クローン (非デプロイメント リポジトリ) でのみダーティな統合作業を実行できます。

于 2012-11-02T16:13:40.877 に答える
1

nvieでgit flowを使用することをお勧めします。非常に単純なコマンドを使用して、すべてのブランチをあるべき場所に保持します。ここにチートシートがありますモデル

于 2012-11-08T23:07:37.873 に答える
0

機能ごとのブランチ (私の記事http://dymitruk.com/blog/2012/02/05/branch-per-feature/で説明されているように) を使用すると、リリース候補のアイデアが得られます。サーバーに更新フックを追加して、リリース候補のマージベースと開発 (別名統合ブランチ) が反復開始タグである共通のベースを持つようにすることができます。これにより、完全な機能だけが得られます。

さらに確実にしたい場合は、機能が完成しているかどうかを確認できます。フック スクリプトを問題追跡システムと統合する必要があります。統合されている機能のステータスが「完了」でない場合は、その時点でも失敗する可能性があります。たとえば、Jira は、コマンド ライン経由で対話する方法を提供します。

于 2012-11-05T05:48:57.503 に答える