Git Hooks ile Ekibinizin Geliştirme İş Akışını Nasıl Kolaylaştırabilirsiniz?

Bir ekip veya açık kaynaklı bir proje için çalışmanın en önemli gereksinimlerinden biri sürüm kontrol sistemi (VCS) kullanmaktır. Git, yazılım geliştirme sırasında kaynak kodu değişikliklerini izlemek için ücretsiz ve açık kaynaklı dağıtılmış bir sürüm kontrol sistemidir. Linux çekirdeğinin geliştirilmesi için 2005 yılında Linus Torvalds tarafından oluşturuldu. Öğrenmesi kolaydır ve yıldırım hızında performansıyla küçük bir ayak izine sahiptir.

Git'i zaten kullanmış olmanız (geliştirme topluluğunda bulunan en popüler ve en iyi benimsenen VCS araçlarından biri olduğu için) büyük bir şans vardır ve büyük olasılıkla kodunuzu itme ve çekme yoluyla hazırlama ve işleme hakkında biraz bilginiz vardır. uzak bir depodan. Bu makale git iş akışlarının temellerini ele almayacak, ancak çoğunlukla git kancalarına ve ekibinizde daha iyi işbirliğini sağlamak için bunların nasıl kullanılacağına odaklanacaktır . Ekiplerin boyutu büyüdükçe, katkıda bulunanları hizada tutmak ve kodla ilgili farklı kuralları sürdürmek daha da önemli hale geliyor.

Git Kancaları Nedir?

Git kancaları, bir git deposunda belirli eylemler veya olaylar gerçekleştirildiğinde tetiklenen komut dosyalarıdır. Bu eylemler, taahhüt etme ve gönderme gibi sürüm denetimi iş akışının bölümleriyle ilgilidir. Kancalar, git iş akışınızdaki görevleri otomatikleştirerek gerçekten yararlı olabilir. Örneğin, bazı belirli kurallara dayalı olarak kod tabanımızın sözdizimini doğrulamamıza veya değişikliklerimizi gerçekleştirmeden önce bazı testler çalıştırmamıza yardımcı olabilirler.

Nasıl Ayarlanır?

Git kancaları yerleşik bir özelliktir, yani git deposu başlatıldığı sürece onlara erişebilir ve bunları kullanmaya başlayabiliriz. Bunları ayarlamaya çalışarak bunun ne anlama geldiğine daha ayrıntılı bir göz atalım.

Favori terminalinizi kullanarak yeni bir git deposu oluşturun.

 mkdir my-new-repository && cd my-new-repository git init ls -la

Yeni bir gizli dizinin henüz oluşturulduğunu fark edeceksiniz. Bu .git klasörü, sürüm kontrol karmaları, taahhütler hakkında bilgiler, uzak havuz adresleri vb. gibi havuzla ilgili bilgileri depolamak için .git kullanılır. Bu aynı zamanda git .git/hooks için kancaların gerçekten yaşadığı klasördür. Başlatma sırasında otomatik olarak oluşturulan bazı önceden doldurulmuş örnek komut dosyalarını bulabilirsiniz. Bunlar aslında belirli eylemlerden sonra tetiklenecek olan komut dosyalarıdır.

 ls .git/hooks

Bulabileceğiniz örneklerden bazıları şunlardır:

• pre-commit.sample : taahhütte bulunmadan hemen önce çağrılır.
• commit-msg.sample : mesaj dosyasını yerinde düzenleyin.
• post-receive.sample : uzak depo güncellendikten sonra çağrılır.

Kaputun Altında

Artık kancaları nerede bulabileceğimizi bildiğimize göre, gerçekte nasıl çalıştıklarını anlamak için bir adım geriye gidelim.

Git kancaları olay tabanlıdır, bu nedenle geliştirme akışında bir git komutu yürüttüğümüz sürece git, çalıştırılacak ilişkili bir komut dosyası olup olmadığını bulmak için kancalar klasörlerini kontrol eder. Bu komut dosyalarının bazıları, bu geliştirme akışı eylemlerinden önce veya sonra çalışır.

