Beej'in Git Rehberi

 (beej.us)
1 puan yazan GN⁺ 2025-02-06 | 1 yorum | WhatsApp'ta paylaş
  • Git öğrenmek veya başvuru kaynağı olarak kullanmak isteyen okurlar için HTML ve PDF dağıtımları birden fazla biçimde sunan bir rehber sayfasıdır
  • Rehberin kendisi hata içerebileceğini peşinen kabul eder ve Git ile ilgili yanlış içerikler için e-posta yoluyla düzeltme önerileri alır
  • HTML dağıtımları, okuma ortamına göre bölümlü sürüm, tek sayfa, geniş ekran ve ZIP gibi seçeneklerle tercih edilebilir
  • PDF'ler US Letter ve A4 olarak; tek taraflı-çift taraflı, sözdizimi vurgulu-siyah beyaz kombinasyonlarıyla indirilebilir
  • Çevirmenler ve yazarlar tüm materyali GitHub'dan clone ettikten sonra README'yi izleyerek çalışabilir

Okuma için dağıtım biçimleri

Düzeltme önerileri ve özgün çalışma materyalleri

  • Rehberin hata içerebileceği kabul ediliyor ve düzeltme önerileri e-posta ile alınıyor
  • Çevirmenler ve yazarlar GitHub deposunu clone edip README'yi takip edebilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-02-06
