Git Ninja Ol: Güvenli ve Etkili Git Kullanım Rehberi

Proje yönetimi ve kaynak kod kontrolünde sıkça karşılaşılan bir problem, yanlış Git komutları sonucu yaşanan veri kayıpları veya karmaşık geçmişlerdir. Bu rehber, sizi temel Git kullanıcısından, hataları minimuma indiren ve iş akışını hızlandıran gerçek bir Git Ninja’sına dönüştürecek stratejilerle dolu. Hadi, “got got” olmadan, Git dünyasında ustalaşalım!

Yazılım geliştirme dünyasında modern iş akışlarının temel taşı olan Git, projelerinizi yönetmenizi, değişiklikleri takip etmenizi ve ekip üyeleriyle sorunsuz bir şekilde işbirliği yapmanızı sağlayan dağıtık bir versiyon kontrol sistemidir (DVCS). Peki, Git’i bu kadar vazgeçilmez kılan nedir ve temel kavramları nelerdir? Cevabı oldukça basit: Güvenilirlik, esneklik ve hız. Git, her geliştiricinin projenin tam bir geçmişine sahip olmasını sağlayarak, merkezi bir sunucunun çökmesi durumunda bile veri kaybını neredeyse imkansız hale getirir. Bu dağıtık yapı, ekip üyelerinin internet bağlantısı olmasa bile yerel olarak çalışmaya devam edebilmelerine olanak tanır, bu da verimliliği ciddi ölçüde artırır. İşbirliği ise Git’in temelinde yatar; birden fazla geliştiricinin aynı proje üzerinde eş zamanlı ve uyumlu çalışabilmesi, projelerin daha hızlı ilerlemesini sağlar.

Git’e yeni başlayanlar için bilmesi gereken birkaç temel komut ve kavram vardır. Bir projeyi Git ile başlatmak için git init komutunu kullanırız. Bu, mevcut dizini bir Git deposu (repository) haline getirir. Eğer var olan bir projeyi klonlamak istiyorsanız, git clone [repo_url] sizin ilk durağınız olacaktır. Çalışma dizininizdeki değişiklikleri Git’in takip etmesi için önce git add [dosya_adı] veya tüm değişiklikleri eklemek için git add . komutunu kullanırız. Bu işlem, değişiklikleri “sahneleme alanına” (staging area) alır. Ardından, sahnelenmiş değişiklikleri projenin geçmişine kaydetmek için git commit -m "Mesajınız" komutu kullanılır. Commit mesajları, yapılan değişikliğin ne hakkında olduğunu açıklayan kısa ve öz ifadeler olmalıdır. Bu, projenin geçmişine bakıldığında ne zaman neyin değiştiğini anlamak için hayati önem taşır. Git, bir nevi projenizin zaman makinesidir; her commit, projenizin belirli bir anının anlık görüntüsüdür ve istediğiniz zaman bu anlık görüntülere geri dönebilirsiniz. Örneğin, bir web sitesi projesinde çalıştığınızı düşünün. Yeni bir navigasyon menüsü eklediniz ve bu değişiklikleri kaydetmek istiyorsunuz. İlk olarak git add . ile tüm dosyaları sahneleme alanına eklersiniz, ardından git commit -m "Navigasyon menüsü eklendi" ile bu değişikliği kalıcı olarak kaydedersiniz. Bu basit adımlar, proje geçmişinizi düzenli tutmanıza ve olası hatalarda kolayca geri dönmenize olanak tanır. Git ile çalışmaya başlamak, ilk başta karmaşık görünse de, bu temel komutlarla pratik yaparak kısa sürede ustalaşabilirsiniz. Unutmayın, Git sadece bir araç değil, aynı zamanda etkili bir geliştirme iş akışının olmazsa olmaz bir parçasıdır.

Git Akışınızı Nasıl Yönetirsiniz: Dallanma ve Birleştirme Sanatı

