Daha İyi Bir Git İş Akışına Doğru

Git’i daha verimli kullanmak için yöntemleri bir araya getirdim.

0. Repo yapısı
   • Git dağıtık bir sürüm kontrol sistemi olduğu için merkezi, GitHub/GitLab tarzı, hiyerarşik gibi çeşitli şekillerde yapılandırılabilir
1. Dal yapısı
   • GitHub Flow: main etrafında özellik veya hata düzeltme dalları oluşturulup geri bildirim alındıktan sonra birleştirilen yapı
   • Git Flow: sık dağıtımdan ziyade daha geleneksel geliştirme için uygundur
     • Feature branch oluşturulup develop dalına birleştirilir
     • Yeterince olgunlaşan develop dalı için release (stage) dalı açılır; burada yalnızca hata düzeltmeleri yapılır ve sonrasında develop ile mastera birleştirilir
     • Sürüm hazırlığı tamamlandığında master dalına birleştirilir ve sonrasında yalnızca hotfix yapılır
   • GitLab Flow: karmaşık Git Flow ile fazla basit GitHub Flow arasında bir ara model
     • Git Flow’da geçici olarak tutulan release dalı yerine kalıcı bir stage dalı kullanılır
     • Hotfix’ler production ve stagee, hata düzeltmeleri ise stage ve developa yansıtılır
   • Perforce Stream: birden fazla sürümü yönetmek gerektiğinde avantajlıdır
     • releasete hata düzeltilirse bu değişiklik main-developa yayılır
     • developta özellik geliştirildiyse çakışmalar giderilip maine yansıtılır
   • Trunk tabanlı: main (master) dalını daha verimli kullanma yaklaşımıdır ve çoğunlukla büyük teknoloji şirketleri tarafından kullanılır
     • main uzun süre korunur, sürüm dallarında ayrıca hata düzeltmesi yapılmaz
     • Özellikler flag kullanılarak kapalı durumda birleştirilir ve böylece kod tabanı her zaman güncel kalır
2. Commit
   • Konvansiyon: genelde Angular konvansiyonu yaygındır ama ekip içinde anlaşmaya göre emoji vb. de kullanılabilir
   • Birim: mümkün olan en küçük birimlerle commit atılmalı, ama bunun da ekip bazında ne olduğu kararlaştırılmalıdır
     • Değişiklikler hunk bazında ayrıştırılarak stage edilebilir
     • Değişiklikler delta düzeyinde karşılaştırılabiliyorsa kullanışlı olur
   • Spekülatif commit ve doğrusal geçmiş: context korunurken sık commit atıp commit geçmişini doğrusal tutma yöntemi
     • Stash ya da prototip denemeleri gibi, yapılan işi saklamak gerektiğinde her seferinde kaydet
     • Checkout gereken her yerde checkout yapıp commit atmaya devam ettikten sonra rebase ile doğrusal yapı korunur
     • git-branchless adlı araç bunu kolaylaştırır
     • git sl: anonim dalları izleyerek commit geçmişini iyi görselleştirir
     • git prev ve git next: önceki/sonraki birime checkout yapmayı kolaylaştırır
     • git sync: main üzerine rebase eder
     • git move: commit’i istenen yere taşıyabilir
     • git restack: rebase ya da commit --amend gibi işlemlerle commit sırası bozulduysa düzeltir
     • git undo: geri alma imkânı sağlar
3. Birleştirme
   • Patch stack: özellik[1/3], özellik[2/3], özellik[3/3] gibi parçalara bölerek inceleme yapılan yöntem
   • Birinci sınıf çakışma: Git ile uyumlu Jujutsu, çakışmaları commit’e kaydeder; böylece bir kez çözülmüş çakışmaların sonradan yeniden yaşanma olasılığı azalır
   • 3-way diff: Jujutsu’da çakışma olduğunda Base-Ours diff olarak, Theirs ise snapshot olarak gösterilir; bu sezgiseldir. Ancak IDE/editör sözdizimi vurgusu ya da Base-Their diff görmek isteyen ihtiyaçlar olabilir
   • İkili dosya çakışması: Git, binary dosyalarda çakışma olunca çözümü kullanıcıya bırakır; bu yüzden kişisel olarak Base ve Their dosyalarını oluşturan basit bir araç yapılmış
   • Patch ve e-posta: daha geleneksel(?) bir birleştirme yaklaşımına giriş
     • git request-pull, pull request oluşturmaya yarayan komuttur
     • git send-mail ile patch e-posta olarak gönderilebilir, git am ile de patch uygulanabilir
4. Diğer yönetim yöntemleri
   • Worktree: Git geçmişi paylaşılmaya devam ederken, SVN dalı gibi yalnızca çalışma dosyaları farklı yerlere checkout edilerek işler eşzamanlı yürütülebilir
   • Git LFS: büyük dosyaları yönetme yöntemi
   • Kısmi çoğaltma ve kısmi checkout: repository kısmen clone edilerek indirme süresi azaltılabilir, ayrıca yalnızca istenen dizinler checkout edilerek çalışılabilir
   • Scalar: Microsoft’un çabalarıyla çok büyük repository’leri daha kolay yönetmeye yardımcı olur