Git İpuçları ve Püf Noktaları

• Git’i uzun süredir kullanan kullanıcıların bile gözden kaçırabileceği az bilinen özellikler çok fazla; bu da ileri seviye komut satırı bilgisinin yaygın olduğu varsayımını sarsıyor
• SVN ve CVS’ten geçen kuşağın aksine, yalnızca Git kullanmış geliştiricilerin bazı ileri kullanım biçimlerini öğrenme fırsatı daha az oldu
• Git zaman içinde küçük ama faydalı özellikler eklemeyi sürdürdü ve bu değişiklikler belirli durumlarda pratik değer taşıyabiliyor
• Orta ve ileri seviye kullanıcılar için eski ama yararlı özellikler, yakın zamanda eklenen özellikler ve büyük depolar/monorepo konuları 3 kısa seriye ayrılıyor
• Alışıldık Git kullanım alışkanlıklarıyla görünmeyen özelliklere yeniden bakmak, günlük depo işlerini daha verimli yönetmeyi sağlayabilir

---

Git’e neden yeniden bakmalı?

• Yakın zamanda Git ve GitButler ile ilgili sunumlar yaparken birçok geliştiricinin Git hakkında bilmediği şeyler olduğunu gördü
• Geçmişte ileri seviye Git sunumları yaptı, ancak son yaklaşık 10 yıldır insanların ileri komut satırı özelliklerini zaten bildiğini varsayıyordu
• Yalnızca Git kullanmış geliştirici kuşağının, SVN ve CVS gibi araçlardan Git’e geçme ya da eski kavramları yeniden öğrenme gibi bir deneyimi olmadı
• Git de zaman içinde yeni özellikler öğrendi; bunların çoğu ince veya belirli kullanımlara yönelik değişiklikler olsa da gerçek iş akışında yardımcı olabilir
• Blog serisi, FOSDEM 2024 sunumu little known Git stuff temel alınarak hazırlandı

3 bölüme ayrılan Git ipuçları serisi

• Hedef kitle orta ve ileri seviye Git kullanıcıları; Git’i uzun süredir kullanıyor olsalar bile gözden kaçırmış olabilecekleri özellikleri ele alıyor
• Her şeyi tek yazıda toplamak yerine, birkaç konuyu bölerek 3 kısa yazı halinde sunuyor
• Dahil edilen konular:
  • Oldies but Goodies: eski ama hâlâ faydalı Git özellikleri
  • Some Subtle New Things: Git’e yakın zamanda eklenen ince değişiklikler
  • Really Large Repositories and Monorepos: çok büyük depolar ve monorepo’larla ilgili içerik
• İlk yazı Oldies but Goodies ile devam ediyor

[GN⁺]

Hacker News yorumları

• Yazarı olarak, bu konuların önemli bir kısmını ancak oldukça yakın zamanda öğrendiğimi kabul ediyorum. Büyük depolar ile ilgili özellikler, son birkaç yılda Microsoft ve GitHub’ın Git çekirdeğine parça parça eklediği şeyler; bu yüzden yaptıkları işleri tek yerde toparlayan bir kaynak bulmak zor olabiliyor.
  Mercurial tarafındaki kişilerle de ilginç sohbetler yaptıklarını, son dönemde Hg içlerinin bir kısmını Rust ile yazarak şaşırtıcı hız iyileştirmeleri elde ettiklerini söylüyor.
  Pro Git 3. baskı da aklında; Git’i zor yoldan öğrenirken fark ettiğiniz şeyler ya da öğrenmek istediğiniz konular varsa haber vermenizi istiyor.
  • Zaten biliyor olabilirsiniz ama Git’in diff’i yerine difftastic kullanmak iyi olur: https://difftastic.wilfred.me.uk/
    Sık kullandığım gitconfig alias’ları olarak fza, gone, root var. git fza, değiştirilmiş/yeni dosyaları bir fzf penceresinde gösterir ve seçilen dosyaları git add’e geçirir: https://github.com/junegunn/fzf
    git gone, uzakta olmayan yerel branch’leri siler; git root ise depo kökünü yazdırır, derin dizinlerden köke dönmek için kullanışlıdır. Bugünlerde zoxide kullandığım için daha az kullanıyorum: https://github.com/ajeetdsouza/zoxide
  • Boşluk farklarıyla ilgili bölüme ignore-revs-file da eklenirse iyi olur. Depoya bir ignore-revs dosyası commit’leyip, büyük bir yeniden biçimlendirme yapan kişinin ilgili SHA’yı eklemesiyle git blame’in bozulması engelleniyor.
    https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revltrevgt
  • Git’te zor yoldan öğrendiğim şeylerden biri, merge, cherry-pick, rebase gibi işlemlerin snapshot değil farklar ve patch’ler, daha doğrusu 3 yönlü merge üzerinden çalıştığıydı. Pro Git, Git’in snapshot depolama modelini iyi vurguluyor; ancak yalnızca bu modelle düşününce özellikle rebase kafa karıştırıcı olabiliyor.
    Örneğin rebase sırasında yalnızca bir commit’i silmişken, neden sonraki tüm commit’lerin değiştiğini anlayamamıştım. Sonunda depolamanın snapshot tabanlı, işlemlerin ise fark tabanlı olduğunu fark edince rebase’i anlayabildim; eğitim verirken bu kısmı daha fazla vurgulamak da yardımcı olur.
