Commit yapmak — nedir, biçimlendirme kuralları ve Git ile çalışma

Git'te Commit Nedir

Git'te commit, proje dosyalarının belirli bir andaki durumunu depolayan bir nesnedir. Her commit, izlenen tüm dosyaların bir anlık görüntüsünü, üst commit'e bir referansı ve meta verileri içerir. Diğer sürüm kontrol sistemlerinin aksine Git, içerik adreslenebilir depolama kullanır — her nesne, içeriğinin SHA-1 hash'i ile tanımlanır.

Bir geliştirici değişiklikleri commit ettiğinde, Git şunları depolayan bir commit nesnesi oluşturur: ağaç nesnesi (dosya yapısı), üst commit hash'i, yazar, committer, tarih ve mesaj. Bu nesne değişmezdir — oluşturulduktan sonra, hash'i değiştirilmeden bir commit değiştirilemez. Bu değişmezlik, proje geçmişinin bütünlüğünü garanti eder.

# Değişiklikleri hazırla ve commit yap
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Commit ayrıntılarını görüntüle
git log --oneline -3
git show HEAD

# Tüm değişiklikleri hazırla ve tek adımda commit yap
git commit -a -m "Update dependencies to latest versions"

Commit'ler, her yeni commit'in bir öncekine referans verdiği yönlü döngüsüz bir grafik (DAG) oluşturur. Bu, geçmişte gezinmeye, değişiklikleri geri almaya ve kod tabanının evrimini analiz etmeye olanak tanır. Git DAG yapısını anlamak, commit'lerle gelişmiş çalışmanın temelidir.

Değişiklikler Nasıl Doğru Şekilde Commit Edilir

Git'te commit süreci iki aşamadan oluşur: hazırlık alanına (indeks) değişiklikleri ekleme ve commit oluşturma. Hazırlık alanı, geliştiricinin çalışma dizininde birçok dosya değiştirilmiş olsa bile, commit'e hangi belirli değişikliklerin dahil edileceğini seçmesine olanak tanır.

Atomiklik kuralı, iyi bir commit'in temel ilkesidir. Her commit bir mantıksal değişiklik içermelidir. Bir geliştirici bir hatayı düzeltiyor ve kodu yeniden düzenliyorsa — bunlar iki ayrı commit olmalıdır. Atomik commit'ler, kod incelemesini, değişiklik geri almayı ve geçmiş analizini basitleştirir.

Commit yapmadan önce, kodda hata ayıklama çıktısı, yorumlanmış bloklar veya yanlışlıkla yapılan değişiklikler kalıp kalmadığını kontrol etmekte fayda var. Bunun için git diff --cached komutu kullanılır ve commit'e tam olarak neyin dahil edileceğini gösterir. git status ile ek kontrol, hazırlık alanındaki dosyaların listesini görüntüler.

• Değişiklikleri kontrol et — git diff --cached commit'e neyin gireceğini gösterir
• Kaliteyi kontrol et — kod, commit'ten önce linter ve testleri geçmelidir
• Bir mesaj yaz — değişikliğin amacının net bir açıklaması
• Hazırlanan dosyaları kontrol et — git status dosya listesini onaylar

Commit Mesajı Yazma Kuralları

Commit mesajı, gelecekteki geliştiriciler için değişikliğin belgelenmesidir. İyi bir mesaj şu soruları yanıtlar: ne değiştirildi ve neden. Conventional Commits kuralı (Angular ekibi, 2016) birçok proje için standart haline gelmiştir ve biçimi tanımlar: tür(kapsam): açıklama.

İyi bir commit mesajı, bir başlık (50 karaktere kadar) ve bir gövdeden (isteğe bağlı, satır başına 72 karaktere kadar) oluşur. Başlık emir kipinde yazılır: “Add” değil “Added” veya “Adds”. Capitalization ve başlık sonunda nokta kullanılmaz — bu uluslararası bir Git kuralıdır.

Kötü bir mesaj: “fix things” veya “update” — bilgi taşımaz. Bir ay sonra, bir geliştirici tam olarak neyin ve neden değiştirildiğini anlayamaz. İyi bir mesaj: “fix(payment): handle timeout in stripe callback” — neyin ve nerede düzeltildiği hemen anlaşılır.

Commit Yaparken Sık Yapılan Hatalar

Geliştiriciler, özellikle yeni başlayanlar, commit yaparken sık sık tipik hatalar yaparlar. En yaygın olanı, düzinelerce değişikliği karıştıran çok büyük bir commit'tir. Böyle bir commit kısmen geri alınamaz ve kod incelemesi bir işkence haline gelir.

İkinci en sık yapılan hata, kötü bir commit mesajıdır. “fix”, “update”, “changes” veya “wip” gibi mesajlar, gelecekteki geliştiricilere bağlam sağlamaz. Altı ay sonra, kimse tam olarak neyin düzeltildiğini hatırlamayacaktır. Kural basittir: bir yıl sonra geçmişe bakıp belirli bir değişikliği bulmaya çalıştığınızı hayal edin.

Üçüncü hata, derlenmemiş veya çalışmayan kodu commit etmektir. Bir commit'ten sonra, kod en azından derlenmelidir. Derlemeyi bozmamak, ortak bir daldaki herhangi bir commit için temel bir gerekliliktir. Bunun için commit'ten önce derleme ve testler çalıştırılır.

Dördüncü hata, gizli verileri commit etmektir. API anahtarları, şifreler ve token'lar Git geçmişine girmemelidir. Bir sır zaten commit edilmişse, onu yeni bir commit'te kaldırmak yeterli değildir, git filter-branch veya BFG Repo-Cleaner ile tüm geçmişten silinmesi gerekir.

Commit'lerle Çalışmak için Gelişmiş Teknikler

Git, commit geçmişini yönetmek için araçlar sağlar. En kullanışlı olanlardan biri git commit --amend'tir, son commit'i yeni değişikliklerle tamamlamaya veya mesajı düzeltmeye olanak tanır. Geliştiricinin bir dosyayı eklemeyi unutması veya mesajda yazım hatası yapması durumunda kullanışlıdır.

# Son commit mesajını düzelt
git commit --amend -m "fix(auth): correct token validation logic"

# Son commit'e unutulan dosyayı ekle
git add missed-file.txt
git commit --amend --no-edit

# Son 3 commit için interaktif rebase
git rebase -i HEAD~3

İnteraktif rebase, geçmişi yeniden yazmak için güçlü bir araçtır. Commit'leri birleştirmeye (squash), mesajları değiştirmeye (reword), yeniden sıralamaya (reorder) ve commit'leri silmeye (drop) olanak tanır. Ancak rebase geçmişi değiştirir, bu nedenle yalnızca henüz uzak depoya gönderilmemiş yerel commit'lerde kullanılır.

Commit'leri geri almak için iki yaklaşım vardır. git revert, öncekinin değişikliklerini geri alan yeni bir commit oluşturur — geçmişi koruyan güvenli bir yöntem. git reset, commit'leri geçmişten kaldırır — commit'ler zaten gönderilmişse tehlikelidir. Takım geliştirmede, yayınlanmış commit'leri geri almak için yalnızca git revert kullanılır.