Gerrit/Commit message guidelines/tr

Yaptığınız değişikliğin taahhüt mesajı önemli bir rol oynar. Diğer insanların sizin değişikliğiniz hakkında ilk görecekleri şey.

Konu
İşlem mesajının ilk satırı konu olarak bilinir. Konu 80 karakterden kısa olmalıdır (50-70 hedefi).
 * Konu satırındaki değişikliğinizi özetleyin. Bunun sonsuza kadar depoda olacağını unutmayın.
 * Konu satırınızdaki zorunlu ruh hâlini kullanın. Zorunlu ruh hâli, birisine talimat veriyormuşsunuz gibi geliyor ve "Değiştir", "Düzelt", "Ekle", "Kaldır", "Belge", "Yeniden Düzeltme" gibi kelimelerle başlayabilir.
 * İyi örnekler, "API'yi sorgulamak için Badge::query ekle", "SimpleBadge içinde API sorgusunu önleyin" ve "SimpleBadge::add'de sıfırları destekleyin".
 * Kötü örnekler "Badge::query yöntemi eklendi", "Badge::sorgu yöntemi düzeltildi", "Rozet API'yi sorgulayabilir", "Rozet API sorguları yapmaz" veya "Rozet eklerken sıfırlar çalışır" olurdu.
 * Your subject line should be short, clearly state what your commit is changing. It should not be possible to use the same subject line for two commits that do different things. People will read your subject line out of context, as it passes by in change feeds, code review emails, git-blame logs, release notes, deployment changelog, etc. A good subject line helps decide quickly whether this commit among many will be relevant to a given interest or concern.
 * Good examples: "badger: Add accessibility labels to form fields", "rdbms: Avoid infinite loop on null input", and "htmlform: Change colours to match April 2020 design".
 * Bad examples: "Implement accessibility fixes", "Don't crash", or "Make prettier with a better design".


 * Konu satırını nokta/tam nokta ile sonlandırmayın.
 * İsteğe bağlı olarak, konunun önüne ilgili bileşen öneki ekleyin. Bileşen, taahhüdünüzün değişeceği genel alandır.

Gövde
Gövde metnini yazarken aşağıdaki soruları düşünün:
 * Bu değişiklik neden yapılmalıdır? Mevcut kodda sorun nedir?
 * Neden bu şekilde değiştirilmeli? Başka yollar var mı?
 * Başka yaklaşımlar düşündünüz mü? Öyleyse, neden bu kadar iyi olmadıklarını açıklayın.
 * Bir yorumcu kodunuzun doğru çalışıp çalışmadığını nasıl test edebilir veya doğrulayabilir?

Yapılması:
 * … gövdeyi özneden bir boş satırla ayırın.
 * … mesajı satırlar maksimum 100 karakter uzunluğunda olacak şekilde sarın. Many editors/tools can do this automatically; 72 characters is a common width to wrap at. Ancak, URL'leri 'uydurmak' için bozmayın, çünkü bu onları tıklanamaz hâle getirir; daha uzun olsalar bile onları saklayın.
 * … birleştirilmişlerse (kısa) Git taahhüt karmasını kullanarak diğer taahhütlere bakın. Henüz birleştirilmedilerse, Gerrit Change-Id kullanarak bunlara bakın.

Yapılmaması:


 * … refer to other commits with a Gerrit URL.
 * Instead, use the Git commit hash. Bu, çevrimdışı olduğunda Git deposunda kolay gezinmeyi sağlar. Ayrıca, tüm depo görüntüleyicilerinin (Gerrit, Gitiles, Phabricator, GitHub ve yerel Git arabirimleri) kullanıcılarının aynı arabirimdeki diğer işlemlere otomatik olarak gitmelerini sağlar. Bir URL yalnızca çevrimiçi olduğunda ve insanların hızlı bir şekilde gezinmesini engelleyen Gerrit kullanıldığında çözülebilir.
 * * Değişiklik için tek açıklama olarak URL kullanmayın.
 * Değişiklik, başka yerlerdeki tartışmalar veya harici belgelerle gerekçelendiriliyorsa, taahhüt mesajındaki ilgili noktaları kısaca özetleyin.

Footer and meta-data
The most important information of the footer is the  (mandatory) and.


 * Aşağıdaki örneklerde olduğu gibi " " ve " " meta verilerini biçimlendirin ve boş bir satırdan sonra bunları gövdenin sonuna yerleştirin.

Find more information on individual meta-data fields below.

İyi örnek
jquery.badge: Add ability to display the number zero

Cupcake ipsum dolor sit. Amet tart cheesecake tiramisu chocolate cake topping. Icing ice cream sweet roll. Biscuit dragée toffee wypas.

Does not yet address T44834 or T176. Follow-up to Id5e7cbb1.

Bug: T42 Change-Id: I88c5f819c42d9fe1468be6b2cf74413d7d6d6907

Kötü örnek
Improved the code by fixing a bug.