• Git numaraları öğrenmek istemiyorum; onu olabildiğince basit kullanmak istiyorum. Kodumu push’layıp Git’i bitirmek ve çalışmaya devam etmek istiyorum sadece.
  Git’i sevenlere saygı duyuyorum ama benim için sadece kullanmak zorunda olduğum bir araç.
  • Git’in karmaşıklığının bir kısmı, Git’in aslında düşük seviyeli tesisat (plumbing) olarak tasarlanmış olmasından geliyor. Git veri modelinin üstüne daha kullanıcı dostu bir yüzey (porcelain) geleceği bekleniyordu; bu yüzden basit ve tutarlı bir UI elde etmek için bugün de en iyi yön bu olabilir. Jujutsu ve Got (game of trees) buna örnek olabilir.
  • Bu duyguyu anlıyorum ama Git o kadar da zor değil. Temel checkout/commit/push dışında, özellikle geçmişi yeniden yazma gibi birkaç şeyi bilmek commit geçmişinin kalitesini ciddi ölçüde artırır ve projedeki diğer mühendislerin akışı anlamasını kolaylaştırır.
    Git sektörde uzun süre kalacak bir sabit gibi görünüyor ve günlük geliştirmede en sık dokunduğumuz araçlardan biri; bu yüzden biraz incelemeye değer.
  • Bazı ayrıntılar problemin doğasında var, bazıları yok. Doğasında olan zorluğu hafife alma eğiliminde olduğumuzu düşünüyorum.
    Bu yüzden Git’in belli ölçüde karmaşıklığa sahip olması bence sorun değil.
  • Programlama öğrenmek istemiyorum, bilgisayarı olabildiğince basit kullanmak istiyorum demeye benziyor. Sadece ne yapılacağını söyleyip bitirmek istiyorum, gibi.
  • Git arayüzü sızıntılı bir soyutlama gibi hissettiriyor. Git numaraları öğrenmek istemiyordum ama sonunda istediğimden daha fazlasını öğrenmiş oldum.
• core.fsmonitor hakkında yeni bir şey öğrendim. Büyük monorepo açısından bakınca git clone için devam ettirme seçeneği olsaydı iyi olurdu.
  2000’lerde düşük bant genişlikli bağlantıyla kernel deposunu clone’lamaya çalışırken aynı sorunu yaşamıştım; mailing list’te yardım istedikten sonra ancak biri kişisel sitesine tüm depoyu sıkıştırılmış tar olarak koyunca indirebilmiştim.
  Bugün bile şirket VPN’i kısa süreli kopunca büyük depo clone’larında ara sıra aynı sorun oluyor. Windows deposunun 300 GB’ını %95 indirdikten sonra Wi-Fi’nin bir anlığına koptuğunu hayal edin.
  Modern geliştirme stack’inde bant genişliğini çok kullanan iki büyük araç olan Git ve Docker’ın indirmeye kaldığı yerden devam etmeyi düzgün desteklememesi garip.
  • İstediğiniz şey git bundle’a yakın görünüyor. Ancak en başta birinin bundle oluşturması gerektiği şartı var.
    https://git-scm.com/docs/git-bundle
  • Shallow clone yapıp sonra birkaç kez genişletmek mümkün olabilir gibi. Yine de fetch/push protokolü temelde daha küçük depoları ya da çok iyi internet bağlantısı ve sunucuları varsayıyor.
