Git Sağlığı - depo hijyeni

Git Sağlığı, içindeki koda değil deponun nasıl kullanıldığına bakar: bayat dallar, incelemesiz merge’ler, korumalı dala force-push, aşırı büyük commit’ler ve benzeri hijyen sinyalleri.

Nasıl çalışır

• Projenin bağlı kimlik bilgisiyle sunucu tarafında, Git sağlayıcısına karşı çalışır - collector yok, CI adımı yok. Kimlik bilgisi olan her proje kapsamdadır. Dört Git sağlayıcısının tümü kapsamdadır - GitLab, GitHub, Bitbucket Cloud ve Azure DevOps Repos; bir sağlayıcının yanıtlayamadığı kural (örneğin Bitbucket’ta kaynak dalı silme varsayılanı) başarısız sayılmaz, atlanır.
• Taramalar kuyruğa alınır ve arka planda işlenir; projeden tetikleyebilir ya da zamanlı taramalara bırakabilirsiniz.
• Her kural dört durumdan biriyle bulgu üretir; proje skoru ağırlıklı bir toplamdır - force-push, adlandırma uyarısından ağır basar.

Merge kapıları ve push kuralları

Git Health dal korumasının kendisinin ötesinde, bir merge’ün gerçekte neyi gerektirdiğini ve korumanın hâlâ neye izin verdiğini okur:

• Onaylar - bir merge request en az bir onay, en az iki onay ister ve yazarı kendi değişikliğini onaylayamaz.
• Merge kapıları - merge için pipeline geçmeli ve tartışmalar çözülmeli.
• Varsayılan dala push - force push yok, merge request’i atlayan doğrudan push yok. Korumalı bir dal bile maintainer’ların ya da dalda adı verilen kişilerin doğrudan push yapmasına izin verebilir: bu yarım puan sayılır, geliştiricilerin push yapabilmesi hiç puan almaz. Korumasız dal bir kez, dal koruma kuralıyla bildirilir; iki push kuralı dal korunana kadar bekler.
• Etiketler - en az bir etiket korumalı; böylece yayınlanmış bir sürüm taşınamaz ya da silinemez. Proje sürümlerini etiketle takip ediyorsa bu etiketleri sürüm koruma kuralı kontrol eder ve bu kural geri çekilir.

Bunlar GitLab ve GitHub’da okunur; Bitbucket Cloud ve Azure DevOps bunları henüz okunmayan dal politikalarında tutar, bu yüzden kurallar orada uygulanmaz. Etiket koruması yalnızca GitLab’da okunur.

Dikkat

Onaylar lisanslı GitLab ister. Merge request onayları bir GitLab Premium / Ultimate özelliğidir. GitLab Free kurulumunda üç onay kuralı onay ayarları lisanslı GitLab gerektiriyor gerekçesiyle atlanır (başarısız sayılmaz); diğer kurallar yine yanıtlanır. GitHub’da bunlar için lisans gerekmez.

Pipeline kuralları gizli bilgi ve bağımlılık taramasının yanında statik güvenlik analizi (SAST) adımına, container imaj taramasına ve üretilmiş bir yazılım malzeme listesine (CycloneDX veya SPDX) de bakar. Include edilen dosyalar da okunur, GitLab şablonları dahil: GitLab’ın bağımlılık ve imaj tarama şablonları kendileri CycloneDX SBOM üretir. Merge request ve issue şablonları depodaki dosyalar olarak kontrol edilir.

Not

Git Health ve Uyumluluk işi paylaşır: Git Health sağlayıcı ayarlarını ve pipeline’ı okur (dal koruması, merge kapıları, CI adımları, commit edilmiş gizli dosyalar), Uyumluluk deponun kendi dokümanlarını okur (README, .gitignore, SECURITY.md, .editorconfig). Bir eksik ikisinden yalnızca biri tarafından bildirilir.

Sonuçları okumak

• Proje skoru ve notu, arkasındaki bulgularla; her bulgu neyin gözlendiğini ve neden önemli olduğunu açıklar.
• Çalışma alanı görünümü - hangi projeler kapsandı, hangileri hiç taranmadı (hiç taranmamış bilinmiyor olarak raporlanır, sağlıklı olarak değil).
• Yönetim alanı aynı resmi kurulum genelinde gösterir.

Not

Kurallar çalışma alanı başına ayarlanabilir; iş akışınıza uymayan kural tartışılmaz, kapatılır.

İş anahtarları, Sonar ve sürümler

• Dal kuralı iş anahtarı istiyor (GIT_BRANCH_RULE_REQUIRES_ISSUE_KEY, GitLab) - projenin push kuralı (branch name regex) okunur. Kural anahtarsız dalı (feature/add-login) reddedip anahtarlıyı (feature/PROJ-123-add-login ya da küçük harfle feature/proj-123-...) kabul ediyorsa geçer. Desen nasıl yazıldığına göre değil, örnek dal adlarına ne yaptığına göre değerlendirilir.
• Sonar sonuçları merge request’te (CI_SONAR_MR_REPORT) - pipeline SonarQube sonucunu merge request’e yazar: açıklamaya yazan bir job ya da Sonar’ın kendi merge request analizi (sonar.pullrequest.key). SonarQube içermeyen pipeline’da bu kural atlanır; o eksikliği SonarQube kuralı raporlar.
• Küçük harfli iş anahtarları sayılır: dal adı kuralında bugfix/proj-123, bugfix/PROJ-123 kadar açık bir iştir.
• Sürüm aktarımları - bir release/ dalını varsayılan dala alan merge request sürümün tüm işlerini taşır; commit kuralında merge commit’lerin sayılmaması gibi, merge request başlığı kuralında sayılmaz.
• Joker desenle koruma - bir desenle (release/*) korunan dal, sürüm dalı kuralında ve her yerde korumalı sayılır.
• Kilit dosyaları üç klasör derinliğe kadar aranır (src/<katman>/<Proje>/packages.lock.json), önce kod klasörleri; taramanın bitiremediği bir arama eksik değil atlandı olur.

Kapatılan kurallar

Bu kurallar artık çalışmaz. Önceki taramaların bulguları geçmişte kalır; aynı soruyu artık hangi kuralın yanıtladığı her birinin yanında yazar.

Kural	Yerine geçen	Neden
REPO_README_PRESENT	Uyumluluk DOC_README_EXISTS	Deponun dokümanlarını Uyumluluk kontrol eder; aynı eksik dosya iki modülde birden bildiriliyordu.
REPO_GITIGNORE_PRESENT	Uyumluluk REPO_GITIGNORE_EXISTS	Aynı sebep.
REPO_SECURITY_MD_PRESENT	Uyumluluk SEC_POLICY_EXISTS	Aynı sebep.