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 halini kullanın. Zorunlu ruh hali size birilerine talimat veriyormuş gibi geliyor, "Değiştir", "Ekle", "Düzelt", "Kaldır", "Güncelle", "Refactor" veya "Belge" gibi kelimelerle başlayabilir. İyi örnekler "Add Badge::query for querying the API" veya "Allow zeroes in SimpleBadge::add". Kötü örnekler "Added Badge::query method" veya "Fixed Badge::query method", veya "Badge can query the API" ve "Zeroes work when adding badges" olurdu.
 * Konu satırını 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ı:


 * Boş bir çizgi ile gövde süjeden ayırın.
 * İleti gövdesini satırlar 100 karakterden kısa olacak şekilde sarın. Ancak, URL'leri kırmayın veya sarmayın, daha uzun olsalar bile saklayın.
 * Aşağıdaki örneklerde olduğu gibi "Bug" ve "Change-Id" meta verilerini biçimlendirin ve boş bir satırdan sonra bunları gövdenin sonuna yerleştirin.
 * Bir (kısa) Git kesin karması kullanarak diğer (birleştirilmiş) işlemlere başvurun. Gerekirse, Change-Id Gerrit kullanarak henüz birleştirilmemiş taahhütlere bakın.

Yapılmaması:


 * Gerrit URL'si olan diğer işlemlere atıfta bulunmayın, bunun yerine Git taahhüt karmasını kullanın. 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.

İ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. Therefore, do not mention Phabricator tasks, Git commits, or urls inside the subject line. Instead, mention those in the body text, or footer meta-data. That way, they can be universally selected, copied, or clicked.


 * Gerrit uses the subject in: email notifications, IRC notifications, search results.
 * GitHub uses the subject in: commit history, commit subject.
 * The Git CLI uses the subject in:,  ,  ,  , etc.
 * and much more!
 * and much more!

Component
You may start the subject line with a component, which will indicate what area of the project is changed by your commit.

It should be one of the following:


 * A directory of PHP classes under  or , such as "installer", "jobqueue", "objectcache", "resourceloader", "rdbms", etc.
 * A PHP class name, such as "Title", "User", "OutputPage", etc.; typically for classes without subdirectory in.
 * ResourceLoader module name (like "mediawiki.Title", "mediawiki.util", etc.).
 * Generic keyword affecting multiple areas relating to the type of change, such as:
 * "build" - for changes to files relating to the development workflow, such as updates to,  , etc.
 * "tests", "qunit", "phpunit" - for changes that only affect unit or integration test suites, or the test suite runners.

Phabricator
To reference a bug or task, in the commit message mention it inline using the Txxx notation (e.g. " That was caused by T169. ")

To express that a commit resolves (even partially) or is specially relevant to a bug, add  in the footer at the end of the commit message. (If you're amending a commit message, insert it immediately above the  line, without an empty line between them.)

Bug: T169

A bot will automatically leave a comment on the Phabricator task about any significant events (being merged, abandoned, etc.). If a patch resolves two or more bugs, put each  reference on its own line at the bottom.

Cross-references
Whenever you refer to another commit, use the SHA-1 git hash of the merged commit. If the commit in still pending review, use the Gerrit Change-Id hash instead of the git hash because the hash relates to an individual patch set (which changes when rebased, thus creating a dead-end).

Change-Id
's  tool will automatically append the "Change-Id: Ixxx" keyword to new commits.

Dependencies
If you have cross-repo dependencies (your commit depends on another commit in a different repository), declare them by adding  to the last paragraph. ("Ixxx"... is the  of the other commit.) This will instruct Zuul to test the commit together with that one.