Git’in en güçlü ve belki de en çok yanlış anlaşılan özelliklerinden biri dallanma (branching) mekanizmasıdır. Dallanma, bir projenin ana akışından bağımsız olarak yeni özellikler geliştirmek, hataları düzeltmek veya farklı deneysel değişiklikler yapmak için adeta paralel çalışma alanları oluşturmanızı sağlar. Bu sayede ana kod tabanını (“main” veya “master” dalı) riske atmadan güvenle çalışabilirsiniz. Peki, bu dallanma sanatını ustaca nasıl icra ederiz? Öncelikle, yeni bir dal oluşturmak ve ona geçiş yapmak için git checkout -b yeni-ozellik komutunu kullanırız. Bu komut, mevcut dalınızdan bir kopya oluşturur ve sizi doğrudan yeni dala geçirir. Bu, yeni bir özellik üzerinde çalışırken veya bir hata düzeltirken ana daldaki kararlı kodu etkilemeden değişikliklerinizi izole etmenizi sağlar. Dalların adları genellikle açıklayıcı olmalıdır; örneğin, “login-page-refactor” veya “bugfix-checkout-error” gibi.

Bir dal üzerinde çalışmayı tamamladığınızda, yaptığınız değişiklikleri ana dala (genellikle main olarak adlandırılır) geri birleştirmeniz gerekir. Bu birleştirme işlemine “merge” denir. Merge işlemi için önce ana dala geçiş yaparız (git checkout main), ardından oluşturduğumuz özellik dalını ana dalla birleştirmek için git merge yeni-ozellik komutunu kullanırız. Bu noktada, bazen “merge conflict” adı verilen bir durumla karşılaşabiliriz. Bu, aynı dosyanın aynı satırlarında farklı değişiklikler yapıldığında ortaya çıkar ve Git hangi değişikliğin korunacağına otomatik olarak karar veremez. Çatışmaları çözmek, bir Git Ninja’sının en önemli becerilerinden biridir. Çatışma durumunda Git, ilgili dosyalarda hangi kısımların çakıştığını gösteren özel işaretler ekler (örneğin <<<<<<<, =======, >>>>>>>). Bu işaretler arasındaki kodları manuel olarak düzenleyerek, hangi değişikliklerin kalmasını istediğinize karar verirsiniz. Tüm çatışmaları çözdükten sonra dosyayı kaydedip, git add . ve git commit -m "Merge islemi tamamlandi" ile birleştirme işlemini tamamlarsınız.

Gerçek dünya senaryosunda, örneğin bir e-ticaret uygulamasında ödeme sayfasını yenilediğinizi varsayalım. Öncelikle git checkout -b refactor-payment-page ile yeni bir dal oluşturursunuz. Bu dalda ödeme akışını baştan yazarsınız, yeni API entegrasyonları yaparsınız. Tüm bu süreç boyunca, ana dalda başka ekip üyeleri sipariş geçmişi düzeltmeleri veya ürün listesi güncellemeleri üzerinde çalışmaya devam edebilir. İşiniz bittiğinde, ana dala geçip git merge refactor-payment-page komutunu kullanarak, yaptığınız tüm değişiklikleri ana akışa güvenle dahil edersiniz. Eğer bu süreçte bir çatışma yaşanırsa, ilgili kısımları dikkatlice inceleyerek doğru entegrasyonu sağlarsınız. Dallanma ve birleştirme, projelerinizin düzenli, sürdürülebilir ve ekip içinde koordineli bir şekilde ilerlemesini sağlayan temel Git akış yönetimi teknikleridir. Bu tekniklerde ustalaşmak, sizi gerçekten etkili bir Git kullanıcısı yapar.

Temiz Bir Geçmiş Nasıl Oluşturulur: Rebase ve Stash ile Tarihi Yeniden Yazmak

