ตัวอย่างบทเรียน

Git Neden Gereklidir — ve Neden İşe Alırken Onsuz Yapamıyorlar

Komutlarla değil, acıyla başlayacağız: versiyon kontrolü olmadan geliştirmenin nasıl göründüğüne bakacağız — 'proje_son_2', 'proje_son_KESİN_SON' klasörleri ve fazlalığı silme korkusu. Git'in tam olarak hangi sorunu çözdüğünü, neden endüstri standardı haline geldiğini ve bir işverenin GitHub profilinize baktığında neyi kontrol ettiğini anlayacaksınız.

versiyon kontrol sistemi değişiklik geçmişi dağıtık mimari
คุณจะเรียนรู้อะไรในบทเรียนนี้
  • Bir mülakatta veya işverene versiyon kontrolünün neden gerekli olduğunu kendi kelimelerinizle, ezberlenmiş tanımlar olmadan açıklayabileceksiniz.
  • Git'in dağıtık modelinin merkezi sistemlerden temel olarak nasıl farklı olduğunu ve bunun pratikte neden önemli olduğunu anlayacaksınız.
  • İşe alım sürecinde hangi belirli Git becerilerinin test edildiğini fark edeceksiniz.

จุดเริ่มต้นของบทเรียน

SON_KESİN_SON — Sizin Suçunuz Değil

  • Tanıdık klasörler: proje_v2, son_düzeltmeler
  • Versiyon kontrol sistemi olmayan herkes böyle yapar
  • Bu kaos değil — ilkel versiyonlama
  • Git'i anlamaya ilk adımınız

Bilgisayarınızda 'proje_v2' veya 'son_düzeltmeler_gerek' gibi isimlerle klasörler gördüğünüzde, kendinizi düzensizlikle suçlamayın. Özel bir araç olmadan dosyaların farklı sürümlerini kaydetme ihtiyacıyla karşılaşan herkes aynısını yapar. Öğrencilerden deneyimli geliştiricilere kadar herkes, versiyon kontrol sistemlerini keşfetmeden önce bu aşamadan geçer. Aslında, versiyonlamayı zaten icat ettiniz — sadece en ilkel biçimde. Bu kaos değil, Git'in neden gerekli olduğunu anlamaya yönelik doğal bir adımdır.

Silme Korkusu: Tarihçe Sadece Kafanızda Yaşadığında

  • Değişim geçmişi sadece kafanızda
  • Önemli bir şeyi silme korkusu
  • 40 dosya versiyonu — hangisi doğru?
  • Bellek ölçeklenmez ve yedekleme yapmaz

Bir roman yazdığınızı ve her gün yeni bir kopya kaydettiğinizi hayal edin: 'roman_taslak', 'roman_SON', 'roman_SON_editör_düzeltmeleri'. Bir ay sonra kırk dosyanız var ve üçüncü bölümün o harika versiyonunun hangi dosyada olduğunu artık hatırlamıyorsunuz. Bu yaklaşımın ana sorunu, değişim geçmişinin yalnızca sizin kafanızda var olmasıdır — insan hafızası mükemmel değildir ve yedekleme yapmaz. Bu yüzden, açıkça güncelliğini yitirmiş olsalar bile eski sürümleri silmekten korkarsınız.

Tek Geliştirici Kaos Yaratır — Ekip Yok Eder

  • Takımda kaos kaçınılmazdır
  • Güncel versiyonların olduğu arşivler e-postayla gelir
  • Biri başkasının düzeltmelerini siler
  • İşbirliği için bir araca ihtiyaç var

Tek başınıza çalışırken, farklı versiyon klasörleri sistemi bir şekilde işlev görür. Ancak projeye ikinci bir kişi girdiğinde gerçek kaos başlar. Birisi yanlışlıkla başkasının düzeltmelerini siler, 'güncel' versiyon e-postayla arşiv olarak gelir ve bir hafta sonra hangisinin gerçekten son versiyon olduğunu kimse anlamaz. Buradaki sorun insanlarda veya dikkatsizliklerinde değil — tüm değişiklik geçmişini hatırlayan ve farklı kişilerin düzeltmelerini düzgün bir şekilde birleştirebilen bir aracın olmamasıdır. İşte Git tam olarak bu sorunu çözer. Peki gerçek bir projede versiyon kontrolü olmadan çalışmak nasıl görünür? Şimdi belirli kayıp senaryolarını inceleyelim.

