Git Commit Nedir? Nasıl Kullanılır? (Detaylı Anlatım + Örnekler)

Git sistemine entegre bir projede çalışırken dosyaları değiştirir, ekler veya sileriz. Bu değişikliklerin belli bir aşamaya geldiğinde bunları artık kaydetmemiz gerekir. Git dünyasında bu işleme commit denir. Git tarihçesine kaydedilen herhangi bir commit'e istediğimiz zaman geri dönebiliriz.

Commit işleminde Git ile yeni tanışanlar arasında yanlış bilinen bir şey vardır. Bu yanlış; commit'in bir belgedeki ctrl + s (kaydet) veya bir video oyunundaki "kayıt noktası (save point)" olarak düşünülmesidir. Ancak git biraz daha kompleks bir arkaplana sahiptir. Ctrl + S ile dosyada üzerine yazılır ama git commit ile daha sonra o versiyona dönülebilir bir şekilde tarihçeye yazılır.

Git sisteminde her commit oluştuğunda projedeki o anda bütün dosyaların fotoğrafı (snapshot) alınır. Değişmeyen bir dosya varsa onu tekrar kopyalamaz (ama bir bağlantı oluşturur). Bu sayede daha hızlı çalışır.

Commit komutunu çalıştırdığımızda, "şu tarihte şu kişi tarafından projenin tam olarak bu hali dondurularak kaydedildi" demiş oluruz.

Git Commit Nasıl Çalışır?

Bir commit'in nasıl çalıştığını anlamak için Git'teki dosyaların geçtiği şu üç katmanı gözden geçirmekte fayda var.

• Çalışma Dizini (Working Directory): Üzerinde çalıştığımız, kendi bilgisayarımızda bulunan proje dosyalarımızdır. Git aslında çalışma dizinindeki değişikliği zaten görür ama commit etmediğimiz sürece bu değişiklikler kalıcı Git geçmişine yazılmaz (Git'in umrunda değildir).
• Hazırlık Alanı (Staging Area/Index): Bir sonraki commit'e dahil edilecek olan değiştirilmiş dosyaların barındırıldığı geçici bir alandır. Git Add komutu ile dosyalarımızı bu alana taşırız. Commit'ten bir önceki aşamadır.
• Git Dizini (Local Repository): Değişikliklerin kalıcı olarak veritabanına kaydedildiği yerdir. Git commit komutunu çalıştırdığımızda Staging Area'ya aldığımız dosyalar artık kalıcı olarak buraya taşınır.

Bir commit yaptığımızda 40 karakterlik benzersiz (SHA-1 ile hashlenir) bir ID'si oluşur. Bu kimlikle bu commit'e her zaman ulaşılabilir. Değişikliği kimin, ne zaman ve hangi amaçla yaptığı (commit yaparken girilen açıklama) öğrenilebilir.

Git'te Ebeveyn (Parent) Referansı Nedir?

İlk commit hariç her commit kendinden önceki commit'i işaret eder. Bu sayede kopuk bir veri yığını değil de birbirine bağlı bir zincir şeklinde tarihçe (history) oluşur.

İyi Bir Commit Mesajı Nasıl Olmalıdır?

Commit yapmaktaki amacımız yaptığımız özellikleri kayıt altına almak olduğundan girdiğimiz açıklamalar önemlidir. Geçmişe dönüp baktığımızda veya takım arkadaşımız baktığında anlaşılabilir olmalıdır.

Peki iyi bir commit nasıl olur? Atomik ve açıklayıcı olmalıdır. Yani yapacağımız commit mantıksal olarak tek bir değişikliği içermelidir. Örneğin hem bir butonun rengini değiştirip hem de bir hatayı giderip bu ikisini tek bir çatı altında commit yapmak önerilmez. Bunun somut bir sebebi var. Butonun rengini eski haline getirmek istediğimizde bug da geri gelir! Bu konuyu enine boyuna incelediğimiz iyi bir commit nasıl olmalıdır? yazımıza göz atabilirsiniz.

Git Commit Komutunun Parametreleri Nelerdir?

• En temel parametre: git commit -m "mesaj" Olmazsa olmaz bu parametre commit için açıklama ekler. Komut satırında herhangi bir editor uygulama açmadan tırnak içinde mesaj yazmamızı sağlar. git commit -m "buton rengi değiştirildi". Eğer çok satırlı mesaj yazmak istiyorsak -m parametresini iki kez kullanabiliriz. İlki başlık ikincisi gövde anlamına gelir.
• Hazırlık Alanını (Staging Area) atlama: git commit -a -m "mesaj" veya -a yerine --all Yukarıda staging area'dan bahsetmiştik. Eğer sadece zaten takip ettiğim (tracked) dosyalarda değişiklik yaptıysak ve bunları tek tek eklemekle uğraşmak istemiyorsak bu süreci hızlandırabiliriz.
  add + commit komutları birlikte kullanılmış gibi davranır.
  
  Kullanımı: git commit -a -m "mesaj" veya kısa olarak git commit -am "mesaj" şeklinde kullanabiliriz.
  Not: bu parametre projeye yeni eklenen dosyaları kapsamaz. Daha önce Git'in bildiği değiştirilmiş/silinmiş dosyaları otomatik olarak staging area'ya alır ve commit'i gerçekleştirir.
• Hayat kurtaran "geri al tuşu": --amend Son commit'i push etmeden önce "mesajı yanlış yazdım" ve "bir dosyayı unuttum" dediğimizde kullanırız. Diyelim ki commit yaptık ve tatmin edici bir yazı yazdık. Daha sonra kodumuzun bozuk olduğunu fark ettik. Yeni bir commit yerine yeniden yazabiliriz.
  Dikkat: Amend yazdığımızda commit'in hash'i değişeceği için push yaptığımız bir commit'i amend edip tekrar push yaparsak takım arkadaşımızın geçmişiyle çakışır (yukarıda bahsettiğimiz parent-child ilişkisi bozulur).
• • Eğer sadece mesajı değiştirmek istiyorsak git commit --amend -m "doğru commit mesajı" şeklinde kullanmalıyız.
  • Unutulan dosya için iki adımlı yol vardır:
  • 1. Unutulan dosyayı ekle git add unutulan_dosya.html
    2. Son commit'in içine kaynaştır git commit --amend --no-edit --no-edit parametresi mesaj değiştirmeden sadece dosyayı değiştirmemizi sağlar.

Git Commit Örneği

Yaptığınız commitle birlikte hiç istemediğiniz dosyayı da git zincirine dahil ettiniz diyelim. Ne yaparsınız?

Yaptığınız anasayfa.html dosyasını commitlemek için git add . çalıştırdık. Ama ilgisi olmayan şifrelerim.txt dosyası da commitle (git commit -m "mükemmel tasarım") beraber birlikte versiyonlandığını hayal edin.

Çözüm: kodu silmeden özel dosyayı çıkarmanın bir yolu var.

1. İlk olarak istenmeyen bir dosyayı Git'in radarından çıkarmamız gerekiyor: git rm --cached sifrelerim.txt (bu kod dosyayı silmez sadece Git'in kayıt listesinden çıkarır)
2. İkinci adımda commit'i yamama: Şimdi elimizde sadece anasayfa.html'in kaldığı doğru ve temiz bir staging area var. Kalan tek komut: git commit --amend --no-edit (buradaki --no-edit başlığın değişmeyeceğini bildirir).