Git, projenizin geçmişini sadece kaydetmekle kalmaz, aynı zamanda bu geçmişi düzenlemenize ve iyileştirmenize olanak tanır. Özellikle takım projelerinde veya herkese açık repolarla çalışırken, temiz ve anlaşılır bir commit geçmişine sahip olmak büyük önem taşır. İşte bu noktada git rebase ve git stash gibi güçlü komutlar devreye girer. Rebase, kelimenin tam anlamıyla bir dalın "tabanını yeniden belirlemek" anlamına gelir. Genellikle, yerel olarak yaptığınız birden fazla küçük ve dağınık commit'i, tek bir anlamlı commit haline getirmek (squash etmek) veya commit mesajlarını düzenlemek için kullanılır. Örneğin, bir özellik üzerinde çalışırken 5-6 tane "Küçük düzeltme", "Hala çalışıyor" gibi commit'ler yapmış olabilirsiniz. Bu commit'leri uzak depoya göndermeden önce tek bir temiz commit'e dönüştürmek, projenin geçmişini çok daha anlaşılır kılar.

İnteraktif rebase (git rebase -i HEAD~N) bu iş için biçilmiş kaftandır. Buradaki N, geriye doğru kaç commit'i düzenlemek istediğinizi belirtir. Bu komutu çalıştırdığınızda, size bir editör penceresi açılır ve burada commit'leri sıralayabilir, silebilir, birleştirebilir veya mesajlarını değiştirebilirsiniz. Örneğin:

git rebase -i HEAD~3

Bu komut, son üç commit'inizi interaktif olarak düzenlemenizi sağlar. Genellikle ilk commit için pick, sonraki commit'ler için ise squash veya fixup komutlarını kullanarak birden fazla commit'i tek bir commit altında birleştirebilirsiniz. Ancak önemli bir uyarı: Ortak kullanılan dallarda (yani zaten uzak depoya itilmiş ve başkaları tarafından çekilmiş dallarda) rebase kullanmaktan kaçınmalısınız. Çünkü rebase, commit ID'lerini değiştirerek başkalarının geçmişiyle uyumsuzluklara yol açabilir. rebase, kendi yerel dalınızı temizlemek için mükemmeldir, ancak paylaşılan dallar için git merge daha güvenli bir seçenektir.

git stash ise, henüz commit etmeye hazır olmadığınız ancak mevcut dalınızdan başka bir dala geçmeniz gereken durumlarda imdadınıza yetişen bir "geçici depolama" aracıdır. Diyelim ki yeni bir özellik üzerinde çalışıyorsunuz, ancak acil bir hata düzeltmesi geldi. Henüz kaydetmeye hazır olmadığınız değişiklikleri kaybetmeden dal değiştirmek için git stash save "Acil hata düzeltmesi öncesi" komutunu kullanabilirsiniz. Bu komut, çalışma dizininizdeki ve sahneleme alanınızdaki tüm değişiklikleri geçici olarak saklar ve çalışma dizininizi temiz bir hale getirir. Hata düzeltmesini bitirip ana dala merge ettikten sonra, eski dalınıza geri dönüp git stash pop ile önceki değişikliklerinizi geri getirebilirsiniz. Bu, iş akışınızı kesintisiz tutarak verimliliğinizi artıran harika bir araçtır.

git stash save "Login butonu tasarimi"
# Başka bir dala geçip acil işi hallet
git checkout main
git pull
git checkout -b bugfix-critical
# Hata düzeltmeleri...
git add .
git commit -m "Kritik hata düzeltildi"
git checkout main
git merge bugfix-critical
# Kendi calistigin dala geri dön
git checkout feature-login
git stash pop

Bu iki komut, Git geçmişinizi hem yerel hem de uzak depoda daha düzenli ve takip edilebilir kılmak için vazgeçilmezdir. Bir Git Ninja'sı olarak, bu araçları ne zaman ve nasıl kullanacağınızı bilmek, sizi karmaşık durumlardan kurtaracaktır.

Ekip Olmak Nasıl Bir Şeydir: Uzak Repolar ve Ortak Çalışma Stratejileri

Git'in gücü, sadece bireysel projeleri yönetme yeteneğinden değil, aynı zamanda birden fazla geliştiricinin aynı proje üzerinde sorunsuz bir şekilde işbirliği yapabilmesinden gelir. Bu ortak çalışmanın kalbinde "uzak depolar" (remote repositories) yer alır. Uzak depolar, genellikle GitHub, GitLab veya Bitbucket gibi platformlarda barındırılan, projenizin merkezi kopyalarıdır. Her ekip üyesi, bu uzak depodan kendi yerel kopyasını (git clone) alır ve değişikliklerini bu merkezi depoya gönderir. Uzak depolarla etkileşim kurmak için git remote, git pull ve git push gibi komutlar kullanılır.

