17 Kasım Pazartesi günü Marmara Üniversitesi\'nde öğrencilere Git & Github konusunda kısa bir eğitim verdim, eğitim için hazırladığım sunumun biraz daha detaylı halini de burada okurlarımla paylaşmak istiyorum. Neden Versiyon Kontrolü? İnsanın hafızası değişkendir; kodun hafızası Git’tir. Dosyaları “final_v3_son_bu_gercekten.zip” adıyla çoğaltma devri gitin ortaya çıkmasıyla birlikte son buldu. Git zaman makinesi gibi commit geçmişi tutar, Ekiplerin paralel çalışmasını sağlar, Hataları geri almayı mümkün kılar, “Kim, neyi, ne zaman değiştirdi?” sorusuna net yanıt verir. Git, tek başına yerel bir araç; GitHub ise bu Git depolarını barındıran, iş birliği araçları (Pull Request, Issues, Actions vb.) ekleyen bulut platformudur. Kısaca Tarihçe & Bugünkü Kullanım Alanları Git, 2005 yılında Linux Torvalds tarafından Linux çekirdeğinin dağıtık geliştirme ihtiyaçları için tasarlandı. Github, 2008 yılında Tom Preston-Werner, Chris Wanstrath ve PJ Hyett tarafından kuruldu. “Sosyal kodlama” fikrini yaygınlaştırdı: Pull Request kültürü, yıldızlama, takip, Issues/Wiki vs. 2018 yılnda ise Microsoft tarafından satın alındı. Kullanım alanları: Açık kaynak projeler Şirket içi özel depolar Devops / CI-CD Kısaca; Git bir motor, Github ise o otoyol + servis istasyonlarıdır. Git\'in Temel Kavramları Repository (repo) Projenin Git tarafından izlenen kök klasörü. Asıl sihir .git/ klasöründe: commitler, dallar, referanslar, konfigürasyon. Nasıl kullanılır Yeni depo: git init (yerel), git clone (uzak kopya). Varsayılan ana dal: main (eski projelerde master olabilir). Bare repo (sunucu için): git init --bare (çalışma dizini yok; sadece sürüm verisi). Yaygın hatalar Yanlış klasörde git init → gereksiz .git/. Çözüm: .git/ klasörünü sil ya da git -C ile doğru dizinde çalış. Büyük dosyaları commit’lemek → push sıkıntıları. Çözüm: Git LFS. Püf noktaları Proje ayarları: .git/config, global ayarlar: ~/.gitconfig. .gitattributes ile satır sonları, dil-diff ayarları, LFS takibi. Working Directory / Staging Area / Commit Working Directory: Diskteki dosyaların mevcut hali. Staging Area (index): “Bir sonraki commit’te olsun” dediğin anlık görüntü. Commit: Deponun “fotoğrafı”. Nasıl kullanılır Durum: git status Stage’e almak: git add / git add -p (parça parça) Stage’den çıkarmak: git restore --staged Çalışma kopyasını geri almak: git restore Commit: git commit -m \"Özet mesaj\" Son commit’i düzeltmek: git commit --amend Yaygın hatalar Commit’te yanlış dosyalar var → git reset --soft HEAD~1 veya git restore --staged ile toparla. “.gitignore çalışmıyor” → dosya daha önce track edilmiştir. git rm -r --cached . git add . git commit-m \"Honor .gitignore\" Püf noktaları Mesaj standardı: kısa özet (50 karakter civarı) + alt satırlarda detay. İmzalama: git commit -S (GPG/SSH signing) güven arttırır. Branch (Dal) Commit zincirini işaret eden hafif bir işaretçi. HEAD genelde aktif dalı gösterir. Nasıl kullanılır Listele/oluştur/geç: git branch git switch -c feature/api git switch main Birleştir: git merge feature/api Rebase: git rebase main (temiz tarihçe; dikkatli kullan) Yaygın hatalar Karmakarışık tarihçe → merge yerine fazla rebase karmaşası. Ekip standardı belirleyin. Yanlış dala commit → git switch -c dogru/dal ile taşı, gerekirse revert. Püf noktaları İsimlendirme: feat/, fix/, chore/, docs/ gibi önekler. Korunan dallar (Protected branches) ve zorla itmeye kısıt: repo ayarlarından. Remote (Uzak) Uzak barındırıcı (GitHub/GitLab vs.). Genelde origin, açık kaynakta ana depo için upstream. Nasıl kullanılır Ekle/Göster: git remote add origin https://github.com/user/repo.git git remote -v Al/Gönder: git fetch, git pull, git push Yaygın hatalar Kimlik doğrulama: Personal Access Token (HTTPS) ya da SSH anahtarı. SSH test: ssh -T git@github.com “non-fast-forward” push reddi → uzak değişiklikleri önce al: git pull --rebase git push Püf noktaları Tracking branch: git push -u origin main sonrası git push/pull kısa çalışır. --force-with-lease güvenli zorla gönderme: git push --force-with-lease Clone / Pull / Push Clone: Uzak deponun yerel kopyasını oluşturur. Pull: Uzak değişiklikleri alır (fetch + merge/rebase). Push: Yerel commitleri uzağa gönderir. Nasıl kullanılır Hızlı klon: git clone --depth 1 (geçmişin tamamı gerekmezse) Sparse checkout (monorepo seçimli klasör): git sparse-checkout init --cone git sparse-checkout set path/subdir Pull stratejisi: git config pull.rebase false # merge git config pull.rebase true # rebase Yaygın hatalar “Diverged” uyarıları → yanlış strateji karışıklığı. Ekiple netleştir. Büyük push’lar → LFS veya release asset’leri kullan. Püf noktaları git fetch + git log origin/main..HEAD ile göndermeden fark kontrolü. Push politika: ana dala doğrudan push kapat, PR zorunlu kıl. Fork Başkasının reposunun kişisel kopyası. Katkı PR’ı göndermek için kullanılır. Nasıl kullanılır (açık kaynak akışı) Fork butonuna bas. Kendi fork’unu klonla: git clone Orijinali upstream olarak ekle: git remote add upstream https://github.com/orijinal/sahip/repo.git Kendi dalında çalış: git switch -c feat/x Fork’una push et: git push -u origin feat/x GitHub’dan Pull Request aç. Upstream’le senkron kalma git fetch upstream git switch main git merge upstream/main # ya da rebase Ne zaman fork yerine dal? Yazma iznin varsa aynı repo içinde dal açmak daha pratiktir. Pull Request (PR) Değişiklik teklifini tartışma + otomatik kontroller + code review ile birleştirme süreci. Akış Daldan push → GitHub’da “Compare & pull request”. Açıklayıcı başlık/özet, PR template varsa doldur. Reviewer’lar, CI (Actions) çalışır: test/format/lint. Gerekirse “Draft PR”: hazır olmayınca tartışma için. Birleştirme stratejileri: Merge, Squash, Rebase. Yaygın hatalar Dev PR’ı: çok büyük değişiklik → parçalara böl. Test yok → CI kırmızı. Küçük de olsa test/linte yer ver. Püf noktaları Code Owners ile dosya bazlı otomatik reviewer. “Require status checks” + “Require reviews” ile kalite kapıları. “Squash merge” küçük commitleri tek commit yapar; tarihçe temiz olur. Issues / Wiki / Projects / Actions Issues (takip & planlama) Etiketler (labels), atama (assignees), milestone, issue templates. “Good first issue” ve “help wanted” açık kaynak için iyi işaretler. Discussions: soru/öneri → Issue’dan ayrı, forumvari. Wiki (dokümantasyon) Proje kılavuzları, kurulum, mimari, karar kayıtları. Repo ile senkron tut; güncelleme işini PR sürecine dahil et. Projects (kanban/roadmap) Project (v2) ile tablo/pano görünümü, custom field’lar, otomasyon. Issue/PR’ları sütunlara akıt, “In Progress/Done” akışı. Actions (CI/CD otomasyon) YAML ile workflow: tetikleyiciler: push, pull_request, schedule, workflow_dispatch runners: ubuntu-latest vb. secrets: deploy anahtarları, tokenlar. Örnek (Node test): name: CI on: pull_request: push: branches: [ \"main\" ] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: \"20\" - run: npm ci - run: npm test --if-present Yaygın hatalar Secrets’i commit’lemek → asla .env’yi repo’ya koyma; Secrets kullan. Runner cache yanlış kullanımı → build tutarsızlığı; cache key’lerini versiyonla. Püf noktaları Issue/PR şablonları ve otomatik etiketleme (actions) ile akış standardize olur. “Required reviewers”, “auto-merge on green” (testler geçince otomatik merge) ekip hızını korur. Kısaca toparlamak gerekirse basit anlamda komutlar aşağıdaki gibi # repo git init git clone # çalışma alanı / staging / commit git status git add -p git commit -m \"feat: add user login\" git commit --amend # branch git switch -c feat/login git merge feat/login git rebase main # remote git remote add origin git fetch --all git pull --rebase git push --force-with-lease # fork senkronu git remote add upstream git fetch upstream git merge upstream/main # veya rebase