Hacker News yorumları

  • Hatalı bir yer bulursanız paylaşın. Ben toparlayıp düzelteceğim — Beej

    • Hata değil ama Git bağlamında vim'den bahsediliyorsa :cq da eklenebilir. Sıfır olmayan bir çıkış durumuyla çıkarak Git'in commit'i ya da işlemi tamamlamasını engelleyebilir
    • Gerçekten harika bir iş; böylesine kapsamlı bir kaynak hazırladığın için teşekkürler. Hepsini okuyamadım ama 5.1 bölümündeki ifade gözüme çarptı
      https://beej.us/guide/bggit/html/split/branches-and-fast-for... sayfasında “varsayılan branch main'dir” ve “eskiden master'dı, eski depolarda hâlâ master vardır” deniyor; bu doğru değil. Git hâlâ varsayılan olarak master kullanıyor ve sadece ileride git init için git config --global init.defaultBranch ile bunun değiştirilebilmesine izin veriyor
      Kaynak: https://github.com/git/git/blob/bc204b742735ae06f65bb20291c9...
      Ayrıca “eski depolar” ifadesi yanlış bir mesaj veriyor. Bu değişikliğe GitHub karar verdi, başka yerler de onu izledi; Git'in kendisi de yukarıdaki ayara izin verir hâle geldi. Yani bu yeni depo/eski depo meselesi değil, daha çok bir tercih meselesi
    • Lambda School'da eğitim alan sayısız öğrenciden biriydim; o zamanki ders, en akılda kalıcı anlarımdan biriydi
    • Gençliğimde C programlama rehberini okumuştum; bugün bir firmware geliştiricisi olarak hâlâ büyük bir borcum olduğunu hissediyorum
    • Hata değil ama git worktree de bahsetmeye değer. Benim iş akışımda kilit önemdeydi ve varlığından bile haberi olmayan çok kişi vardı
      stash ile uğraşma zahmetine girmeden branch'lerin birbirine karışmasını önlemenin iyi bir yolu

  • Gençliğimde okuduğum Beej's Guide to Network Programming ve Beej's Guide to Unix IPC hem erişilebilirdi hem de derinliğe sahipti; sonrasında nasıl bir programcı olduğumu büyük ölçüde etkiledi
    [0] https://beej.us/guide/bgnet/
    [1] https://beej.us/guide/bggit/

    • [1], https://beej.us/guide/bgipc/ olmalı
    • Ben de benzerim. 90'ların ortasında ergendim ve IRCd sunucu kodu ile botlar beni büyülemişti
      İkinci el, yanında CD-ROM gelen Slackware Linux Unleashed almıştım; içinde C ağ programlama örnekleri vardı. O kodlar kafamı karıştırınca Beej'in ağ programlama sitesini buldum. Oradan daha da içine çekilip derin bir tavşan deliğine girdim; programlama kitapları bulmak için birçok kitapçıyı dolaşırdım
      Richard Stevens'ın harika başvuru kitabını aldıktan sonra geriye bakmadım; o tutkuyu mümkün kıldığı için Beej'e hâlâ minnettarım
    • select kullanmayı öğrendiğim dönem, bir port tarayıcıyı (muhtemelen “grabb”?) daha hızlı yapmak istediğim için Beej'in ağ rehberini İtalyancaya çevirdiğimi hatırlıyorum. Güzel zamanlardı
    • Aynı kişi mi diye bakmaya gelmiştim; sayfa sayfa kendine özgü eski web tasarımını görünce neredeyse emin oldum
      Babam telefon faturasına kızmasın diye sayfaları çevrimdışı okumak üzere kaydettiğim dönemlerdi; kod çalıştığında, hayattaki önceki başarısızlıkların ve reddedilmelerin ötesinde bir onay gibi gelirdi. Bir bilgisayardan diğerine mesaj göndermenin sevinci büyüktü

  • “Eski komut: git checkout” ifadesini görünce git switch diye bir şey olduğunu bile bilmediğimi, git checkout'un da eski bir alternatif sayıldığını bilmediğimi fark ettim. Kendimi yaşlanmış hissettim
    Git öğrenmeye neredeyse 10 yıl önce başladım, hadi bunu anlayayım; ama bugün Git öğrenen birinin benim neden git checkout kullandığımı garipseyebilecek olması tuhaf. Eski moda bir ifade kullanıyormuşum gibi
    Metne dönersek, ben öğrenirken bu rehber olsaydı gerçekten çok faydalı olurdu. Takip etmesi kolay ve sık sorulan soruları iyi ele alıyor
    İlk merge conflict'ten korkup durduktan sonra, conflict'ten kaçınmak için etrafından dolandığımı da iyi hatırlıyorum

    • git switch oldukça yeni bir komut ve ilk kez 2019'da yayımlandı
      2021'deki bir tartışma ve birkaç hafta önceki bir tartışma var; ikincisinde dokümantasyonda git switch'in hâlâ deneysel özellik sayıldığı da geçiyor
      https://news.ycombinator.com/item?id=28024972
      https://news.ycombinator.com/item?id=42649858
    • git checkout'un hâlâ “eski alternatif” sayıldığını düşünmüyorum. Son kontrol ettiğimde switch hâlâ deneyseldi; yaklaşık 15 yıl önce Git öğrenirken edindiğim iş akışı ve komutlardan sapmayı da düşünmedim
      Yapmak istediğim her şey hâlâ aynı şekilde çalışıyor, git checkout da eskisiyle aynı işleri yapıyor ve başkalarıyla Git üzerinden işbirliği yaparken sorun yaşamıyorum; o hâlde iş akışımı değiştirmem için bir sebep yok

  • Git kullanımını anlatan 30’dan fazla bölümlük bir rehbere ihtiyaç duyulması bile, Git’in büyük resmi kaçırmış gibi hissettirdiğini gösteriyor

    • Karmaşık veri yapıları üzerinde karmaşık işler yapan karmaşık bir araçta belli ölçüde karmaşıklık olmasına programcıların neden bu kadar sert tepki verdiğini anlamıyorum
    • İnsanlar Git’ten şikâyet etmeye harcadıkları çabanın yarısını Git öğrenmeye harcasaydı, kılavuz sayfalarında bulunabilecek şeyleri açıklamak için 30’dan fazla bölümlük bir rehber yazmaya gerek kalmazdı sanırım
      Commit, ağacın bir anlık görüntüsüdür ve bir ata listesine sahiptir. Genellikle bir tanedir ama her zaman öyle değildir. Tag, değişmeyen bir commit etiketi; branch ise değişen bir commit etiketidir. Index, commit etmeden önce add ile doldurduğunuz, üzerinde çalışılan küçük bir proto-commit’tir
      Git budur. Daha fazlasını bilmek istiyorsanız rehber okumak yerine “ağacı etkilemeden belirli bir Git commit’ine nasıl geçilir”, “değiştirilen dosyaların yalnızca bir kısmı nasıl commit edilir”, “başka bir yerdeki commit mevcut ağaca nasıl kopyalanır” gibi aramalar yapabilirsiniz
      Temel soyutlama minimalist ve kolaydır. Bu soyutlamayla yapmak istediğiniz işler incelikli ve karmaşıktır. İlkini öğrenip ikincisini aramak yeterli; rehber okumaya gerek yok
    • Git kullanımı HN yorumunda 5 satırda da anlatılabilir: git clone, git checkout, git pull, git add + commit + push, git reset / rebase
    • Yine de kendi ayağınıza sıkabilirsiniz
    • Hem öyle hem değil. Git’in kullanıcıya yönelik komutları muhtemelen kullanıcıların %95’i için yeterince iyi
      rebase -i içinde hangi komutun ne yaptığına dair açıklamalar var; git log çıktısını zevke ve ödünlere göre biçimlendirmeyi anlatmak da birkaç paragraf sürer. Genelde kullanıcıya yönelik komutlara git gc, git fsck, git rev-parse gibi epey dağınık şeylerin de dahil olduğunu düşünüyorum
      Düşük seviyeli komutlar kesinlikle daha anlaşılması zor ve yaygın kullanım senaryolarına optimize edilmiş kullanıcı komutlarıyla her zaman kolayca yapılamayan pek çok işi kendi başlarına yapıyorlar
      Özetle Git büyük, hatta devasa; ama geliştiricilerin çoğu için sunduğu özelliklerin önemli bir kısmı ana akıştan epey uzakta kalıyor

  • Korkutucu olan, rehberin bu kadar uzun olması
    Beej’in rehberlerinin genel olarak kapsamlı olduğunu biliyorum ama Git’in uçsuz bucaksız nüanslarını bunu görene kadar tam kavrayamamıştım
    Jujutsu için çok daha ince bir rehber olurdu ya da en azından insanların keşfederek öğrenmesini daha kolaylaştıran bir rehber olurdu gibi geliyor

    • Kendi rehberlerimin çoğunu, yeterince okuduğunuzu hissettiğinizde okumayı bırakabileceğiniz şekilde hazırlamaya çalışıyorum. Hepsini okumanız gerekmiyor
      Bu rehberin Git’in yaklaşık %10’unu ele aldığını hissediyorum ama yaygın kullanımın %90’ını kapsamasını umuyorum
    • Bu rehber kapsamlı tarafta; bunun tam karşı ucunda ise ileride ihtiyaç duyacağınız Git komutlarının %90’ını içeren tek sayfalık bir kaynak var: https://wizardzines.com/git-cheat-sheet.pdf
    • Bu, Git’in çoğunluk için uygun bir araç olmadığının ama bir şekilde standart gibi yerleştiğinin işareti gibi görünüyor

  • İş yerinde yılda bir iki kez, 2 saatlik Git veri modeline giriş dersi veriyorum
    Gerçekten .git dizininin içine girip dosyaları açarak her şeyin temel veri yapılarının düz metin temsillerinden ibaret olduğunu gösteriyorum. İnsanların zihninde taşların yerine oturduğu anı görmek gerçekten harika
    Yeni işe başlayanların kod commit etmeye başlaması için temel Git tarifleri belgesini paylaşıyoruz ama çoğu, ne olup bittiğini anlamadan aynen takip ediyor
    Buna karşılık dersi alanlar tüm komutları iyi bilmese de Git’te gerçekte neler olduğuna dair oldukça makul bir çalışma anlayışı kazanıyor. Komutlar kolayca aranabildiği için, zihinsel model doğruysa komutların kendisi büyük bir sorun değil. Buna rağmen HN’deki neredeyse tüm Git yazısı tartışmaları komut satırı konusuna kayıyor
    İlginç biçimde bu ders https://xkcd.com/1597/ içindeki alternatif metne benziyor. Fark şu ki, teknik okur için bu gerçekten Git öğretmenin doğru yolu ve bir kez anladığınızda unutmayacağınız temel bir kavrayış kazandırıyor
    Açıkçası bunun zaman karşılığı getirisi o kadar yüksek ki yapmamak tuhaf geliyor

    • Ben de bir kez yaptım; gerçekten çok iyiydi ve ardından gelen tartışma da mükemmeldi
      Sunumun son slaytına Git veri modeline dayanarak meslektaşların yanıtlayacağı sorular koydum. Örneğin “Bir commit başka bir branch’e taşınabilir mi?”, “Commit grafiğinde döngü olmadığını ne garanti eder?” gibi sorular
      İnsanların yalnızca Git kullanmakla kalmayıp Git gibi düşünmeye başlaması gerçekten tatmin ediciydi
    • “Zihinsel model doğruysa komutlar büyük bir sorun değildir” sözü ilk başta 90’larda sık gördüğümüz “Linux’un tüm katmanlarını ve tüm parçalarını anlarsanız Linux kullanmak kolaydır” türü bir mantık gibi gelmiş olabilir. Teoride doğru ama çoğu kişi için pratikte imkânsız gibi
      Neyse ki erken dönemde Git’in iç modelinin bir kısmını açıklayan bir video izledim ve aslında iç bilginin o kadar fazla ya da derin olmasına gerek kalmadan büyük fark yarattığını gördüm. Git’in nasıl çalıştığının yaklaşık %5’ini bilmek bile komutların ne yaptığını ve nasıl kullanılmaları gerektiğini çok daha iyi anlamamı sağladı
    • O 2 saatlik dersin materyallerini ya da kaydını paylaşmayı engelleyen özel bilgi veya kısıt yoksa paylaşabilir misiniz merak ediyorum
      Herkese açık ve 2 saate sığacak kadar özlü bir materyale dayanıyorsa bunu bu thread’de ya da HN yazısı olarak paylaşmanız harika olurdu. Aynı konuda bile varsayımları, benzetmeleri ve odağı farklı olan öğrenme materyalleri ne kadar çok olursa o kadar iyi diye düşünüyorum
    • Sunumun bir kopyası ya da videosu var mı, yoksa önerebileceğiniz benzer bir kaynak var mı merak ediyorum
    • Videoyu paylaşın lütfen

  • Git’in genel akışı, merge, rebase gibi şeyleri bir ölçüde yapabiliyorum ama Git’te daha iyi olmaya çalışmaktansa ciddi ciddi jujutsu’ya geçmeyi düşünüyorum. jj Git ile uyumlu ve iş arkadaşlarım normal Git kullanırken yalnızca ben kullanabiliyorum

  • Pek çok rehberin ve çoğu Git GUI’sinin kaçırdığı bir püf noktası olduğunu düşünüyorum. İstisna olarak magit bunu iyi ele alıyor
    Upstream branch’i feature/foo için origin/feature/foo olarak değil, birleştirmek istediğiniz hedefe, yani entegrasyon branch’i olan master ya da origin/master olarak ayarlamak
    Böyle yapınca pek çok şey basitleşiyor. git status çalıştırdığınızda entegrasyon branch’inden ne kadar ayrıştığınızı söylediği için işe yarıyor; argümansız git rebase çalıştırınca da doğrudan upstream’in üzerine rebase ediyor
    Upstream’i origin/feature/foo olarak bırakmak daha az kullanışlı. Geliştiriciler uzaktaki kendi branch’lerine de genelde “sahip” olduğundan, ondan ne kadar ayrıştığınız pek anlamlı değil; oraya rebase etmek isteyeceğiniz bir durum da olmaz
    push.default değerini "current" olarak ayarlarsanız git push da beklendiği gibi feature/foo’yu origin/feature/foo’ya push eder
    Bu ayarın neden daha yaygın olmadığını merak ediyorum

  • İş birliği bölümünde feature branch’ler hiç ele alınmıyor. Oldukça yaygın bir çalışma biçimi değil mi diye düşünüyorum
    Rehberdeki “herkesin kendi branch’ini kullandığı yöntem” ile karşılaştırmak faydalı olabilir. Ayrıca 17. bölümde GitHub pull request’lerinde branch’i yeniden kullanma yöntemi ile her PR için yeni branch oluşturma yöntemi ele alınabilir

  • Yazıyı henüz kontrol etmedim ama iyi olacağını düşünüyorum. Bir başka öneri olarak Primeagen’ın öğrettiği boot.dev Git kursu var
    İnteraktif ve .git dizini içindeki dosyaları doğrudan manipüle etme seviyesine kadar derine iniyor. O kursu aldıktan sonra Git’in nasıl çalıştığına dair tamamen yeni bir zihinsel model edindim