git remote -v komutu, yerel deponuzun hangi uzak depolara bağlı olduğunu görmenizi sağlar. origin genellikle varsayılan uzak depo adıdır. Bir Git Ninja'sının en temel hareketlerinden biri, başkalarının yaptığı değişiklikleri kendi yerel deposuna çekmek için git pull origin main (veya çalıştığınız dala göre) komutunu kullanmaktır. Bu komut, uzak depodaki değişiklikleri hem getirir (fetch) hem de yerel dalınızla birleştirir (merge). Kendi yaptığınız değişiklikleri uzak depoya göndermek için ise git push origin main komutunu kullanırız. Bu, yerel commit'lerinizi diğer ekip üyelerinin erişebileceği hale getirir. Her push yapmadan önce pull yapmak iyi bir alışkanlıktır; böylece uzak depodaki değişikliklerle kendi değişiklikleriniz arasında çakışma olup olmadığını önceden tespit edebilir ve çözebilirsiniz.

Ortak çalışma stratejileri, yani "workflow"lar, ekiplerin projenin büyüklüğüne ve ihtiyaçlarına göre benimsediği yaklaşımlardır. En yaygın olanlardan biri GitHub Flow'dur. Bu akışta, ana dal (main) her zaman deploy edilebilir durumdadır. Her yeni özellik veya hata düzeltmesi için ayrı bir dal oluşturulur. Geliştirme tamamlandığında, bu dal ana dala birleştirilmeden önce bir "çekme isteği" (Pull Request - PR) açılır. PR'lar, diğer ekip üyelerinin kodu incelemesi, yorum yapması ve olası sorunları erken aşamada tespit etmesi için kritik bir mekanizmadır. Kod incelemesi (code review) süreci tamamlanıp onaylandıktan sonra, dal ana dala birleştirilir ve genellikle otomatik olarak üretim ortamına deploy edilir.

Bir vaka analizinde, büyük bir mobil uygulama geliştirme ekibini ele alalım. Ekipteki her geliştirici, kullanıcı profili sayfası, ürün listeleme veya ödeme entegrasyonu gibi farklı bir modül üzerinde çalışır. Herkes kendi özellik dalını oluşturur: git checkout -b feature/profile-page. Geliştirmeler tamamlandığında, değişiklikler yerel olarak test edilir ve uzak depoya git push origin feature/profile-page ile gönderilir. Ardından, bir Pull Request açılır ve diğer ekip üyeleri kodu inceler. Yorumlar ve düzeltmeler yapıldıktan sonra PR onaylanır ve ana dala birleştirilir. Bu sistem, kod kalitesini artırır, hataları minimize eder ve tüm ekibin uyum içinde çalışmasını sağlar. GitFlow gibi daha karmaşık akışlar da mevcuttur, ancak çoğu modern ekip için GitHub Flow'un basitliği ve esnekliği yeterlidir. Bu akışları anlamak ve doğru uygulamak, sizi "got got" olmaktan koruyacak ve başarılı ekip çalışmalarının anahtarı olacaktır.

Git Felaketlerinden Kurtulma: Hataları Geri Alma ve Düzeltme Yöntemleri Nelerdir?

Her Git kullanıcısının başına gelebilecek en korkunç anlardan biri, yanlışlıkla bir hata yapmak ve bu hatayı nasıl geri alacağını bilememektir. Ancak panik yapmaya gerek yok! Git, size bir dizi güçlü "geri alma" ve "düzeltme" aracı sunarak olası felaketlerden kurtulmanızı sağlar. Bir Git Ninja'sı, hata yapmaktan korkmaz; aksine, bu hataları nasıl hızlı ve güvenli bir şekilde düzelteceğini bilir. En sık kullanılan geri alma komutlarından biri git revert'tir. git revert, var olan bir commit'in yaptığı değişiklikleri tersine çeviren yeni bir commit oluşturur. Yani, orijinal commit'i silmek yerine, onun etkisini ortadan kaldıran bir "karşıt commit" yapar. Bu, özellikle ortak kullanılan dallarda, projenin geçmişini değiştirmeden bir hatayı düzeltmek için güvenli bir yöntemdir. Örneğin, bir önceki commit'inizde kritik bir bug bıraktığınızı fark ettiniz:

