Git kancalarını depoya koymak

Kötü bir uygulama olarak mı görülüyor - .git/hooksproje havuzuna koymak (örneğin sembolik bağlantıları kullanarak). Evetse, aynı kancaları farklı git kullanıcılarına ulaştırmanın en iyi yolu nedir?

Genellikle Scytale ile birkaç ek öneriyle, ayrı bir cevaba değecek kadar katılıyorum.

İlk olarak, özellikle bu kancalar politikayı uygulamak veya faydalı bildirimler oluşturmakla ilgili ise, uygun sembolik bağlantıları oluşturan bir komut dosyası yazmalısınız. İnsanların, sadece bin/create-hook-symlinkskendileri yapmak zorunda olduklarından daha fazla yazabilecekleri zaman kancaları kullanma olasılıkları daha yüksek olacaktır .

İkincisi, doğrudan symlinking kancaları kullanıcıların kendi kişisel kancalarını eklemelerini önler. Örneğin, herhangi bir boşluk hatası olmadığından emin olan örnek ön işleme kancasını seviyorum. Bunun için harika bir yol, repodaki bir kanca sarma betiğine düşmek ve tüm kancaları ona bağlamaktır. Sarıcı daha sonra hangi kancaya çağrıldığını anlamak için $0bir bash betiği; argv[0]aksi gibi bir eşdeğer olduğu varsayılarak) inceleyebilir , daha sonra repo içinde uygun kancayı ve yeniden adlandırılması gereken uygun kullanıcının kancasını çağırabilir. , tüm argümanları her birine geçirerek. Bellekten hızlı örnek:

#!/bin/bash
if [ -x $0.local ]; then
    $0.local "$@" || exit $?
fi
if [ -x tracked_hooks/$(basename $0) ]; then
    tracked_hooks/$(basename $0) "$@" || exit $?
fi

Yükleme komut dosyası, önceden varolan tüm kancaları yana taşır ( .localadlarına ekler ) ve bilinen tüm kanca adlarını yukarıdaki komut dosyasına bağlar:

#!/bin/bash
HOOK_NAMES="applypatch-msg pre-applypatch post-applypatch pre-commit prepare-commit-msg commit-msg post-commit pre-rebase post-checkout post-merge pre-receive update post-receive post-update pre-auto-gc"
# assuming the script is in a bin directory, one level into the repo
HOOK_DIR=$(git rev-parse --show-toplevel)/.git/hooks

for hook in $HOOK_NAMES; do
    # If the hook already exists, is executable, and is not a symlink
    if [ ! -h $HOOK_DIR/$hook -a -x $HOOK_DIR/$hook ]; then
        mv $HOOK_DIR/$hook $HOOK_DIR/$hook.local
    fi
    # create the symlink, overwriting the file if it exists
    # probably the only way this would happen is if you're using an old version of git
    # -- back when the sample hooks were not executable, instead of being named ____.sample
    ln -s -f ../../bin/hooks-wrapper $HOOK_DIR/$hook
done

Hayır, onları depoya koymak iyidir, hatta bunu yapmanızı öneririm (başkaları için de faydalıysa). Kullanıcı, bir yandan biraz acı veren, ancak diğer yandan kullanıcıları rızası olmadan rastgele kod çalıştırmalarına karşı koruyan (örneğin, symlinking yoluyla) açık bir şekilde etkinleştirmelidir.

Günümüzde, sürüm kontrolü altındaki bir dizini git hooks dizininiz olarak ayarlamak için aşağıdakileri yapabilirsiniz, örn MY_REPO_DIR/.githooks.

git config --local core.hooksPath .githooks/

Yine de doğrudan uygulanamaz, ancak README'nize (veya her neyse) bir not eklerseniz, bu her geliştirici için minimum çaba gerektirir.

Gönderen http://git-scm.com/docs/git-init#_template_directory , sen / her yeni oluşturulan git repo ait dir kanca .git güncellemek için bu mekanizmalardan birini kullanabilirsiniz:

Şablon dizini, oluşturulduktan sonra $ GIT_DIR klasörüne kopyalanacak dosyalar ve dizinler içerir.

Şablon dizini aşağıdakilerden biri olacaktır (sırayla):

• --template seçeneği ile verilen argüman;

• $ GIT_TEMPLATE_DIR ortam değişkeninin içeriği;

• init.templateDir yapılandırma değişkeni; veya

• varsayılan şablon dizini: / usr / share / git-core / templates.

Projede saklayın ve yapıya kurun

Diğerleri yanıtlarında belirtildiği gibi, kancalarınız belirli projeleriniz için spesifikse, git tarafından yönetilen projenin kendisine ekleyin. Bunu daha da ileri götürürdüm ve projenizin tek bir komut dosyası veya komut kullanarak derlenmesinin iyi bir uygulama olduğu göz önüne alındığında, kancaların derleme sırasında yüklenmesi gerektiğini söyleyebilirim.

Biraz daha derinlemesine okumak istiyorsanız, git kancalarını yönetme hakkında bir makale yazdım .

Java ve Maven

Tam sorumluluk reddi; Aşağıda açıklanan Maven eklentisini yazdım.