Kancaların tetiklendiği akışın üzerinden geçmemiz ve daha spesifik olarak anlamamız için iyi bir örnek, oldukça tanıdık bir kullanım durumu olan taahhüt iş akışıdır.

Kod tabanımızda herhangi bir değişiklik yaptığımızda, bu ilgili kancalardan bazıları aşağıdaki sırayla tetiklenir:

1. pre-commit : taahhüt edilmek üzere olan anlık görüntüyü inceler ve neyin taahhüt edileceğini doğrular.
2. prepare-commit-msg : taahhüt eden yazar görmeden önce varsayılan mesajı düzenlemenizi sağlar.
3. commit-msg : taahhüt mesajını bir şablona ayarlar.
4. post-commit : taahhüt tamamlandıktan hemen sonra bir eylemi çalıştırır ve örneğin bir bildirim gönderir.

Yukarıdaki depoda, git kancalarının gerçekte nasıl çalıştığını daha fazla görselleştirmek için şimdi bazı özel işleme öncesi ve sonrası komut dosyaları eklemeye çalışalım.

 nano .git/hooks/pre-commit

Aşağıdaki parçacığı ekleyin:

 #!/bin/sh echo Changes are about to be committed

Komut dosyalarımızın yürütülebilir olduğundan emin olun:

 chmod +x .git/hooks/pre-commit

İşlem post-commit komut dosyası için yukarıdaki işlemi tekrarlayın:

 nano .git/hooks/post-commit

 #!/bin/sh echo Changes have been committed

 chmod +x .git/hooks/post-commit

Şimdi, yalnızca gösterim amacıyla küçük bir HTML parçacığıyla birlikte yeni bir dosya nano index.html ekleyebiliriz (HTML doğrulayıcılarının bunu bilmesine gerek yoktur).

 <h1>Hello world from our new repository!</h1>

Aşamalandırma yoluyla kod tabanımızdaki değişiklikleri ekleyeceğiz ve ardından bunu gerçekleştireceğiz:

 git add . git commit

Taahhüt başarıyla işlendikten sonra, yukarıda eklenen iki betiğin aşağıdaki çıktısını görebiliriz:

 Changes are about to be committed Changes have been committed

Beklendiği gibi git, işleme akışında kancaları tetikledi. Eklenen pre-commit ve taahhüt post-commit komut dosyaları çalışıyor ve doğru sırayla (daha önce bahsettiğimiz sıraya göre) yürütülecek.

Bu, taahhüt eden iş akışı komut dosyalarının nasıl çalıştığını ve nasıl yürütüldüklerini anlamak için basit bir gösteriydi. Bu iş akışı hakkında daha fazla ayrıntı için belgelerde daha fazlasını okuyabilirsiniz.

Yukarıdaki örnekte, bu iki betiği bash ile yazmayı seçtik ama gerçek şu ki git, istediğimiz herhangi bir betik dilinde yazılabilen kancaları destekliyor. Yürütülebilir komut dosyamızın ilk satırında doğru Shebang'ı ayarladığımız sürece Ruby, Python veya JavaScript harika alternatiflerdir.

Örneğin, pre-commit kancasını aşağıdaki gibi bir Node.js betiği olarak yeniden yazabiliriz:

 #!/usr/bin/env node console.log("Changes are about to be commited")

Yerel ve Uzak Kancalar

Kancalar yerel ve uzak (veya istemci ve sunucu) arasında ayrılır. Yerel kancalar yerel depodaki belirli eylemlerden önce veya sonra çalışırken, uzak kancalar sunucuya yapılan göndermelerden önce veya sonra çalışır. Yerel olanlar, doğaları geliştiricilerin bunları kolayca değiştirmesine izin verdiği için politikaları uygulamak için kullanılamaz. Çoğunlukla bir ekip içinde uygulamak istediğimiz bazı özel yönergelere bağlı kalmak için kullanılırlar. Depomuz için daha katı olmak ve bazı politikaları uygulamak istiyorsak, uzak kancalarda yaşarız.