git log --oneline
# ...
# abcd123 Yanlislikla hata iceren commit
# ...
git revert abcd123

Bu komut, abcd123 commit'inin yaptığı değişiklikleri geri alan yeni bir commit oluşturur ve projenin geçmişini korur.

Daha radikal geri alma işlemleri için git reset komutu kullanılır. git reset, çalışma dizininizi, sahneleme alanınızı ve/veya commit geçmişinizi belirli bir duruma sıfırlamanıza olanak tanır. Üç farklı modu vardır: --soft, --mixed (varsayılan) ve --hard.

• git reset --soft HEAD~1: Son commit'i geri alır, ancak değişiklikleri sahneleme alanında bırakır. Bu, commit mesajını değiştirmek veya commit'e yeni değişiklikler eklemek için kullanışlıdır.
• git reset --mixed HEAD~1: Son commit'i geri alır ve değişiklikleri çalışma dizininizde bırakır (sahneleme alanından da çıkarır). Bu, commit'i tamamen iptal edip değişiklikleri yeniden düzenlemek istediğinizde kullanılır.
• git reset --hard HEAD~1: En tehlikeli olanıdır. Son commit'i tamamen siler ve çalışma dizininizi de o commit'ten önceki haline döndürür. Bu, kaydedilmemiş tüm değişiklikleri ve son commit'i kalıcı olarak sildiği için son derece dikkatli kullanılmalıdır. Yalnızca yerel ve henüz uzak depoya gönderilmemiş değişiklikler için tercih edilmelidir.

Peki ya yanlışlıkla bir dalı sildiyseniz veya bir reset --hard ile önemli değişiklikleri kaybettiyseniz? İşte burada git reflog (reference log) imdadınıza yetişir. git reflog, Git'in yerel deponuzda gerçekleştirdiğiniz tüm HEAD hareketlerini kaydettiği bir güvenlik ağıdır. Bu, yaptığınız her commit, checkout, merge veya rebase işleminin bir kaydını tutar. Kaybettiğinizi düşündüğünüz bir commit'in hash'ini reflog'dan bulup git checkout [hash] ile o duruma geri dönebilir veya git branch kurtarilan-dal [hash] ile yeni bir dal oluşturabilirsiniz.

git reflog
# Output:
# a1b2c3d HEAD@{0}: checkout: moving from old-branch to main
# e4f5g6h HEAD@{1}: commit: Son eklenen ozellik
# ...
git checkout e4f5g6h

Unutmayın, git reflog sadece yerel deponuzda çalışır ve uzak depodaki değişiklikleri kapsamaz. Bir Git Ninja'sı olmak, bu kurtarma komutlarını ne zaman ve nasıl kullanacağını bilmekle başlar. Herhangi bir geri alma işlemi yapmadan önce her zaman dikkatli olun ve özellikle --hard seçeneklerini kullanırken iki kez düşünün.

Bir Git Ninja'sı Olmanın Sırları: Güvenlik ve İleri Düzey İpuçları

Git'in temellerini ve ortak çalışma mekanizmalarını öğrendik. Şimdi sıra, sizi sıradan bir kullanıcıdan gerçek bir Git Ninja'sına dönüştürecek ileri düzey ipuçları ve güvenlik pratiklerinde. Bu bölümde, kodunuzu ve projenizin bütünlüğünü korurken, iş akışınızı daha da optimize edecek tekniklere odaklanacağız. Öncelikle, projenizin hassas bilgilerini Git deposuna yanlışlıkla göndermesini engellemek için .gitignore dosyasının öneminden bahsedelim. API anahtarları, veritabanı şifreleri, log dosyaları, bağımlılık klasörleri (node_modules/, vendor/) veya derlenmiş çıktılar (build/, dist/) gibi dosyaların versiyon kontrolüne dahil edilmemesi hayati önem taşır. Bu dosyaları .gitignore dosyasına ekleyerek, git add . komutuyla bile Git'in bu dosyaları takip etmesini engellemiş olursunuz. Her proje için doğru .gitignore yapılandırması, projenin temiz ve güvenli kalmasının temelidir.