Java projeleriniz için Maven ile derleme yönetimini yönetiyorsanız, aşağıdaki Maven eklentisi projenizdeki bir konumdan kanca takmayı işler.

https://github.com/rudikershaw/git-build-hook

Tüm Git kancalarınızı projenizdeki bir dizine koyun, ardından pom.xmlaşağıdaki eklenti bildirimini, hedefini ve yapılandırmasını içerecek şekilde yapılandırın.

<build>
  <plugins>
    <plugin>
      <groupId>com.rudikershaw.gitbuildhook</groupId>
      <artifactId>git-build-hook-maven-plugin</artifactId>
      <configuration>
        <gitConfig>
          <!-- The location of the directory you are using to store the Git hooks in your project. -->
          <core.hooksPath>hooks-directory/</core.hooksPath>
        </gitConfig>
      </configuration>
      <executions>
        <execution>
          <goals>       
            <!-- Sets git config specified under configuration > gitConfig. -->
            <goal>configure</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
      <!-- ... etc ... -->
  </plugins>
</build>

Proje derlemenizi çalıştırdığınızda, eklenti git'i belirtilen dizinden kancaları çalıştıracak şekilde yapılandırır. Bu, projenizde çalışan herkes için bu dizindeki kancaları etkin bir şekilde ayarlayacaktır.

JavaScript ve NPM

NPM için Husky adında bir bağımlılık vardır, bu da JavaScript'te yazılmış kancalar da dahil olmak üzere kancaları takmanıza izin verir.

// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "npm test",
      "pre-push": "npm test",
      "...": "..."
    }
  }
}

Diğerleri

Ayrıca, orada olup önceden taahhüt Python projeler için Overcommit Yakut projeleri için ve Lefthook yakut için veya Düğüm projelerine.

Https://www.npmjs.com/package/pre-commit bu zarif belirtmek için izin npm paket kolları senin package.json içinde kancaları ön işlemek.

İşte, depoda normal bir dosya olarak gönderebileceğiniz ve git kancasını kod dosyasına eklemek için çalıştırılabilen add-git-hook.sh adlı bir komut dosyası. Hangi kancayı kullanacağınızı (ön işlem, son işlem sonrası, ön itme, vb.) Ve kedi heredocundaki kancanın tanımını ayarlayın.

#!/usr/bin/bash
# Adds the git-hook described below. Appends to the hook file
# if it already exists or creates the file if it does not.
# Note: CWD must be inside target repository

HOOK_DIR=$(git rev-parse --show-toplevel)/.git/hooks
HOOK_FILE="$HOOK_DIR"/post-commit

# Create script file if doesn't exist
if [ ! -e "$HOOK_FILE" ] ; then
        echo '#!/usr/bin/bash' >> "$HOOK_FILE"
        chmod 700 "$HOOK_FILE"
fi

# Append hook code into script
cat >> "$HOOK_FILE" <<EOF

########################################
# ... post-commit hook script here ... #
########################################

EOF

Bu komut dosyasının yürütülebilir izinlere sahip olması anlamlı olabilir veya kullanıcı doğrudan çalıştırabilir. Bunu yaptıktan sonra diğer makinelere otomatik olarak git-pull yapmak için kullandım.

DÜZENLEME-- OP sorusu olmayan ve OP'nin aradığı kolay olmayan soruyu cevapladım. Aşağıdaki yorumlarda onları harici olarak yönetmeye karşı repoda kanca komut dosyaları göndermeye yönelik kullanım durumlarını ve argümanları seçtim. Umarım aradığınız şey buydu.

Composer tabanlı PHP projeleri için mühendislere otomatik olarak dağıtabilirsiniz. İşte ön taahhüt ve kesin msj kancalarına bir örnek.

Bir hooksklasör oluşturun , ardından composer.json'unuzda:

 },
 "scripts": {
     "post-install-cmd": [
         "cp -r 'hooks/' '.git/hooks/'",
         "php -r \"copy('hooks/pre-commit', '.git/hooks/pre-commit');\"",
         "php -r \"copy('hooks/commit-msg', '.git/hooks/commit-msg');\"",
         "php -r \"chmod('.git/hooks/pre-commit', 0777);\"",
         "php -r \"chmod('.git/hooks/commit-msg', 0777);\"",
     ],

Daha sonra, herkes composer installdüzenli olarak çalışırken proje devam ettikçe bunları güncelleyebilirsiniz .

Ön işleme gibi ön işleme kanca yönetimi için yönetilen bir çözüm kullanabilirsiniz . Veya Datree.io gibi sunucu tarafı git-kancaları için merkezi bir çözüm . Şu gibi yerleşik politikalara sahiptir:

1. Sırları tespit edin ve birleştirin .
2. Uygun Git kullanıcı yapılandırmasını zorunlu kılın .
3. Jira bilet entegrasyonunu zorunlu kıl - çekme isteği adı / taahhüt mesajında ​​bilet numarasını belirt .

Tüm kancalarınızın yerini almayacak, ancak kancaları her geliştiricinin bilgisayarına / repo'suna yapılandırma cehennemi olmadan geliştiricilerinize en belirgin olanlarla yardımcı olabilir.

Feragatname: Datrees kurucularından biriyim