• Çok ilginç. Birden fazla kişinin farklı release’lere, özelliklere ve hotfix’lere katkı verdiği; release’lerin tag’lendiği ve bug bulmak için geçmişe dönüldüğü sorunları daha kolay bir arayüzle kimin çözebileceğini görmek isterim.
  Sistem karmaşıklığını gizleyen düşük seviyeli bir dil istemeye benziyor; ikisi aslında fiilen birbirini dışlıyor. Git tatmin edici ve öğrenmesi o kadar zor değil, bu yüzden işin bir kısmında Git’i öğrenmek gerekiyor.
  • Bu yüzden GitKraken’ı güçlü şekilde tavsiye ediyorum. Ücretli bir ürün olduğu için temkinliyim ama birçok araç denedim ve hiçbiri GitKraken kadar gücü açığa çıkarmadı.
    Terminalde birçok geliştiricinin hissettiği kara kutuyu ortadan kaldırıp grafiği öne çıkarıyor; rebase işlemlerini görsel olarak doğal biçimde gösterdiği için Git’i eğlenceli hale getiriyor.
    CLI yetkinliği hâlâ değerli, ama 10 yıllık geliştiricilerin temel sorunları çözerken bocaladığını ya da “gerçek mühendis Git CLI’dan başka bir şey kullanmaz” havası yüzünden proje geçmişini mahvettiğini görmek sinir bozucu.
    Bugünlerde CLI kullansanız bile, gün boyu başka bir pencerede grafiğe bakın diyorum. VS Code, JetBrains, hatta CLI’da bile ücretsiz olarak mümkün.

Bir ekip üyesi PR’ı birleştirir birleştirmez bunu görüp kendi dalımı rebase ettiğim için, dal her zaman main tabanında güncel kalıyor; böylece merge cehennemine düşmüyor ya da berbat “fix conflicts” commit’leri bırakmıyorum

• Dün oluşturulduktan sonra en çok değiştirilen ilk 10 dosyayı ararken https://github.com/tj/git-extras/blob/main/Commands.md adresini keşfettim
  Kullanışlı pek çok ek Git komutu var

  • git-extras iyi. Bir başka güzel araç da git absorb: https://github.com/tummychow/git-absorb

• GitKraken gibi modern UI istemcileri gayet kullanılabilir ve yardımcıyken, çoğu geliştiricinin neden özellikle Git CLI’da ısrar ettiğini pek anlayamıyorum: https://www.gitkraken.com/

  • CLI bilgisi betik yazmaya, betiklerden öğrenilen Git bilgisi de tekrar günlük kullanıma taşınır. Sunucu olarak kullandığım Raspberry Pi’ye SSH ile girdiğimde CLI kullanmam gerektiği için çaresiz kalmak istemem
    GUI’ye tamamen karşı değilim ama şu an CLI daha verimli ve şu koşulları sağlayan bir GUI aramaya zaman harcamak istemiyorum:
    İyi görünmeli, içine eski usul bir web tarayıcısı gömülmüş bir şey değil yerel bir uygulama olmalı, telemetri olmamalı ya da varsayılan olarak kapalı olmalı, tamamen açık kaynak olmalı ve 5 yıl sonra da ortadan kaybolmayacağını umabilmeliyim
    Ayrıca işleri daha da kafa karıştırıcı hâle getirmemeli. Eski şirketimde Visual Studio kullanmak zorundaydım; aslında “çakışma çözüldü olarak işaretle” anlamına gelen bir düğmenin üstünde ürkütücü biçimde “Accept merge” yazıyordu
    Belirli bir kelimenin belirli bir anlama geldiğini bekleyen insanları şaşırtmamalı; “Commit changes” düğmesinin yardımseverlik adına uzaktaki depoya push da yapması gibi davranışlara da güvenmek zor
  • CLI da gayet kullanılabilir. Editör eklentileri de kullanıyorum ama zaten komut satırındaysam işi orada hallediyorum
    Tek bir commit atmak için başka bir programa geçmem gerekiyorsa sık commit atma isteğim azalıyor
  • Çok belirli bir sorun olmadığı sürece Git ile yaptığım işleri en aza indiriyorum. Benim durumumda fiilen push, pull, checkout civarında olduğu için GUI kullanmak fazla geliyor
  • Temiz görünüyor ama grafik arayüzler çok kolay dikkat dağıtıcı hâle geliyor. Sonuçta kişisel tercih meselesi gibi görünüyor; CLI hızlı ama öğrenme eğrisi yüksek
    CLI’da Git kullanırken de çoğu şey özel değil, sadece birkaç komut; sık kullanmadığım ipuçlarını ve püf noktalarını bir metin dosyasına yazıyorum