# .gitignore ornegi
node_modules/
.env
*.log
/build/

Güvenlik konusunda bir diğer önemli adım ise commit'lerinizi GPG (GNU Privacy Guard) ile imzalamaktır. Commit imzalama, bir commit'in gerçekten o commit'i yapan kişi tarafından yapıldığını ve üzerinde oynanmadığını kanıtlar. Bu, özellikle açık kaynak projelerde veya yüksek güvenlik gerektiren iş ortamlarında büyük önem taşır. GPG anahtarınızı oluşturup Git ile entegre ettikten sonra, her commit'i git commit -S -m "Imzali commit" komutuyla imzalayabilirsiniz. Böylece projenizin geçmişindeki her commit'in güvenilirliğini doğrulamak mümkün olur.

Git hooks (Git kancaları), Git olayları (örneğin commit, push, merge) tetiklendiğinde otomatik olarak çalışan özel betiklerdir. Bu betikler, kod kalitesini artırmak, testleri otomatikleştirmek veya belirli kod standartlarını zorunlu kılmak için kullanılabilir. Örneğin, pre-commit hook'u, bir commit oluşturulmadan önce kodunuzu biçimlendirebilir veya linting kontrolünden geçirebilir. Bu sayede, kötü biçimlendirilmiş kodların veya basit hataların depoya girmesini engelleyebilirsiniz.

# .git/hooks/pre-commit ornegi
#!/bin/sh
# Linting kontrolü
npm run lint || exit 1
# Testleri calistir
npm test || exit 1

Bir diğer ileri düzey ipucu ise Git alias'larıdır. Sık kullandığınız uzun Git komutları için kısayollar oluşturarak verimliliğinizi artırabilirsiniz. Örneğin, git config --global alias.co checkout ile git checkout yerine git co kullanabilirsiniz.

Son olarak, mobil uyumlu HTML veya genel olarak responsive web geliştirme ile Git'in nasıl birlikte çalıştığına değinelim. Bir web projesi geliştirirken, farklı ekran boyutlarına uygun tasarımlar için medya sorguları (@media kuralları) kullanılır. Git, bu tür CSS dosyalarındaki değişiklikleri ve farklı dallardaki responsive tasarım yaklaşımlarını takip etmek için mükemmeldir. Örneğin, bir geliştirici mobil öncelikli tasarım üzerinde çalışırken başka biri masaüstü görünümünü iyileştirebilir ve Git, bu farklı yaklaşımları dallar aracılığıyla izleyip sorunsuz bir şekilde birleştirebilir.

/* styles.css */
.container {
    width: 90%;
    margin: 0 auto;
}

@media (min-width: 768px) {
    .container {
        width: 70%;
        max-width: 1200px;
    }
    .navigation {
        display: flex;
        justify-content: space-between;
    }
}

@media (max-width: 480px) {
    .container {
        padding: 10px;
    }
    .mobile-menu-button {
        display: block;
    }
}

Bu gibi kod bloklarının Git tarafından sürüm kontrolünde tutulması, responsive tasarım değişikliklerinin geçmişini net bir şekilde görmenizi, farklı sürümler arasında karşılaştırmalar yapmanızı ve gerektiğinde belirli bir duruma geri dönmenizi sağlar. Bu ileri düzey araçları ve güvenlik pratiklerini benimseyerek, projelerinizin daha güvenli, daha düzenli ve daha verimli olmasını sağlarsınız; böylece gerçek bir Git Ninja'sına dönüşürsünüz.

Sonuç: Git Ninja Yolculuğunuz Başlasın ve Sıkça Sorulan Sorular

