index.html.haml 9.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179
  1. ---
  2. description: Değişiklik kaydı tutun
  3. title: Değişiklik kaydı tutun
  4. language: tr-TR
  5. version: 0.3.0
  6. ---
  7. :markdown
  8. # CHANGELOG dosyası kullanın
  9. ## Arkadaşlarınızın git kayıtlarını CHANGELOG dosyalarına boşaltmasını engelleyin™
  10. ### Nedir bu değişiklik kayıtları?
  11. Değişiklik kayıtları bir proje için özel olarak hazırlanmış, tarihsel sıralamayla
  12. sıralanmış, önemli değişikliklerin bir bütünüdür.
  13. %pre.changelog= File.read("CHANGELOG.md")
  14. :markdown
  15. ### Değişikliklerin kayıtlarını tutmanın anlamı ne?
  16. Bir projenin kullanıcılarının ya da katılımcılarının, dağıtımlar (ya da sürümler)
  17. arasındaki tam olarak hangi önemli değişikliklerin olduğunu takip edebilmelerini sağlar.
  18. ### Neden umrumda olsun ki?
  19. Çünkü yazılım paketleri insanlar içindir. Eğer umrunuzda değilse neden açık kaynağa
  20. katkıda bulunuyorsunuz ki? Mutlaka sevimli beyninizin bir yerlerinde bunu önemseyen
  21. bir çekirdek (a-ha!) vardır.
  22. [Adam Stacoviak ve Jerod Santo ile Changelog Podcast'inde][thechangelog](uyuyor,
  23. değil mi?) neden geliştiricilerin ve katılımcıların umrunda olması gerektiğini ve
  24. bu projenin arkasındaki motivasyonu konuştuk. Eğer vaktiniz varsa (1:06) iyi bir
  25. söyleşi oldu.
  26. ### Bir değişiklik kaydını iyi yapan nedir?
  27. Bunu sorduğunuza sevindim.
  28. İyi bir değişiklik kaydı şu prensiplere bağlıdır:
  29. - İnsanlar için yapılmıştır, makineler için değil, yani okunurluğu kritik.
  30. - Kolayca bölümler arası bağlantı kurulabilmeli (bu yüzden yalın metin yerine markdown).
  31. - Her sürüm için bir alt bölüm.
  32. - Dağıtımları tersine tarih sırası ile listeleyin (en yeni en üstte).
  33. - Tüm tarihleri `YYYY-AA-GG` biçiminde yazın. (Örneğin `2 Haziran 2012` için `2012-06-02`.) Uluslararasıdır, [anlamlıdır](http://xkcd.com/1179/), ve lisan bağımsızdır.
  34. - [Anlamsal sürümlemeyi][semver] destekleyip desteklemediğini özellikle belirtin.
  35. - Her sürümde olması gerekenler:
  36. - Üstteki biçimde dağıtım tarihi.
  37. - Projeye etkileri bakımından değişiklikleri gruplayın, şöyle ki:
  38. - `Eklendi`: yeni özellikler için.
  39. - `Değişti`: var olan beceriler değiştiyse.
  40. - `Rafa kalktı`: gelecekte yok olacak var olan beceriler.
  41. - `Kaldırıldı`: bu sürümde kaldırılan, daha önce rafa kaldırılmış olan beceriler.
  42. - `Düzeltildi`: ayıklanmış hatalar için.
  43. - `Güvenlik`: açıkları kapatabilmeleri için kullanıcıları bilgilendirin.
  44. ### Gerekli çabayı nasıl en aza indirebilirim?
  45. Her zaman en üstte değişiklikleri takip ettiğiniz bir `"Yayımlanmadı"` bölümü olsun.
  46. Bu, iki amaca hizmet eder:
  47. - İnsanlar gelecek sürümlerde karşılarına ne gibi değişiklikler çıkacağını görebilirler
  48. - Dağıtım zamanı geldiğinde `"Yayımlanmadı"` başlığını sürüm numarası ile değişitip
  49. tepeye yeni bir `"Yayımlanmadı"` bölümü eklemeniz yeterli.
  50. ### Tek boynuzlu atları ağlatan ne?
  51. Peki… Gelelim sadede.
  52. - **Commit kayıtlarının farkını yüklemek.** Sakın bunu yapmayın, kimseye yardım etmiyorsunuz.
  53. - **Rafa kalkanları ön plana çıkarmamak.** Kullanıcılar bir sürümden diğerine
  54. yükseltme yaptıklarında neyin bozulabileceği apaçık ortada olmalı.
  55. - **Bölgesel biçimlenmiş tarihler.** ABD'de insanlar ay bilgisini önce kullanıyor
  56. ("06-02-2012" demek 2 Haziran 2012 demek yani, ki tamamen *saçma*), diğer taraftan
  57. dünyanın bir çok bölgesinde "2 Haziran 2012" gibi robotik bir yapı kullanıp farklı
  58. şekilde dile getiriyor. "2012-06-02" hem mantıksal olarak en büyüğünden en küçüğüne çalışıyor,
  59. hem de diğer tarih biçimleriyle çakışmıyor. Aynı zamanda [ISO standardında](http://www.iso.org/iso/home/standards/iso8601.htm).
  60. Bu yüzden değişiklik kayıtları için önerilen tarih biçimidir.
  61. Dahası da var. Bu tek boynuzlu at gözyaşlarını toplamak için
  62. [bir başlık açın][issues]
  63. ya da bir çekme isteği (pull request) gönderin.
  64. ### Standart bir değişiklik kaydı biçimi var mı?
  65. Ne yazık ki hayır. Sakin olun. Biliyorum, şu an alelacele GNU değişiklik kaydı
  66. stil rehberi için bağlantı arıyorsunuz, ya da iki paragraflık GNU NEWS dosyasına
  67. bakınıyorsunuz. GNU stil rehberi iyi bir başlangıç fakat üzücü derece naif.
  68. Naif olmakta yanlış bir şey yok, fakat insanlar rehberlik aradığında nadiren
  69. yardımcı oluyorlar. Özellikle ortada uğraşılacak bir çok durum ve uç örnekler
  70. mevcutken.
  71. Bu proje [umuyorum ki daha iyi CHANGELOG dosyaları için bir altyapı oluşturacak][CHANGELOG].
  72. Mevcut durumun çok iyi olduğunu düşünmüyorum, ve topluluk olarak, gerçek yazılım
  73. projelerinden iyi pratikleri toplayarak bundan daha iyisini yapabiliriz. Lütfen
  74. etrafa bir göz gezdirin ve unutmayın [gelişme yolunda tartışmalara ve önerilere her zaman açığız][issues]!
  75. ### Değişiklik kayıtlarının dosya ismi ne olmalı?
  76. Eh, üstteki örnekten çıkartamadıysanız eğer, `CHANGELOG.md` şu ana kadarki
  77. en iyi çözüm.
  78. Bazı projeler `HISTORY.txt`, `HISTORY.md`, `History.md`, `NEWS.txt`, `NEWS.md`,
  79. `News.txt`, `RELEASES.txt`, `RELEASE.md`, `releases.md` vb de kullanıyor.
  80. Tam bir karmaşa. Tüm bu isimler insanların bu dosyayı bulmasını zorlaştırıyor.
  81. ### Neden `git log` farkları kullanılmasın?
  82. Çünkü kayıt farkları bir sürü gürültü içerir - doğal olarak. Mükemmel insanlar
  83. tarafından yürütülen, hiç yazım hatasının yapılmadığı, dosyaların gönderilmesinin
  84. hiç unutulmadığı, refaktör yapılmasının atlanmadığı varsayımsal bir projede bile
  85. uygun bir değişiklik kaydı oluşmayacaktır. Dosyaları repoya göndermenin amacı
  86. atomik seviyede kodun bir durumdan diğerine geçişinin sağlanmasıdır. Değişiklik
  87. kayıtları ise bu durumlar arasında, önem arz eden değişiklikleri belgelemeyi
  88. amaçlıyor.
  89. İyi yorumlar ve kodun kendisi arasındaki fark,
  90. aynı şekilde değişiklik kayıtları ve commit kayıtları arasındaki gibidir:
  91. biri *neden* olduğunu, diğeri nasıl olduğunu açıklar.
  92. ### Değişiklik kayıtları otomatik olarak toplanabilir mi?
  93. Zor, çünkü insanlar bir çok farklı biçim ve dosya isimleri kullanıyorlar.
  94. [Vandamme][vandamme], [Gemnasium][gemnasium] ekibi tarafından oluşturulmuş
  95. bir Ruby Gem'idir ve bir çok (hepsini değil) açık kaynaklı projenin değişiklik
  96. kayıtlarını ayrıştırabiliyor.
  97. ### Neden arada bir "CHANGELOG" ve arada bir "değişiklik kaydı" yazıyorsun?
  98. "CHANGELOG" dosyanın ismi. Biraz fazla şaşalı ama bir çok açık kaynak kodlu
  99. proje tarafından uygulanan tarihi bir gelenek. Benzer dosyalar da var;
  100. [`README`][README], [`LICENSE`][LICENSE], ve [`CONTRIBUTING`][CONTRIBUTING].
  101. Büyük harfle isimlendirme (eski işletim sistemlerinde dosyaların tepede
  102. gözükmelerini sağlardı) dikkat çekmek için. Proje hakkında önemli meta verileri
  103. içerdikleri için, kullanmak ya da katkıda bulunmak isteyen herkesin işine
  104. yarar, tıpkı [açık kaynaklı proje rozeleri][shields] gibi.
  105. "Değişiklik kaydı"ndan bahsettiğim zamanlar bu dosyanın işlevinden bahsediyorum:
  106. Değişiklikleri kaydetmek.
  107. ### Peki ya Geri çekilen dağıtımlar?
  108. Geri çekilen dağıtımlar, önemli hatalar ya da güvenlik sebepleri nedeniyle
  109. yayından geri çekilen sürümlerdir. Genelde bu sürümler değişiklik kayıtlarında
  110. görüntülenmezler. Görünmeliler. Tam da şu şekilde görünmeliler:
  111. `## 0.0.5 - 2014-12-13 [GERİ ÇEKİLDİ]`
  112. `[GERİ ÇEKİLDİ]` etiketi belirli bir sebepten büyük harf. İnsanların bunu fark
  113. etmeleri çok önemli. Ayrıca köşeli parantezler ile çevrelenmiş olması
  114. programatik olarak da ayrıştırılabilmeine olanak sağlıyor.
  115. ### Değişiklik kayıtlarınızı tekrar yazmalı mısınız?
  116. Tabii ki. Her zaman değişiklik kayıtlarını geliştirmek için iyi sebepler vardır.
  117. Düzenli olarak açık kaynaklı projelerde bakım yapılmayan değişiklik kayıtları
  118. için çekme istekleri yapıyorum.
  119. Ayrıca bir sürümdeki notların arasında önemli bir değişiklikten bahsetmeyi
  120. unutmuş olduğunuzu fark edebilirsiniz. Değişiklik kütüğünüzü bu bilgi ışığında
  121. güncellemeniz gerekliliği gün gibi ortada.
  122. ### Nasıl katkıda bulunabilirim?
  123. Bu belge **doğrunun kendisi** değil; benim hesaplı görüşlerimdir. Beraberinde
  124. toparlamış olduğum bilgiler ve örnekler bulunur.
  125. [GitHub repo][gh]sunda güncel bir [CHANGELOG][] sağlıyor olsam da, özellikle
  126. bir *sürüm* ya da ([SemVer.org][semver] benzeri) takip edilecek kurallar
  127. oluşturmadım.
  128. Bunu istememin sebebi topluluğun ortak bir paydada buluşmasını istememdir.
  129. İnanıyorum ki tartışmanın kendisi de sonucu kadar önemli.
  130. Yani lütfen, [**siz de katılın**][gh].
  131. [CHANGELOG]: https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md
  132. [CONTRIBUTING]: https://github.com/olivierlacan/keep-a-changelog/blob/master/CONTRIBUTING.md
  133. [LICENSE]: https://github.com/olivierlacan/keep-a-changelog/blob/master/LICENSE
  134. [README]: https://github.com/olivierlacan/keep-a-changelog/blob/master/README.md
  135. [gemnasium]: https://gemnasium.com/
  136. [gh]: https://github.com/olivierlacan/keep-a-changelog
  137. [issues]: https://github.com/olivierlacan/keep-a-changelog/issues
  138. [semver]: http://semver.org/
  139. [shields]: http://shields.io/
  140. [thechangelog]: http://5by5.tv/changelog/127
  141. [vandamme]: https://github.com/tech-angels/vandamme/