บทเรียนฉบับเต็มใช้ได้เมื่อสมัครสมาชิก

ฉบับเต็มมีสไลด์เพิ่มอีก 28 สไลด์

วิดีโอ สไลด์ทั้งหมด โน้ต แบบทดสอบ AI ติวเตอร์ และการสัมภาษณ์จะเปิดหลังเข้าสู่ระบบและสมัครสมาชิก

เข้าสู่ระบบหรือลงทะเบียน สมัครสมาชิก

เนื้อหาบทเรียน

  1. SON_KESİN_SON — Sizin Suçunuz Değil
  2. Silme Korkusu: Tarihçe Sadece Kafanızda Yaşadığında
  3. Tek Geliştirici Kaos Yaratır — Ekip Yok Eder
  4. Dosyayı Sildiniz — Kod Sonsuza Kadar Kayboldu
  5. Geri Dönülemiyorsa — Dokunmamak Daha İyidir
  6. Takımda: Tek Dosya, Tek Hayatta Kalan
  7. Geçmişsiz Kaos: dosya_son_v3_SONUC.docx
  8. VCS — Kodunuz İçin Bir Zaman Makinesi
  9. VCS'nin Cevap Verdiği Üç Soru
  10. Her Commit'in Dört Bileşeni
  11. Git, Dosyalar Arasındaki Farkı Değil, Anlık Görüntüleri Saklar
  12. git log: Proje Günlüğünü Canlı Olarak Okuyun
  13. Merkezi VCS: Sunucu Her Şeyi Saklar
  14. Tek Sunucu – Tek Hata Noktası
  15. Ekip Büyüdükçe Darboğaz Daralır
  16. Tek Sunucu — Tek Hata Noktası
  17. Tam Kopya: Geçmiş, Dallar, Her Şey Yerelde
  18. Dağıtık Yapının Sağladığı Üç Özgürlük
  19. Git Neden Tam O Zaman Yaratıldı?
  20. Git'in Kazanmasının Üç Nedeni
  21. Git ≠ GitHub: Yeni Başlayanların En Büyük Kafa Karışıklığı
  22. Tüm Yeni Başlayanları Engelleyen Kafa Karışıklığı
  23. Git — Bilgisayarınızda, GitHub — Bulutta
  24. Word, Google Drive ve Git'e Üç Alternatif
  25. GitHub — Eyleme Geçmiş Özgeçmişiniz
  26. Doküman Olarak Okunan Üç Sinyal
  27. Profili Öldüren Şeyler: Görünmezlik ve Dijital Çöp
  28. Anlamsız Aktivite: Profilin Üç Tuzağı
  29. Depolardaki Sırlar: Neden Felakettir
  30. “Süreci Anlıyorum” Diyen Profil
  31. Özet ve Ödev

บทความเกี่ยวกับบทเรียนนี้

บทเรียนทั้งหมดในคอร์สนี้

  1. Giriş: Sıfırdan Güvenilir Geliştiriciye Git
  2. Git Neden Gereklidir — ve Neden İşe Alırken Onsuz Yapamıyorlar
  3. Kurulum ve Yapılandırma: Git'i İlk Çalıştırmaya Hazırlama
  4. İlk Depo: init, add, commit ve İndeksin Sihri
  5. Geçmişi Okumak: log, diff, show ve Geçmişte Gezinti
  6. Dallar: Kodunuzun Paralel Gerçekliği
  7. Hataları Geri Alıyoruz: restore, reset, revert — Doğru ve Tehlikeli Kullanımları
  8. GitHub ve Uzaktaki Depolar: Kodunuz Bulutta
  9. Takım Çalışması: Fork'lar, Özellik Dalları ve Pull Request'ler
  10. Birleştirme Çakışmaları: Panik Yapmayın — Anlayın ve Çözün
  11. Gerçek Ekiplerde Git Süreçleri: Hangi İş Akışı Seçilmeli
  12. Gelişmiş Araçlar: rebase, stash, cherry-pick ve etiketler
  13. Final Proje: Gerçek Ekip Çalışmasını Simüle Ediyoruz