Kavramın hikâyesi
Önce iş karşılığını gör, gerektiğinde bağlamı aç.
İlk taramaİşte karşılaşacağın sinyaller
Gerilim ve çözüm · Bölüm 01
Hangi problemi çözer?
Staging area ya da index, çalışma alanındaki hangi değişikliklerin sıradaki commite gireceğini seçmene yardım eder. Varsayılan git commit akışında staged durum ve commit mesajı yeni kaydı oluşturur; staged olmayan değişiklikler çalışma alanında kalır.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Normal akışta yeni commit, önceki HEAD commitinin çocuğu olur ve current branch'in ucunu ilerletir.
Gerçek hayat · Bölüm 02
Gerçek iş senaryosu
SCN-002'de ilgili değişiklikleri stage eder, commit öncesinde seçilen kapsamı kontrol eder ve niyeti anlaşılır bir mesajla kaydedersin.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Commit bulunduğun yerel branch'i ilerletir. Bu kaydı uzak repository'ye göndermek için ayrıca push etmen, GitHub'da incelemeye sunmak için ayrıca Pull Request açman gerekir.
Duyacağın bağlam · Bölüm 03
Ekipte bunu nasıl duyabilirsin?
Temsili ekip konuşması: “Bu refactor ile davranış değişikliğini ayrı commitlerde tutabilir misin? İncelerken niyetleri ayırmak kolaylaşır.”
Beklenti seviyesi · Bölüm 04
Junior hangi seviyede bilmeli?
- Tanı: Working tree, staged ve committed durumlarını; commit mesajı ve commit ID ifadelerini tanır.
- Açıkla: Commitin index'ten bir history noktası oluşturduğunu ve current branch'i ilerlettiğini açıklar.
- Uygula: Stage edilen kapsamı kontrol eder, amaca uygun bir mesajla commit oluşturur ve son commitin doğru branch'te olduğunu doğrular.
- Şimdilik bilmesi gerekmeyen: Commit object'in ham formatı, ileri history rewrite akışları ve organizasyon çapında imzalama politikaları.
İhtiyacın kökeni · Bölüm 05
Neden ortaya çıktı?
Bir projenin yalnızca son hâlini görmek, değişikliğin hangi sırada ve hangi bağlamda yapıldığını anlamaya yetmez. Commit kaydı proje ağacının belirli bir durumunu ve yazar/zaman gibi temel bilgileri taşır; ilk commit dışındaki commitler parent ilişkileriyle önceki history'ye bağlanır. Böylece history, birbirini izleyen tanımlı noktalardan oluşur.
Ekip etkisi · Bölüm 06
Şirketler neden kullanır?
Ekipler commit history üzerinden değişikliklerin kapsamını, sırasını ve mesajlarda açıklanan niyeti inceleyebilir. GitHub'ın rehberi küçük ve anlamlı değişiklik gruplarını önerir; bu, her commitin tek dosya veya belirli sayıda satır içermesi gerektiği anlamına gelmez. Uygun commit kapsamı işin niteliğine ve ekibin çalışma anlaşmasına göre değişir.
Karar alanı · Bölüm 07
Trade-off ve bağlam
Birbiriyle ilgisiz çok sayıda değişikliği tek committe toplamak, kaydın niyetini ve history'yi okumayı zorlaştırabilir. Gereğinden fazla parçalamak da tek bir amacı birçok kayıt arasında dağıtabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Doğru sınır için evrensel bir dosya veya satır sayısı yoktur. Ayrıca --amend, mevcut commit nesnesini yerinde düzenlemez; yeni bir commit oluşturup current branch'in ucunu değiştirir. Paylaşılmış history'yi yeniden yazmadan önce ekibin sürecini kontrol etmelisin.
Yanılgı radarı · Bölüm 08
Yaygın yanlış anlamalar
- Commit oluşturmak değişikliği remote repository'ye göndermez; bunun için push gibi ayrı bir paylaşım işlemi gerekir.
- Working tree'de görünen her değişiklik varsayılan commit kapsamına otomatik girmez.
- Commit yalnızca bir diff veya mesaj değildir; proje durumuna ve parent history'ye bağlanan bir Git object'tir.
- Commit ID commitin kimliğidir, commit nesnesinin tüm içeriği değildir.
- Amend mevcut commit object'ini yerinde değiştirmez; yeni bir commit ve yeni uç oluşturur.
Gerilim ve çözüm1. bölüm