Bu rehber boyunca, Git'in temel prensiplerinden başlayarak, dallanma ve birleştirme sanatı, geçmişi temizleme teknikleri, ekip içinde sorunsuz işbirliği ve olası felaketlerden kurtulma stratejilerine kadar birçok önemli konuyu ele aldık. Bir Git Ninja'sı olmanın sadece komutları bilmekten ibaret olmadığını, aynı zamanda doğru iş akışlarını benimsemek, güvenlik pratiklerini uygulamak ve sorun çözme yeteneğinizi geliştirmekle ilgili olduğunu gördük. Git, doğru kullanıldığında, yazılım geliştirme sürecinizi inanılmaz derecede hızlandıran ve kolaylaştıran güçlü bir müttefiktir. Artık, projelerinizde karşılaşabileceğiniz herhangi bir Git zorluğunun üstesinden gelmek için gereken bilgi ve becerilere sahipsiniz. Pratik yapmaktan çekinmeyin, farklı komutları deneyin ve her zaman git status ve git log gibi komutlarla deponuzun durumunu kontrol etmeyi alışkanlık haline getirin. Unutmayın, Git'te öğrenme süreci sürekli devam eder ve her yeni proje, yeni bir deneyim sunar. Cesur olun, hata yapmaktan korkmayın ve her hatadan ders çıkararak yolculuğunuza devam edin. Git Ninja yolculuğunuzda bol şans dileriz!

Sıkça Sorulan Sorular

• Git ile GitHub arasındaki fark nedir?

  Git, versiyon kontrol sistemi olarak kullandığımız bir yazılımdır; yerel bilgisayarınızda kod değişikliklerini takip eder. GitHub ise, Git depolarınızı barındırmak için kullanılan bulut tabanlı bir hizmettir. Yani Git bir araç, GitHub ise bu aracı kullanarak kodlarınızı çevrimiçi depolayabileceğiniz ve ekip arkadaşlarınızla paylaşabileceğiniz bir platformdur.

• Merge conflict (birleştirme çatışması) yaşadığımda ne yapmalıyım?

  Merge conflict yaşadığınızda, Git hangi değişikliklerin kalacağına karar veremediği için dosyaları işaretleyecektir. Öncelikle git status ile hangi dosyalarda çatışma olduğunu görün. Ardından, çatışmalı dosyaları bir kod editörüyle açın ve <<<<<<<, =======, >>>>>>> işaretleri arasındaki kodları manuel olarak düzenleyerek istediğiniz nihai versiyonu oluşturun. Tüm çatışmaları çözdükten sonra dosyayı kaydedin, git add . ile değişiklikleri sahneleyin ve git commit ile birleştirme işlemini tamamlayın.

• Yanlışlıkla git push --force kullandım, ne yapabilirim?

  git push --force, uzak depodaki geçmişi değiştirir ve bu oldukça risklidir. Eğer yanlışlıkla kullandıysanız ve başkalarının da o depodan çekim yaptığını düşünüyorsanız, ilk yapmanız gereken ekibinize haber vermektir. Daha sonra, kaybettiğiniz commit'leri yerel git reflog komutunuzdan bularak git reset --hard [kayıp_commit_hash] ile yerel deponuzu o noktaya geri alabilir ve tekrar git push --force ile uzak depoyu düzeltebilirsiniz. Ancak bu işlem, ekipteki herkesin depolarını da senkronize etmesini gerektirecektir.

• Büyük dosyaları Git ile nasıl yönetirim?

  Git, büyük ikili dosyaları (resimler, videolar, derlenmiş çıktılar) verimli bir şekilde yönetmek için tasarlanmamıştır. Bu tür dosyaları Git ile depolamak deponuzun boyutunu şişirir ve performans sorunlarına yol açar. Bunun yerine, Git Large File Storage (Git LFS) gibi araçları kullanmalısınız. Git LFS, büyük dosyaların işaretçilerini Git deposunda tutarken, gerçek dosyaları ayrı bir LFS sunucusunda depolar. Bu, deponuzun hafif kalmasını sağlar ve büyük dosyalarla çalışmayı kolaylaştırır.