Changed the files a.php and b.php

Bug: T42 Change-Id: I88c5f819c42d9fe1468be6b2cf74413d7d6d6907

Konu
Git komutunu görüntülediğimiz çoğu program, konu satırını düz metin olarak işler. Bu, URL'lerin çalışmadığı ve metnin sıklıkla seçilmesi/kopyalanmasının mümkün olmadığı anlamına gelir. Bu nedenle, konu satırında Phabricator görevlerinden, Git taahhütlerinden veya URL'lerinden bahsetmeyin. Bunun yerine, gövde metninden veya altbilgi meta verilerinden bahsedin. Bu şekilde, evrensel olarak seçilebilir, kopyalanabilir veya tıklayabilirler.


 * Gerrit şu konuyu kullanır: e-posta bildirimleri, IRC bildirimleri, arama sonuçları.
 * GitHub şu konuyu kullanır: kesinleştirme geçmişi, kesinleştirme konusu.
 * Git CLI aşağıdaki konuyu kullanır:,  ,  ,  , etc.
 * ve daha fazlası!
 * ve daha fazlası!

Bileşen
Konu satırına, taahhüdünüz tarafından projenin hangi alanının değiştirildiğini belirten bir bileşenle başlayabilirsiniz.

Aşağıdakilerden biri olmalıdır:
 * "installer", "jobqueue", "objectcache", "resourceloader", "rdbms", vb. gibi  veya   altındaki PHP sınıfları dizini
 * "Title", "User", "OutputPage", vb. gibi bir PHP sınıf adı; tipik olarak  içinde alt dizini olmayan sınıflar için.
 * ResourceLoader modül adı ("mediawiki.Title", "mediawiki.util", vb. gibi).
 * Değişiklik türüyle ilgili birden çok alanı etkileyen genel anahtar kelime, örneğin:
 * "build" - $1 -,  , vb. güncellemeleri gibi geliştirme iş akışıyla ilgili dosyalarda yapılan değişiklikler için
 * "tests", "qunit", "phpunit" - "$1", "$2", "$3" - yalnızca birim veya entegrasyon test takımlarını veya test takımı çalıştırıcılarını etkileyen değişiklikler için.

Phabricator
bir hataya veya göreve başvurmak için, taahhüt mesajında Txxx gösterimini kullanarak satır içinde belirtin (ör. "That was caused by T169.")

Bir taahhüdün çözüldüğünü (kısmen de olsa) veya bir hatayla özellikle ilgili olduğunu ifade etmek için, taahhüt mesajının sonuna altbilgiye  ekleyin. (Bir işlem mesajını değiştiriyorsanız, bunu, aralarında boş bir satır olmadan  satırının hemen üstüne ekleyin. Genel yapı kurallarına uymayı ve gövdeyi konudan bir boş satırla ayırmayı unutmayın.)

Bug: T169

Bir bot otomatik olarak Phabricator'ın görevi hakkında önemli olaylar (birleştirilmiş, terk edilmiş vb.) hakkında bir yorum bırakacaktır. Bir yama iki veya daha fazla hatayı giderirse, her  kaynağı altta kendi satırına koyun.

Bug: T299087 Bug: T299088

Çapraz kaynaklar
Ne zaman başka bir işleme başvurursanız, birleştirilmiş işlemin SHA-1 git karmasını kullanın. Hâlâ incelenmeyi bekliyorsa, git ayrı karması yerine Gerrit Change-Id karmasını kullanın, çünkü karma ayrı bir yama kümesiyle ilgilidir (yeniden temel alındığında değişir, böylece çıkmaz oluşturur).

Change-Id
'in  aracı otomatik olarak " " anahtar kelimesini yeni taahhütlere ekleyecektir.

Bağımlılıklar
Çapraz repo bağımlılığı (taahhüdünüz farklı bir depodaki başka bir işleme bağlıysa) varsa, son paragrafa  ekleyerek bunları beyan edin. ("Ixxx"... diğer taahhütlerin .) Bu Zuul'a taahhüdü bununla birlikte test etmesini söyleyecektir.

Başkalarına katkı vermek
Değişiklik üzerinde çalışan diğer geliştiricilere katkı vermek için bu satırı Change-id'den önce ekleyin. Satır sonu ile ayrılmış birden fazla ekleyebilirsiniz.

Daha fazla okuma

 * Node.js Taahhüt Kuralları
 * Git Temel Taahhüt Kuralları
 * jQuery Taahhüt Kuralları
 * Erlang Taahhüt Kuralları
 * Git Tamamlama Mesajları Hakkında Bir Not - Tim Pope tarafından
 * Git Tamamlama Mesajı Nasıl Yazılır - Chris Beams tarafından
 * Gerrit integrations with the Puppet Catalogue Compiler
 * Git Tamamlama Mesajı Nasıl Yazılır - Chris Beams tarafından
 * Gerrit integrations with the Puppet Catalogue Compiler