Yerel Kancalar

• pre-commit
• prepare-commit-msg
• commit-msg
• post-commit
• applypatch-msg
• pre-applypatch
• post-applypatch
• pre-rebase
• post-rewrite
• post-checkout
• post-merge
• pre-push

Uzak Kancalar

• pre-receive
• update
• post-receive

Kancaları Paylaşmak

Git kancaları, onları ekip içinde paylaşmakla ilgilidir. Var olmalarının ana nedeni budur: daha iyi ekip işbirliğini teşvik etmek, zararlı süreçleri otomatikleştirmek ve yalnızca kod tabanının önemli bölümlerine odaklanmamıza izin vermek.

Daha önce belirtildiği gibi, .git/hooks , özelleştirilmiş kancalarımızı barındıran klasördür, ancak bu klasör git tarafından izlenmediğinden bu komut dosyalarını ekip içinde paylaşmamız gerektiğinde bu gerçekten yardımcı olmaz.

Bunu çözmek için iyi bir yaklaşım, tüm özel kancalarımızı havuzumuzdaki ayrı bir klasöre eklemektir. Örneğin, bir .githooks klasörü ekleyebilir ve yürütülebilir komut dosyalarını oraya kaydedebiliriz. Ardından, proje başlatıldığında, kancalarımızı .git/hooks tutmak için bu komut dosyalarını açıkça kopyalayabilir veya orijinal klasöre sembolik bağlayabiliriz.

 find .git/hooks -type l -exec rm {} \\; find .githooks -type f -exec ln -sf ../../{} .git/hooks/ \\;

Alternatif olarak, en son git sürümünü kullanıyorsanız ( 2.9 ve üzeri sürümlerden bahsediyorsanız), özel klasörümüze giden git hooks yolunu doğrudan yapılandırabiliriz:

 git config core.hooksPath .githooks

Git Kancaları Kolaylaştırıldı (Bir JavaScript Kod Tabanı Kullanım Örneği)

Git kancalarını kod tabanımızın ihtiyaçlarına daha fazla entegre etmemize yardımcı olan araçlar var. Özellikle JavaScript kod tabanları için, yapılandırma yoluyla git olaylarındaki eylemleri kolayca özelleştirebileceğimiz Husky vardır.

Örneğin, kolayca kodumuzu lint edebilir veya pre-commit olayında bazı testler çalıştırabilir ve linting, test veya her ikisinin de başarılı olup olmadığına bağlı olarak taahhütte bulunmaya devam edebiliriz.

Bu, package.json yapılandırmasını basitçe şu şekilde genişleterek gerçekleştirilebilir:

 { "scripts": { "test": "echo Running tests" }, "devDependencies": { "eslint": "5.16.0", }, "husky": { "hooks": { "pre-commit": "eslint . && npm test", } } }

Çözüm

Bu makalede, git deposunda gerçekleştirilen farklı eylemlerin isteğe bağlı olarak çalışacak özel komut dosyalarını tetikleyebileceğini öğrendik. Bu komut dosyaları yerel olarak geliştiricinin kontrolü altında olabilir veya bir ekip veya proje için daha merkezi olarak uzaktan yönetilebilir. Ayrıca komut dosyalarının genellikle bash gibi bir kabuk komut dosyasında yazıldığını, ancak JavaScript'i bile hemen hemen her komut dosyası dilini kullanabileceğini öğrendik.

Git kancaları, iyi tasarlanmış bir iş akışının gerçekten güçlü bir parçası olabilir ve onları denemenizi ve kendi projeleriniz için neler yapabileceğinizi görmenizi tavsiye ederim.