feat: add blog post about conventional commits
This commit is contained in:
@@ -8,39 +8,43 @@ excerpt: "Yazılım geliştirme sürecinde yalnızca kod yazmıyoruz; aynı zama
|
|||||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/1*WQOgajPE2m4aYuVC3SZoFQ.jpeg"
|
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/1*WQOgajPE2m4aYuVC3SZoFQ.jpeg"
|
||||||
---
|
---
|
||||||
|
|
||||||
Yazılım geliştirme sürecinde yalnızca kod yazmıyoruz; aynı zamanda takım iletişimini ve proje geçmişini de yönetiyoruz. Commit mesajları bu süreçte kritik rol oynar. Conventional Commits, commit geçmişini daha anlaşılır ve sürdürülebilir hale getiren pratik bir standarttır.
|
# Yazılım Projelerinde Düzen ve Verimlilik İçin: **Conventional Commits Nedir?**
|
||||||
|
|
||||||
## Conventional Commits Nedir?
|
Yazılım geliştirme sürecinde, kod yazmanın ötesinde pek çok detayla uğraşıyoruz. Commit mesajları da bu sürecin kritik bir parçası tabii ki. Ancak commit mesajları, bazen dağınık, anlaşılmaz ve düzensiz olabiliyor. İşte bu noktada **“Conventional Commits”** devreye giriyor.
|
||||||
|
|
||||||
Conventional Commits, commit mesajlarını belirli bir formatta yazmayı öneren bir standarttır. Her commit'in amacı daha hızlı anlaşılır; release notları, sürümleme ve ekip içi takip süreçleri kolaylaşır.
|
## Conventional Commits **Nedir?**
|
||||||
|
|
||||||
## Neden Kullanmalıyız?
|
Conventional Commits, commit mesajlarınızı belirli bir formata oturtan bir yazılım standardı. Amaç, her commit’in ne yaptığını net bir şekilde ifade etmek ve proje geçmişini daha anlaşılır hale getirmek. Commit mesajlarınızı bu standarda göre yazmak, projeyi daha düzenli, takip edilebilir ve sürdürülebilir kılar. Gelin şimdi beraber inceleyelim.
|
||||||
|
|
||||||
### 1. Anlaşılabilirlik
|
## Neden Conventional Commits **Kullanmalıyız?**
|
||||||
|
|
||||||
Commit geçmişi daha okunabilir olur. Özellikle büyük projelerde hangi commit'in neyi değiştirdiğini bulmak çok daha hızlı hale gelir.
|
### 1. **Anlaşılabilirlik**
|
||||||
|
|
||||||
### 2. İzlenebilirlik ve Şeffaflık
|
Commit geçmişinin anlaşılabilir olması hepimiz için önemli. Bu standart, projede yapılan değişikliklerin kolayca takip edilmesini sağlıyor. Büyük projelerde, hangi commit’in hangi sorunu çözdüğünü veya hangi yeni özelliği eklediğini anlamak zaman zaman zorlaştığı için bu gibi standartları kullanmak yazılımcıların işini kolaylaştırıyor.
|
||||||
|
|
||||||
Hangi değişikliğin bug fix, hangisinin yeni özellik olduğu netleşir. Geriye dönük analiz ve hata takibi kolaylaşır.
|
### 2. İzlenebilirlik ve **Şeffaflık**
|
||||||
|
|
||||||
## Commit Mesajı Yapısı
|
Commit mesajlarımızı tutarlı ve net hale getirmek, proje geçmişimizde yapılan değişikliklerin izlenmesini kolaylaştırıyor. Özellikle geriye dönük uyumluluğu bozan değişikliklerde, bu düzenlemeler büyük bir avantaj sağlıyor.
|
||||||
|
|
||||||
Conventional Commits'te mesaj genelde üç bölümden oluşur:
|
## Peki Bu Commit Mesajları **Nasıl Yazılıyor?**
|
||||||
|
|
||||||
- **Başlık (Summary)**: Tür + kısa açıklama
|
Conventional Commits’e göre, her commit mesajı üç ana bölümden oluşur:
|
||||||
- **Gövde (Body)**: Değişikliğin nedeni ve detayları
|
|
||||||
- **Altbilgi (Footer)**: Breaking change veya issue referansları
|
|
||||||
|
|
||||||
## Sık Kullanılan Türler
|
- **Başlık (Summary):** Mesajın türünü ve kısaca ne yaptığını belirtir.
|
||||||
|
- **Gövde (Body):** Değişikliğin detaylarını açıklar. Neden yapıldığını ve nasıl yapıldığını anlatır.
|
||||||
|
- **Altbilgi (Footer):** Breaking changes gibi uyumluluğu bozan değişiklikler veya kapatılan sorunlar burada belirtilir.
|
||||||
|
|
||||||
- `feat`: Yeni özellik
|
## Commit **Türleri**
|
||||||
- `fix`: Hata düzeltmesi
|
|
||||||
- `docs`: Dokümantasyon değişikliği
|
|
||||||
- `style`: Format/stil düzeni (işlev değişmez)
|
|
||||||
- `refactor`: Davranışı değiştirmeden kod iyileştirme
|
|
||||||
|
|
||||||
## Örnek Commit
|
Commit mesajları belirli türlerle başlar. İşte en yaygın kullanılan türler: [Daha detaylı commit türlerini incelemek için tıklayın.](https://www.conventionalcommits.org/en/v1.0.0/)
|
||||||
|
|
||||||
|
- **feat:** Yeni bir özellik eklenmesi.
|
||||||
|
- **fix:** Bir hatanın düzeltilmesi.
|
||||||
|
- **docs:** Sadece dokümantasyonla ilgili değişiklikler.
|
||||||
|
- **style:** Kodun işleyişini değiştirmeyen biçimlendirme (boşluklar, noktalı virgüller vb.).
|
||||||
|
- **refactor:** Kodda, işlevini değiştirmeyen yeniden düzenleme.
|
||||||
|
|
||||||
|
### Gelin beraber örnek bir **Commit Mesajını** inceleyelim:
|
||||||
|
|
||||||
```text
|
```text
|
||||||
feat(login): add JWT authentication
|
feat(login): add JWT authentication
|
||||||
@@ -51,17 +55,37 @@ This change involves updating the login controller and modifying the user model.
|
|||||||
BREAKING CHANGE: The user model now requires a JWT token for all login operations.
|
BREAKING CHANGE: The user model now requires a JWT token for all login operations.
|
||||||
```
|
```
|
||||||
|
|
||||||
Bu örnekte:
|
#### 1. Başlık **(Summary)**
|
||||||
|
|
||||||
- `feat(login)` kısmı değişikliğin türünü ve kapsamını açıklar.
|
- **feat:**
|
||||||
- Body kısmı neyin ve neden yapıldığını anlatır.
|
Commit türünü belirtir. Burada feat (feature) türü kullanılmış, bu da commit'in projeye yeni bir özellik eklediğini gösterir. Başka türler de kullanılabilir, örneğin fix (bir hatayı düzeltmek), docs (dokümantasyon güncellemeleri) gibi.
|
||||||
- `BREAKING CHANGE` ifadesi geriye dönük uyumluluğu etkileyen bir güncelleme olduğunu belirtir.
|
- **(login):**
|
||||||
|
Parantez içinde belirtilen bölüm, bu özelliğin veya değişikliğin hangi modülü veya bölümü etkilediğini gösterir. Burada login kullanılmış, yani yapılan değişiklik, login (giriş) süreciyle ilgilidir.
|
||||||
|
- **add JWT authentication:**
|
||||||
|
Bu, commit'in yaptığı spesifik değişikliği kısa ve öz bir şekilde açıklar. Burada, JWT (JSON Web Token) ile kimlik doğrulamanın login sürecine eklendiği belirtiliyor.
|
||||||
|
|
||||||
## Sonuç
|
#### 2. Gövde **(Body)**
|
||||||
|
|
||||||
Conventional Commits, proje geçmişini düzenler ve ekip verimliliğini artırır. Özellikle takım çalışmasında ve sürüm yönetiminde standart bir commit dili oluşturmak için güçlü bir yöntemdir.
|
- **İlk Cümle:**
|
||||||
|
“Added JWT authentication to the login process to enhance security.”
|
||||||
|
Bu cümle, yapılan değişikliğin amacını ve sonucunu açıklar. Burada, JWT kimlik doğrulamasının login sürecine eklendiği ve bunun güvenliği artırmak amacıyla yapıldığı belirtiliyor.
|
||||||
|
- **İkinci Cümle:**
|
||||||
|
“This change involves updating the login controller and modifying the user model.”
|
||||||
|
Bu cümle, değişikliğin hangi dosya veya modülleri etkilediğini daha detaylı açıklar. Burada, login controller’ın güncellendiği ve user model’in değiştirildiği belirtiliyor.
|
||||||
|
|
||||||
## Kaynak
|
#### 3. Altbilgi **(Footer)**
|
||||||
|
|
||||||
|
- **BREAKING CHANGE:**
|
||||||
|
Bu ifade, uyumluluğu bozan bir değişiklik olduğunu gösterir. Eğer bir commit, mevcut kodun çalışmasını bozacak bir değişiklik yapıyorsa, bu mutlaka belirtilmelidir. Bu, diğer geliştiricilerin bu değişiklikten haberdar olmasını sağlar.
|
||||||
|
- **Detay:**
|
||||||
|
“The user model now requires a JWT token for all login operations.”
|
||||||
|
Bu açıklama, uyumluluğu bozan değişikliğin ne olduğunu detaylandırır. Burada, kullanıcı modelinin artık tüm giriş işlemleri için bir JWT token gerektirdiği belirtiliyor. Bu, diğer geliştiricilerin bu değişiklikleri uygularken dikkatli olmaları gerektiğini ifade eder.
|
||||||
|
|
||||||
|
## Sonuç **olarak**
|
||||||
|
|
||||||
|
Conventional Commits, yazılım geliştirme sürecimizi daha düzenli, anlaşılır ve verimli hale getirdi. Commit mesajlarımızı belirli bir yapıya oturtarak, proje yönetimimizi daha sürdürülebilir ve izlenebilir bir hale getirdik.
|
||||||
|
|
||||||
|
## **Kaynak**
|
||||||
|
|
||||||
- [Conventional Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/)
|
- [Conventional Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/)
|
||||||
- [3 reasons why you should use conventional commits](https://developer.vonage.com/en/blog/3-reasons-why-you-should-use-conventional-commits)
|
- [3 Reasons Why You Should Use Conventional Commits](https://developer.vonage.com/en/blog/3-reasons-why-you-should-use-conventional-commits)
|
||||||
Reference in New Issue
Block a user