• -committerdate’i biliyordum ama varsayılan sıralama olarak ayarlanabildiğini bilmiyordum; çok faydalı. Birkaç notum var
  git columns, ekrana sığmayıp kaydırmak gerektiğinde epey kafa karıştırıcı oluyor; sayı olursa iyi olurdu
  git maintenance iyi görünüyor ama çok rebase yaptığım için endişeliyim. Gevşek nesneleri gc’den daha hızlı kaybedip kaybetmediğini merak ediyorum. gc’nin kapalı olduğu görülüyor ama net değil
  git blame ile ilgili, pek bilinmeyen ama yararlı bir betik olarak https://github.com/gnddev/git-blameall var. O kadar az biliniyor ki kendim Python 3’e portlamak zorunda kaldım; üstelik Python geliştiricisi de değilim

  • Zamanlanmış bakımda gc devre dışı bırakılır. maintenance run açıkça çalıştırıldığında ise bir görev olarak etkinleşir
    Gevşek nesneleri gc’den daha hızlı toplamaz. Sonuçta sadece gc çalıştırır
  • Ters sıralamanın mümkün olup olmadığını merak ediyorum. Dalların ekranın dışına itilmesi sorununun basit çözümü en yeni dalları en sona koymak gibi görünüyor. Ben kullanıcı betiğiyle bunu yapıyorum
  • Daha hızlı kaybetmez. Sadece uzaktan verileri daha sık çeker ve verileri yeniden paketler. GC kapalıysa veri silinmez
    git-blameall iyi görünüyor, bir denemem gerekecek

• Birden çok ortamda çalışan birkaç alias ile Git akışımı büyük ölçüde basitleştirdim
  git synced, mevcut dalı upstream varsa onunla, yoksa origin ile rebase ederek senkronize eder. master veya main kullanır ve main’e öncelik verir
  git pub, değişiklikleri uzak origin’e yayımlar ve lease’li force push kullanır
  git pr, GitHub’da uygun PR URL’sini açar; GH istemcisi gerekmez. Upstream tanımlıysa PR’ı oraya gönderir
  git hub, deponun GitHub sayfasını açar
  https://softwaredoug.com/blog/2022/11/09/idiot-proof-git-aliases.html

  • Ayraç olarak kullandığı o tuhaf tüylü oku neden seçtiğini merak ediyorum

• Ne yaptığımı biliyormuş gibi davranmayı bırakıp görsel Git araçları kullanıyorum. SmartGit ya da IntelliJ’nin içindeki araçlar gibi. Git “komut satırı kahramanlığı” bana daha çok gösteriş gibi geliyor
  Kullanıcıya yönelik komut katmanı sinir bozucu derecede kafa karıştırıcı olabiliyor. Örneğin Yours ve Theirs, bağlama göre tamamen zıt anlamlara gelebiliyor
  Tüm kullanıcı arayüzünde ortak bir stil ya da tema yok; insanı delirtmemek için yeni bir görsel katman gerekiyor

  • Ben de aynı fikirdeyim. Farkları her zaman görebilmek ve ne olacağını tek bakışta görsel olarak doğrulayabilmek hoşuma gidiyor. Bir sürü ek komut çalıştırmaya da gerek kalmıyor
    Uygulamayı ve genel olarak Git’i işim için gerektiği kadar biliyorum; nadiren daha fazlası gerekirse bakıp öğrenirim. Yıllardır kullanıyorum, böyle durum bir ya da iki kez oldu
  • Günlük işlerimde her zaman görsel bir Git aracı, özellikle Tortoise Git kullanıyorum
    Başkalarının ya da kendi hatalarımı düzeltmem gereken karmaşık işlerde de önce görsel araçla geçmişi, commit’leri, reflog’u ve farkları inceleyip neyin karıştığını ve kurtarılabilecek bir şey olup olmadığını anlamaya çalışıyorum
    Geri dönecek tek bir commit varsa reset --hard yapıyorum; birden çok commit’ten bir şeyleri birleştirmem gerekiyorsa genellikle komut satırını kullanıyorum

• İkisi birbirini dışlamaz. Diff ya da çakışma gibi şeylerde yalnızca görsel araçlar kullanıyorum, ama commit nesnesi, reflog, rebase’in arka planda ne yaptığı, etkileşimli rebase, hard/soft reset vb. şeyleri öğrenirken çok şey kazandım.