mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2024-11-15 02:45:15 +01:00
fix(tr): delete translate typos and improve grammar
This commit is contained in:
Abdullah Bagyapan
GitHub
parent
e475c0758d
commit
174f7eccbc
@ -1,27 +1,26 @@
|
||||
---
|
||||
draft: false
|
||||
aliases:
|
||||
- "/tr/"
|
||||
aliases: ["/tr/"]
|
||||
---
|
||||
|
||||
# Conventional Commits 1.0.0
|
||||
|
||||
## Özet
|
||||
|
||||
Conventional Commits şartnamesi, commit mesajları hakkında kolayca takip edilebilecek bir sözleşmedir.
|
||||
Otomatik araçlar yazılarak anlaşılabilecek açık bir commit geçmişi oluşturmak için kolay bir dizi kural sağlar.
|
||||
Bu sözleşme [SemVer](http://semver.org) ile uyumludur ve commit mesajlarında yeni özellik ekleme (features), hata düzeltme (fixes) ve yıkıcı değişiklik (breaking change) tanımlamalarını yapar.
|
||||
Conventional Commits yönergesi, commit mesajları hakkında kolayca takip edilebilecek bir sözleşmedir.
|
||||
Anlaşılabilir bir commit geçmişi için kolay bir dizi kurallar oluşturarak, üzerine daha kolay otomatik araçlar yazılmasını sağlar.
|
||||
Bu sözleşme, commit mesajlarında yeni özellik ekleme (features), hata düzeltme (fixes) ve köklü değişiklik (breaking changes) tanımlamalarıyla [SemVer](http://semver.org) ile uyumludur.
|
||||
|
||||
Commit mesajı aşağıdaki gibi yapılandırılmalıdır:
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
<tip>[kapsam, zorunlu değil]: <açıklama>
|
||||
<tip>[isteğe bağlı kapsam alanı]: <açıklama>
|
||||
|
||||
[zorunlu olmayan mesaj metni]
|
||||
[isteğe bağlı mesaj metni]
|
||||
|
||||
[zorunlu olmayan alt metin(ler)]
|
||||
[isteğe bağlı alt metin(ler)]
|
||||
```
|
||||
|
||||
---
|
||||
@ -30,47 +29,46 @@ Commit mesajı aşağıdaki gibi yapılandırılmalıdır:
|
||||
<br>
|
||||
Commit mesajı kütüphanenizin kullanıcılarına niyet belirtmek için aşağıdaki yapısal unsurları içerir:
|
||||
|
||||
1. **fix:** `fix` *tipi* bir commit kodunuzdaki bir hatayı düzeltir (Semantik versiyonlamadaki [`PATCH`](http://semver.org/#summary) ile paraleldir).
|
||||
2. **feat:** `feat` *tipi* commit kodunuza yeni bir özellik ekler (Semantik versiyonlamadaki [`MINOR`](http://semver.org/#summary) ile paraleldir).
|
||||
3. **BREAKING CHANGE:** `BREAKING CHANGE:` ile başlayan bir alt metin ya da tip/kapsam sonuna eklenmiş bir `!` içeren commit yıkıcı bir değişiklik getiriyordur (Semantik versiyonlamadaki [`MAJOR`](http://semver.org/#summary) ile paraleldir). Bir BREAKING CHANGE harhangi bir *tip* commit içinde olabilir.
|
||||
4. `fix:` ve `feat:` dışında *tipler* de kullanılabilir. Örneğin [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ve birkaç başka tipi de tavsiye eder (bu [the Angular sözleşmesinden](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines) esinlenmiştir).
|
||||
5. `BREAKING CHANGE: <description>` dışında *alt metinler* de kullanılabilir ve [git trailer format](https://git-scm.com/docs/git-interpret-trailers) takip edilebilir.
|
||||
1. **fix:** `fix` *tipi* bir commit, kodunuzdaki bir hatayı düzeltir (Semantik versiyonlamadaki [`PATCH`](http://semver.org/#summary) ile paraleldir).
|
||||
2. **feat:** `feat` *tipi* bir commit, kodunuza yeni bir özellik ekler (Semantik versiyonlamadaki [`MINOR`](http://semver.org/#summary) ile paraleldir).
|
||||
3. **BREAKING CHANGE:** `BREAKING CHANGE:` ile başlayan bir alt metin ya da tip/kapsam sonuna eklenmiş bir `!` içeren commit köklü bir değişiklik getiriyordur (Semantik versiyonlamadaki [`MAJOR`](http://semver.org/#summary) ile paraleldir). Bir BREAKING CHANGE herhangi bir *tip* commit içinde olabilir.
|
||||
4. `fix:` ve `feat:` dışındaki *tipler* de kullanılabilir. Örneğin [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) ([Angular yönergesine göre](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ve birkaç başka tipi de tavsiye eder.
|
||||
5. `BREAKING CHANGE: <description>` dışında *alt metinler* de kullanılabilir ve [git trailer format](https://git-scm.com/docs/git-interpret-trailers)'a benzer yönergeler takip edilebilir.
|
||||
|
||||
Ek tipler Conventional Commits sözleşmesi tarafından zorunlu kılınmaz ve semantik versiyon oluşturmada örtülü bir etkisi yoktur (tabiki BREAKING CHANGE içermedikçe).
|
||||
<br><br>
|
||||
Ek bağlamsal bilgi sağlamak için bir commit türüne bir kapsam eklenebilir ve parantez içinde yer alır, Örneğin, `feat(parser): add ability to parse arrays`.
|
||||
Harici ek tipler Conventional Commits yönergesi tarafından zorunlu kılınmaz ve semantik versiyon oluşturmada tam bir etkisi yoktur (tabiki BREAKING CHANGE içermedikçe).
|
||||
<br /><br />
|
||||
Fazladan ilave bağlamsal bilgi sağlamak için bir commit türüne bir kapsam eklenebilir ve parantez içinde yer alır, Örneğin, `feat(parser): add ability to parse arrays`.
|
||||
|
||||
## Örnekler
|
||||
|
||||
### Açıklama ve yıkıcı değişiklik içeren alt metin sahibi bir commit mesajı
|
||||
### Açıklama ve köklü değişiklik içeren alt metinli bir commit mesajı
|
||||
|
||||
```
|
||||
feat: config neslelerinin birbirinden türetilmesi sağlandı
|
||||
feat: config nesnelerinin birbirinden türetilmesi sağlandı
|
||||
|
||||
BREAKING CHANGE: `extends` artık başka bir ayar dosyasından türetildiğini belirtiyor
|
||||
BREAKING CHANGE: `extends` kelimesi artık başka bir ayar dosyasından türetildiğini belirtiyor
|
||||
```
|
||||
|
||||
### Yıkıcı bir değişikliğe dikkat çeken `!` içeren commit mesajı
|
||||
### Köklü değişikliğe `!` ile dikkat çeken commit mesajı
|
||||
|
||||
```
|
||||
refactor!: Node 6 desteği kaldırıldı
|
||||
feat!: müşteriye, ürünü kargolandığında mail atma özelliği eklendi
|
||||
```
|
||||
|
||||
### Kapsamı belirtilen ve `!` ile yıkıcı değişikliğe dikkat çeken commit mesajı
|
||||
|
||||
### Kapsam içeren ve köklü değişikliğe `!` ile dikkat çeken commit mesajı
|
||||
```
|
||||
refactor(runtime)!: Node 6 desteği kaldırıldı
|
||||
feat(api)!: müşteriye, ürünü kargolandığında mail atma özelliği eklendi
|
||||
```
|
||||
|
||||
### `!` ve BREAKING CHANGE alt metni içeren commit mesajı
|
||||
### `!` ve köklü değişiklik alt metni içeren commit mesajı
|
||||
|
||||
```
|
||||
refactor!: Node 6 desteği kaldırıldı
|
||||
chore!: Node 6 desteği kaldırıldı
|
||||
|
||||
BREAKING CHANGE: Sadece Node 6 içinde olan Javascript özellikleri kullanan yerler yeniden yazılmalı.
|
||||
```
|
||||
|
||||
### Mesaj metni olamayan commit
|
||||
### Mesaj metni olamayan commit mesajı
|
||||
|
||||
```
|
||||
docs: CHANGELOG'daki yazım hataları düzeltildi
|
||||
@ -82,7 +80,7 @@ docs: CHANGELOG'daki yazım hataları düzeltildi
|
||||
feat(lang): Türkçe çeviri eklendi
|
||||
```
|
||||
|
||||
### Çok paragraflı mesaj metni ve birden çok alt metin içeren commit
|
||||
### Çok paragraflı mesaj metni ve birden çok alt metin içeren commit mesajı
|
||||
|
||||
```
|
||||
fix: bazı küçük yazım hataları düzeltildi
|
||||
@ -95,31 +93,31 @@ Reviewed-by: Z
|
||||
Refs #133
|
||||
```
|
||||
|
||||
## Şartname
|
||||
## Yönerge
|
||||
|
||||
Bu belgedeki “-MALI”, “-MAMALI”, “ZORUNLU”, “YAPALIM”, “YAPMAYALIM”, “-SAM IYI OLUR”, “-MASAM IYI OLUR”, “TAVSIYE EDILIR”, “-ABİLİRİM” ve “SEÇMELİ” kalıpları [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt)'da açıklandığı gibi yorumlanmalıdır.
|
||||
|
||||
1. Her commit mesajı bir `feat`, `fix`, vs. gibi bir tip ile başlaMALI, SEÇMELİ bir kapsam, SEÇMELİ bir `!` işareti ve ZORUNLU bir iki nokta üst üste işareti ve bir adet boşluk ile devam eder.
|
||||
2. `feat` tipi eğer commit uygulamaya ya da kütüphaneye yeni bir özellik ekliyorsa kullanılMALI.
|
||||
3. `fix` tipi eğer commit uygulamadaki bir hatayı düzeltiyorsa kullanılMALI.
|
||||
4. Tip bilgisinden sonra bir kapsam belirtilEBİLİR. Kapsam bilgisi parantez içerisinde kodun hangi bölümün değiştiğine açıklayan bir isimden oluşur. Örneğin `fix(parser):`.
|
||||
5. Açıklama tip/kapsam ön bilgilerinden sonraki iki nokta ve boşluktan hemen sonra yazılMALIdır. Yapılan değişikliği anlatan kısa bir özettir. Örneğin *fix: array parsing issue when multiple spaces were contained in string*.
|
||||
6. Kısa açıklamadan sonra, kod değişiklikleri hakkında ek bağlamsal bilgiler sağlayan daha uzun bir commit mesajı metni yazılABİLİR. Mesaj metni açıklamadan sonra boş bir satıra başlaMALIDIR.
|
||||
7. Bir commit mesaj metni serbest şekildedir ve boş bir satırla ayrılan herhangi bir sayıda paragraftan oluşABİLİR.
|
||||
8. Bir ya da birden fazla alt metin mesaj metninden bir boş satır sonra koyulABİLİR. Her alt metin bir anahtar kelime ile başlaMALI, anahtar kelime ya `:<boşluk>` ile ya da `<boşluk>#` ayraçları ile bir metine bağlanmalı (bu [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)'dan ilham almıştır).
|
||||
9. Alt metin anahtar kelimesi boşluk karakteri yerine `-` kullanmalı. Örneğin `Acked-by` (bu alt metnin çok paragraflı mesaj metinlerinden ayırılmasına yardımcı olur). Buna sadece istisna olarak sadece `BREAKING CHANGE` kalıbını anahtar kelime olarak kullanımına izin verilmiştir.
|
||||
10. Alt metin birden fazla boşluk ve satır içerEBİLİR, ve bir sonraki geçerli anahtar kelimeye ulaştığında bitmiş demektir.
|
||||
11. Yıkıcı değişiklikler ya tip/kapsam içinde ya da alt metin olarak belirtilMELİDİR.
|
||||
12. Eğer alt metin içinde belirtiliyorsa, yıkıcı değişiklik büyük harflerle BREAKING CHANGE ile başlaMALI, iki nokta işareti, boşluk ve açıklama ile devam etMELİDİR. Örneğin *BREAKING CHANGE: environment variables now take precedence over config files* gibi.
|
||||
13. Eğer tip/kapsam içinde belirtiliyorsa, yıkıcı değişiklikler `:` işaretinden önce `!` ile belirtilmelidir. Eğer `!` kullanılırsa altmetinde `BREAKING CHANGE:` kullanılMAYABİLİR ve commit açıklaması yıkıcı değişikliği tanımlamak için kullanılABİLİR.
|
||||
14. `feat` ve `fix` dışındaki tipler de kullanılABİLİR. Örneğin *docs: updated ref docs.*.
|
||||
15. Uygulamaya çalışanlar Conventional Commits'i oluştura kalıpları büyük/küçük harf duyarlı düşünMEMELİ. Buna tek istisna BREAKING CHANGE kalıbıdır çünkü her zaman büyük harfle yazılMALIdır.
|
||||
1. Her commit mesajı bir `feat`, `fix`, vs. gibi bir tip ile başlaMALI, SEÇMELİ bir kapsam, SEÇMELİ bir `!` işareti ve ZORUNLU bir iki nokta üst üste işareti ve bir adet boşluk ile devam eder.
|
||||
2. `feat` tipi commit, uygulamaya ya da kütüphaneye yeni bir özellik ekliyorsa kullanılMALI.
|
||||
3. `fix` tipi commit, uygulamadaki bir hatayı düzeltiyorsa kullanılMALI.
|
||||
4. Tip bilgisinden sonra bir kapsam belirtilEBİLİR. Kapsam bilgisi parantez içerisinde kodun hangi bölümünün değiştiğini açıklayan bir isimden oluşMALI. Örneğin `fix(parser):`.
|
||||
5. Açıklama ön tip/kapsam bilgilerinden sonraki iki nokta ve boşluktan hemen sonra yazılMALIdır. Açıklama kısmı yapılan değişikliği anlatan kısa bir özettir. Örneğin *fix: array parsing issue when multiple spaces were contained in string*.
|
||||
6. Kısa açıklamadan sonra, kod değişiklikleri hakkında ek bağlamsal bilgiler sağlayan daha uzun bir commit mesajı metni yazılABİLİR. Mesaj metni açıklamadan sonra boş bir satırdan sonra başlaMALIDIR.
|
||||
7. Bir commitin mesaj metni serbest şekildedir ve boş bir satırla ayrılan herhangi bir sayıda paragraftan oluşABİLİR.
|
||||
8. Bir ya da birden fazla alt metin mesaj metninden bir boş satır sonra koyulABİLİR. Her alt metin bir anahtar kelime ile başlaMALI, anahtar kelime ya `:<boşluk>` ile ya da `<boşluk>#` ayraçları ile bir metine bağlanmalı (bu özellik [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)'dan ilham alınmıştır).
|
||||
9. Alt metin anahtar kelimesi boşluk karakteri yerine `-` kullanmalı. Örneğin `Acked-by` (bu alt metnin çok paragraflı mesaj metinlerinden ayırılmasına yardımcı olur). Buna istisna olarak sadece `BREAKING CHANGE` kalıbının anahtar kelime olarak kullanımına izin verilmiştir.
|
||||
10. Alt metin birden fazla boşluk ve satır içerEBİLİR, ve bir sonraki geçerli anahtar kelimeye ulaştığında bitmiş olMALI.
|
||||
11. Köklü değişiklikler ya tip/kapsam içinde ya da alt metin olarak belirtilMELİDİR.
|
||||
12. Eğer alt metin içinde belirtiliyorsa, köklü değişiklik büyük harflerle BREAKING CHANGE ile başlaMALI, iki nokta işareti, boşluk ve açıklama ile devam etMELİDİR. Örneğin *BREAKING CHANGE: environment variables now take precedence over config files* gibi.
|
||||
13. Eğer tip/kapsam içinde belirtiliyorsa, köklü değişiklikler `:` işaretinden önce `!` ile belirtilmelidir. Eğer `!` kullanılırsa alt metinde `BREAKING CHANGE:` kullanılMAYABİLİR ve commit açıklaması köklü değişikliği tanımlamak için kullanılABİLİR.
|
||||
14. `feat` ve `fix` dışındaki tipler mesaj metninde tekrar kullanılABİLİR. Örneğin *docs: updated ref docs.*.
|
||||
15. Conventional Commits ile harmanlanmış kalıplar, geliştiriciler tarafından büyük/küçük harf duyarlı olarak düşünülMEMELİ. Buna tek istisna BREAKING CHANGE kalıbıdır çünkü her zaman büyük harfle yazılMALIdır.
|
||||
16. Alt metinde anahtar olarak kullanılırken BREAKING CHANGE BREAKING-CHANGE şeklinde yazılMALI.
|
||||
|
||||
## Neden Conventional Commits'e Uymalıyız
|
||||
|
||||
- CHANGELOG'ları otomatik olarak oluşturma.
|
||||
- Bir semantik version tümcesini otomatik olarak belirleme (commit işlemlerinin tiplerine göre).
|
||||
- Bir semantik versiyon geçişini otomatik olarak belirleme (commit işlemlerinin tiplerine göre).
|
||||
- Değişikliklerin doğasını ekip arkadaşlarına, kamuya ve diğer paydaşlara iletmek.
|
||||
- Derleme ve yayınlama işlemlerini tetikleme.
|
||||
- İnsanların daha yapılandırılmış bir commit geçmişini kendi kendilerine keşfetmelerine imkan vererek projelerinize katkıda bulunmalarını kolaylaştırmak.
|
||||
@ -138,47 +136,47 @@ Herhangi biri kullanılabilir, ancak tutarlı olmak en iyisidir.
|
||||
|
||||
Geri dönün ve mümkün olduğunca çok commit yapın. Conventional Commits'in avantajlarından biri, bizi daha organize commit ve PR yapmaya teşvik etmesidir.
|
||||
|
||||
### Bu, hızlı gelişimi ve hızlı döngüyü yapma cesaretini kırmıyor mu?
|
||||
### Bu, hızlı geliştirme ve hızlı ilerleme cesaretini kırmıyor mu?
|
||||
|
||||
Dağınıklık içinde hızlı bir şekilde hareket etmeyi önler. Uzun vadede çeşitli katkıda bulunanlar ile birden fazla projede daha hızlı bir şekilde ilerlemenize yardımcı olur.
|
||||
Bu, dağınıklık içinde hızlı bir şekilde hareket etmeyi önler. Uzun vadede, çeşitli katkıda bulunanlar ile birden fazla projede daha hızlı bir şekilde ilerlemenize yardımcı olur.
|
||||
|
||||
### Conventional Commits, geliştiricileri sağlanan tipleri düşünecekleri için yaptıkları taahhütlerin tipini sınırlamaya yönlendirebilir mi?
|
||||
### Conventional Commits, sağlanan tipleri düşünecekleri için geliştiricilerin yaptıkları commit'lerin tipini sınırlamaya yönlendirebilir mi?
|
||||
|
||||
Conventional Commits, hata düzeltmeleri gibi belirli commit tiplerinden daha fazlasını yapmamızı teşvik eder. Bunun dışında, Conventional Commits'in esnekliği, ekibinizin kendi tiplerini bulmasına ve zamanla bu tipleri değiştirmesine olanak tanır.
|
||||
Conventional Commits, hata düzeltmeleri(fixes) gibi kesin olan commit tiplerinden daha fazla yapmamızı teşvik eder. Bunun dışında, Conventional Commits'in esnekliği, ekibinizin kendi tiplerini bulmasına ve zamanla bu tipleri değiştirmesine olanak tanır.
|
||||
|
||||
### Bunun SemVer ile ilişkisi nedir?
|
||||
|
||||
`fix` tipi commit `PATCH` sürüm olarak yayınlanabilir. `feat` tipinde commit `MINOR` sürüm olarak yayınlanabilir. `BREAKING CHANGE` içeren commit, tipi ne olursa olsun `MAJOR` olarak yayınlanabilir.
|
||||
`fix` tipi commit `PATCH` sürüm olarak tercüme edilebilir. `feat` tipinde commit `MINOR` sürüm olarak tercüme edilebilir. `BREAKING CHANGE` içeren commit, tipi ne olursa olsun `MAJOR` olarak tercüme edilebilir.
|
||||
|
||||
### Conventional Commits sözleşmesine yaptığım eklentiyi nasıl sürümlendirmeliyim, Örneğin `@jameswomack/conventional-commit-spec` şeklinde mi?
|
||||
### Conventional Commits yönergesinde yaptığım eklentiyi nasıl sürümlendirmeliyim, Örneğin `@jameswomack/conventional-commit-spec` şeklinde mi?
|
||||
|
||||
Bu sözleşmeye ait kendi uzantılarınızı yayınlamak için SemVer kullanmanızı öneririz (ve bu uzantıları oluşturmanızı teşvik ediyoruz!).
|
||||
Bu yönergeye ait kendi uzantılarınızı yayınlamak için SemVer kullanmanızı öneririz (ayrıca bu uzantıları oluşturmanızı destekliyoruz!).
|
||||
|
||||
### Yanlışlıkla yanlış commit tipi kullanırsam ne yapmalıyım?
|
||||
### Yanlışlıkla yanlış bir commit tipi kullanırsam ne yapmalıyım?
|
||||
|
||||
#### Sözleşemede olan ancak doğru olmayan bir tip kullandığınızda, örneğin `feat` yerine `fix`
|
||||
#### Yönergede olan ancak doğru olmayan bir tip kullandığınızda, örneğin `feat` yerine `fix`
|
||||
|
||||
Hatayı birleştirmeden veya yayınlamadan önce, commit geçmişini düzenlemek için `git rebase -i` kullanmanızı öneririz. Yayınlandıktan sonra temizleme, kullandığınız araç ve işlemlere göre farklı olacaktır.
|
||||
Hatayı birleştirmeden veya yayınlamadan önce, commit geçmişini düzenlemek için `git rebase -i` kullanmanızı öneririz. Yayınlandıktan sonra temizleme ise, kullandığınız araç ve işlemlere göre farklı olacaktır.
|
||||
|
||||
#### Şözleşmede *olmayan* bir tür kullandığınızda, örneğin `feat` yerine `feet`
|
||||
#### Yönergede *olmayan* bir tür kullandığınızda, örneğin `feat` yerine `feet`
|
||||
|
||||
En kötü durumda, Conventional Commits şartnamesine uymayan bir commit tipi dünyanın sonu değildir. Bu sadece commit'in sözleşmeye dayalı araçlar tarafından kaçırılacağı anlamına gelir.
|
||||
En kötü durumda bile, Conventional Commits yönergesine uymayan bir commit tipi dünyanın sonu değildir. Bu sadece commit'in yönergeye dayalı araçlar tarafından, commit'in kaçırılacağı anlamına gelir.
|
||||
|
||||
### Tüm proje katılımcılarının Conventional Commits şartnamesini kullanması gerekiyor mu?
|
||||
### Tüm projeye katkıda bulunanlar Conventional Commits yönergesini kullanması gerekiyor mu?
|
||||
|
||||
Hayır! Git'te squash tabanlı bir iş akışı kullanırsanız, proje yürütücüleri birleştirme sırasında commit mesajlarını temizleyebilir; bu da dışardan katkı yapanlara iş yükü eklemez.
|
||||
Bunun için yaygın bir iş akışı, git sisteminizin otomatik olarak bir PR isteğinden commit mesajlarını ayırmasını ve isteği kabul edecek kişinin için birleştirme için uygun git commit mesajını girmesi için bir form sunmasını sağlamaktır.
|
||||
Bunun için yaygın bir iş akışı olarak, git sisteminizin otomatik olarak bir PR isteğinden commit mesajlarını ayırmasını ve isteği kabul edecek kişinin birleştirme sırasında uygun git commit mesajını girmesi için bir form sunmasını sağlamaktır.
|
||||
|
||||
### Conventional Commits geri dönen commit'leri nasıl ele alır?
|
||||
### Conventional Commits geri döndürülen commit'leri nasıl ele alır?
|
||||
|
||||
Eklenen bir kodu geri almak karmaşık olabilir: birden fazla işi geri mi alıyorsunuz? Bir özelliği geri alıyorsanız, bir sonraki sürüm belki de bir yama mı olmalı?
|
||||
Eklenen bir kodu geri almak karmaşık olabilir: birden fazla commit'i mi geri alıyorsunuz? Bir özelliği geri alıyorsanız, bir sonraki sürüm veya belkide bir yama mı olmalı?
|
||||
|
||||
Conventional Commits, geri döndürme davranışını tanımlamak için açık bir çaba göstermez. Bunun yerine bu işi geliştiricilere bırakıyoruz, geliştiriciler geri dönüşleri ele almak için kendi yollarını geliştirmek üzere *tiplerin* ve *alt metinlerin* esnekliğini kullanabilirler.
|
||||
|
||||
Bir öneri şöyle olabilir, `revert` tipini ve geri döndürülen commit'in SHA bilgisini başvuran bir alt metinde belirtmektir:
|
||||
|
||||
```
|
||||
revert: let us never again speak of the noodle incident
|
||||
revert: bir daha asla noodle olayından bahsetmeyelim
|
||||
|
||||
Refs: 676104e, a215868
|
||||
```
|
||||
|
||||
Loading…
Reference in New Issue
Block a user