Git Commit Tek Başına Yeterli midir?

Git commit komutu yalnızca staging area içindeki değişiklikleri kaydeder. Bu, Git ile yeni tanışanların sık yaşadığı bir yanılgıdır. Çalışma dizininde yapılan ama git add ile hazırlık alanına alınmayan dosyalar commit'e dahil edilmez.

Git Commit İleri Seviye Parametreler

• --allow-empty: Normalde Git'in varsayılan davranışı hiçbir değişiklik yoksa commit atmamıza izin vermez. Ancak bazen bir otomasyonu tetiklememiz için (örneğin CI/CD pipeline) kod değiştirmeden commit etmemiz gerekebilir. Bu gibi durumlarda kullanılmak üzere tasarlanmıştır. git commit --allow-empty -m "pipeline tetikleniyor"
• -S (büyük S harfi): Yazılan kodun gerçekten bana mı ait olduğunu şifreleme anahtarı ile doğrulamak için kullanılır. Güvenliğin kritik olduğu projelerde kullanılır.
• -p (Patch) Dosyanın tamamını değil, sadece içindeki belli kod bloklarını commit'lemek için kullanılır.
• --dry-run git commit --dry-run -m "test" gerçek commit oluşturmaz ama atılırsa ne olacağını gösterir. Neyin commit'e gireceğini test etmekte kullanışlıdır.
• --author ve --date Normalde git bu bilgileri sistemden otomatik olarak alır. Eğer başkası adına commit yapmamız gerekiyorsa veya geçmişteki bir commit'in tarihini manipüle etmemiz gerekiyorsa kullanılır.

Git Commit Parametreleri (Özet)

Git Add ve Git Commit Arasındaki Fark

Git'te değişiklikler doğrudan commit edilmez. Önce git add ile staging area'ya aktarılır sonrasında git commit ile kalıcı hale getirilir. Bu Git ile yeni tanışanların sık karıştırdığı bir konudur.

• git add: Değişiklikleri bir sonraki commit için hazırlar.
• git commit: Hazırlanan değişiklikleri Git geçmişine kaydeder.

Kısaca: add seçer, commit kaydeder.

Git'te çok satırlı commit mesajı nasıl yazılır?

Neden önemli: GitHub, GitLab gibi platformlar başlık + gövdeyi ayrı ayrı render eder. git log --oneline sadece başlığı gösterir, gövde git show <hash> ile görünür. Gövdesi olan git commit mesajı, kişisel projelerde pek gerekmese de ekip çalışmasında veya açık kaynak katkısında "neden yaptım" sorusunu cevaplayan gövde, commit geçmişini gerçekten okunabilir kılar. Bunun için iki yöntem mevcuttur:

• -m iki kez kullanmak: Daha pratiktir. git commit -m "başlık" -m "gövde açıklaması" şeklinde yazılır. Hızlı ama kısıtlı, kısa bir ek not için yeterli.
• Editörle yazmak: -m vermeden sadece git commit yazınca Git varsayılan editörü açar (genellikle Vim veya Nano). İlk satır başlık, bir boş satır, sonrası gövde. Uzun açıklama gerektiğinde bu yol daha rahat.
  terminal

  Buton rengi kırmızıdan maviye değiştirildi   ← başlık (50 karakter önerilir)
                                               ← boş satır (zorunlu)
  Erişilebilirlik raporuna göre kırmızı renk   ← gövde (72 karakter/satır önerilir)
  kontrast testini geçemiyordu. Mavi (#1a73e8)
  WCAG AA standardını karşılıyor.