Git ve GitHub Başlangıç Rehberi: Amazon Linux 2023 Üzerinde Fork, Branch, Commit ve Pull Request Adım Adım (Walkthrough)
Modern yazılım geliştirme dünyasında ekip çalışması ve kod yönetimi vazgeçilmezdir. Bu süreçte Git ve GitHub gibi araçlar, geliştiricilerin kodlarını verimli bir şekilde yönetmelerini, işbirliği yapmalarını ve projelerinin farklı versiyonlarını takip etmelerini sağlar. Bu rehberde, Amazon Linux 2023 ortamında Git’i kurmaktan başlayarak, GitHub’ın temel iş akışı olan Fork, Branch, Commit ve Pull Request adımlarını uygulamalı olarak ele alacağız. İster yeni başlayan bir geliştirici olun ister mevcut bilginizi tazelemek isteyin, bu kapsamlı rehber size Git ve GitHub dünyasına sağlam bir giriş yapmanızı sağlayacak.
Git ve GitHub Neden Önemli?
Yazılım geliştirme, genellikle birden fazla kişinin aynı kod tabanı üzerinde çalıştığı karmaşık bir süreçtir. Bu ortamda kod çakışmalarını önlemek, değişiklikleri takip etmek ve projenin farklı aşamalarını yönetmek için güçlü araçlara ihtiyaç duyulur. İşte bu noktada Sürüm Kontrol Sistemleri (VCS) ve özellikle Git devreye girer.
Sürüm Kontrol Sistemleri (VCS) Nedir?
Sürüm Kontrol Sistemleri, zaman içinde dosyalarda ve dizinlerde yapılan değişiklikleri yöneten bir sistemdir. Bir VCS kullanarak, projenin herhangi bir noktasındaki geçmiş sürümlerine geri dönebilir, kimin ne zaman ve hangi değişikliği yaptığını görebilir, farklı değişiklikleri birleştirebilir ve potansiyel hataları kolayca düzeltebilirsiniz. Bu sistemler, özellikle ekip projelerinde koordinasyonu artırır ve hataları minimize eder.
Git’in Avantajları
Git, dağıtık bir sürüm kontrol sistemidir (DVCS). Bu, her geliştiricinin projenin tam bir kopyasına sahip olduğu anlamına gelir. Merkezi bir sunucuya bağımlılık olmadan çevrimdışı çalışabilir ve değişiklikleri yerel olarak yapabilirsiniz. Git’in başlıca avantajları şunlardır:
- Hız: Git, büyük projelerde bile çok hızlıdır.
- Dağıtık Yapı: Herkesin projenin tam geçmişine sahip olması, merkezi sunucu arızası durumunda bile veri kaybını önler.
- Güçlü Dallanma ve Birleştirme: Git’in dallanma (branching) modeli oldukça esnektir ve farklı özellikler üzerinde paralel çalışmayı kolaylaştırır.
- Veri Bütünlüğü: Git, kriptografik karma işlevleri kullanarak dosya geçmişinin bütünlüğünü korur.
GitHub’ın Rolü
Git bir sürüm kontrol sistemi iken, GitHub Git depolarını barındıran web tabanlı bir platformdur. GitHub, Git’in sağladığı sürüm kontrol yeteneklerini, sosyal kodlama ve işbirliği özellikleriyle birleştirir. GitHub sayesinde şunları yapabilirsiniz:
- Kod depolarınızı (repository) güvenli bir şekilde barındırabilirsiniz.
- Ekip üyeleriyle kolayca işbirliği yapabilir, kod incelemeleri yapabilir ve Pull Request’ler aracılığıyla değişiklikleri tartışabilirsiniz.
- Açık kaynak projelere katkıda bulunabilir veya kendi projelerinizi dünyaya açabilirsiniz.
- Proje yönetimi için sorun takip (issue tracking) ve proje panoları gibi araçları kullanabilirsiniz.
Ortam Kurulumu: Amazon Linux 2023
Git ve GitHub ile çalışmaya başlamadan önce, geliştirme ortamımızı hazırlamamız gerekiyor. Bu rehberde Amazon Linux 2023 kullanacağız. Amazon Linux 2023, AWS ortamında bulut tabanlı uygulamalar için optimize edilmiş, güvenli ve performanslı bir işletim sistemidir.
Amazon Linux 2023 Nedir?
Amazon Linux 2023, Amazon Web Services (AWS) tarafından sağlanan genel amaçlı bir Linux dağıtımıdır. CentOS Stream, Fedora ve RHEL ile uyumlu paketler sunar. Güvenlik odaklıdır, uzun süreli destek sağlar ve AWS hizmetleriyle sorunsuz entegrasyon sunar. Genellikle EC2 örnekleri üzerinde kullanılır.
Git Kurulumu
Amazon Linux 2023’te Git kurulumu oldukça basittir. Terminalinizi açın ve aşağıdaki komutları çalıştırın:
sudo dnf update -y
sudo dnf install git -y
Kurulum tamamlandıktan sonra, Git'in doğru şekilde kurulup kurulmadığını ve hangi sürümün yüklü olduğunu kontrol edebilirsiniz:
git --version
Şimdi Git'i yapılandırmamız gerekiyor. Bu, yaptığınız commit'lerin kim tarafından yapıldığını gösteren bilgileri ayarlamak içindir. Bu bilgiler her commit ile birlikte kaydedilir:
git config --global user.name "Adınız Soyadınız"
git config --global user.email "eposta@adresiniz.com"
Bu bilgileri doğru girdiğinizden emin olun, çünkü GitHub'da bu bilgilerle eşleşen kullanıcı adınız ve e-posta adresiniz olması, katkılarınızın doğru şekilde ilişkilendirilmesini sağlar.
SSH Anahtarı Oluşturma (Önerilir)
GitHub ile güvenli ve parola girmeden etkileşim kurmak için SSH anahtarları kullanmak iyi bir pratiktir. Bu adım isteğe bağlıdır ancak şiddetle tavsiye edilir.
- SSH anahtarı oluşturma: Terminalde aşağıdaki komutu çalıştırın. E-posta adresinizi kendi e-posta adresinizle değiştirin.
- SSH agent'ı başlatma:
- SSH anahtarınızı agent'a ekleme:
- Genel anahtarınızı (public key) kopyalama: Genel anahtarınızı GitHub hesabınıza eklemeniz gerekecek.
- GitHub'a anahtarı ekleme: GitHub hesabınıza giriş yapın. Sağ üst köşedeki profil resminize tıklayın, Settings -> SSH and GPG keys bölümüne gidin. New SSH key butonuna tıklayın, bir başlık (örneğin "Amazon Linux 2023") girin ve kopyaladığınız anahtarı "Key" alanına yapıştırın. Ardından Add SSH key butonuna tıklayın.
ssh-keygen -t ed25519 -C "eposta@adresiniz.com"
Bu komut size bir parola girmenizi isteyecektir. Güvenlik için bir parola belirleyebilirsiniz, ancak boş bırakırsanız her kullanımda parola sormaz. Anahtar, genellikle ~/.ssh/id_ed25519 ve ~/.ssh/id_ed25519.pub yollarına kaydedilir.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
cat ~/.ssh/id_ed25519.pub
Bu komutun çıktısını kopyalayın.
GitHub Üzerinde Proje Akışı: Fork ve Clone
Artık Git'i kurup yapılandırdığımıza göre, GitHub üzerindeki bir projeyi yerel ortamımıza nasıl alacağımızı ve üzerinde nasıl çalışmaya başlayacağımızı görelim.
Fork İşlemi Nedir ve Neden Yapılır?
Bir projeyi "fork etmek", o projenin kendi GitHub hesabınızda tamamen bağımsız bir kopyasını oluşturmaktır. Genellikle açık kaynak projelere katkıda bulunmak istediğinizde veya bir projenin üzerinde kendi değişikliklerinizi yapmak istediğinizde fork işlemi yapılır. Fork ettiğiniz depo (repository), orijinal depodan bağımsızdır, ancak orijinal depoyla senkronize edilebilir.
Neden fork yapılır?
- Orijinal projeye doğrudan yazma izniniz olmadığında değişiklik yapmak için.
- Kendi projenizin temelini oluşturmak için.
- Orijinal projeye bir özellik eklemek veya bir hata düzeltmesi önermek için (Pull Request göndermek amacıyla).
Bir Depoyu Fork Etme
GitHub üzerinde bir depoyu fork etmek oldukça basittir:
- GitHub'da fork etmek istediğiniz depoya gidin. Örneğin,
github.com/octocat/Spoon-Knifedeposunu kullanabiliriz. - Sağ üst köşede bulunan Fork butonuna tıklayın.
- GitHub size depoyu nereye fork etmek istediğinizi soracaktır (genellikle kendi hesabınız). Onaylayın.
- Kısa bir süre sonra, deponun kendi hesabınızda bir kopyası oluşacaktır (örneğin,
github.com/SizinKullanıcıAdınız/Spoon-Knife).
Depoyu Yerel Ortama Klonlama
Fork ettiğiniz depoyu artık yerel Amazon Linux 2023 makinenize klonlayabilirsiniz. Klonlama, uzak depodaki tüm dosya ve geçmişi yerel diskinize indirme işlemidir.
- Kendi fork ettiğiniz deponun GitHub sayfasına gidin (örneğin,
github.com/SizinKullanıcıAdınız/Spoon-Knife). - <> Code butonuna tıklayın.
- SSH sekmesini seçin (eğer SSH anahtarı kurduysanız). Kopyala butonuna tıklayarak SSH URL'sini kopyalayın (örneğin,
git@github.com:SizinKullanıcıAdınız/Spoon-Knife.git). - Terminalinizde, projeyi kaydetmek istediğiniz dizine gidin ve aşağıdaki komutu çalıştırın:
- Klonlama tamamlandığında, yeni bir dizin (
Spoon-Knife) oluşturulacak ve tüm proje dosyaları bu dizine indirilecektir. Bu dizine girin:
git clone git@github.com:SizinKullanıcıAdınız/Spoon-Knife.git
cd Spoon-Knife
Artık projenin yerel bir kopyasına sahipsiniz ve üzerinde çalışmaya başlayabilirsiniz.
Geliştirme Süreci: Branch ve Commit
Bir projeye katkıda bulunurken veya kendi projenizi geliştirirken, doğrudan ana (main) dal üzerinde çalışmak genellikle kötü bir pratiktir. Bunun yerine, yeni özellikler veya hata düzeltmeleri için ayrı dallar (branch) oluşturmak ve bu dallar üzerinde çalışmak en iyi yaklaşımdır.
Branch (Dal) Kavramı
Bir "branch", projenin ana geliştirme hattından ayrılan bağımsız bir geliştirme yoludur. Her dal, projenin o anki durumunun bir kopyasıdır. Bu, farklı özellikler üzerinde aynı anda, birbirlerini etkilemeden çalışmanıza olanak tanır. Bir dal üzerindeki değişiklikler, siz açıkça birleştirene kadar diğer dalları etkilemez.
Örneğin, bir web uygulaması üzerinde çalışıyorsunuz ve hem yeni bir ödeme özelliği eklemek hem de mevcut bir hatayı düzeltmek istiyorsunuz. Bu durumda, ödeme özelliği için bir dal ve hata düzeltmesi için başka bir dal oluşturabilirsiniz. Her iki işi de paralel olarak yapabilir, test edebilir ve bittiğinde ana dala birleştirebilirsiniz.
Yeni Bir Dal Oluşturma ve Geçiş Yapma
Öncelikle, hangi dalda olduğunuzu kontrol edelim:
git branch
Genellikle * main veya * master çıktısını görürsünüz, bu da ana dalda olduğunuzu gösterir.
Yeni bir dal oluşturmak ve doğrudan o dala geçmek için aşağıdaki komutu kullanırız:
git checkout -b ozellik/yeni-ozellik
Burada ozellik/yeni-ozellik, yeni dalımızın adıdır. Dal adlarını açıklayıcı ve hiyerarşik tutmak iyi bir pratiktir (örneğin, feature/login-page, bugfix/footer-alignment).
Tekrar dalları kontrol ettiğinizde, artık yeni dalda olduğunuzu göreceksiniz:
git branch
# main
#* ozellik/yeni-ozellik
Değişiklik Yapma ve Staging Alanı
Şimdi yeni dalımızda bazı değişiklikler yapalım. Klonladığınız Spoon-Knife dizininde, yeni bir dosya oluşturalım veya mevcut bir dosyayı düzenleyelim. Örneğin, README.md dosyasını düzenleyebilir veya yeni-dosya.txt adında bir dosya oluşturabiliriz.
echo "Bu benim yeni özelliğim için eklediğim bir satır." >> README.md
nano yeni-dosya.txt # İçine bir şeyler yazıp kaydedin
Değişiklikleri yaptıktan sonra, Git'in bu değişiklikleri fark ettiğini görebilirsiniz:
git status
Çıktıda, değiştirilen veya yeni oluşturulan dosyaların "Untracked files" veya "Changes not staged for commit" başlığı altında listelendiğini göreceksiniz. Bu dosyaları bir sonraki commit'e dahil etmek için "staging area"ya (hazırlık alanı) eklememiz gerekir:
git add README.md yeni-dosya.txt
Tüm değiştirilen dosyaları eklemek için ise:
git add .
Şimdi git status komutunu tekrar çalıştırdığınızda, dosyaların "Changes to be committed" başlığı altında olduğunu göreceksiniz.
Değişiklikleri Kaydetme (Commit)
Staging alanına eklediğiniz değişiklikleri kalıcı olarak projenin geçmişine kaydetmek için "commit" işlemi yaparız. Her commit, yapılan değişiklikleri ve bu değişikliklerin ne anlama geldiğini açıklayan bir mesaj içerir.
git commit -m "Yeni bir özellik eklendi ve README güncellendi"
Commit mesajları açıklayıcı ve kısa olmalıdır. Genellikle ilk satırda kısa bir özet, ardından boş bir satır ve daha detaylı bir açıklama kullanılır (ancak tek satırlık mesajlar da yaygındır).
Commit'i yaptıktan sonra, değişiklikleriniz artık yerel deponuzun geçmişine kaydedilmiştir.
Değişiklikleri Uzak Depoya Gönderme ve Senkronizasyon
Yerel deponuzdaki değişiklikleri GitHub'daki fork'unuza göndermenin ve orijinal depoyla senkronize kalmanın zamanı geldi.
Değişiklikleri Push Etme
Yerel commit'lerinizi GitHub'daki fork'unuza göndermek için git push komutunu kullanırız:
git push origin ozellik/yeni-ozellik
Burada:
origin, GitHub'daki fork'unuzun varsayılan uzak adıdır.ozellik/yeni-ozellik, yerel olarak üzerinde çalıştığınız dalın adıdır.
Eğer bu dalı ilk kez push ediyorsanız, Git size aşağıdaki gibi bir komut önerebilir:
git push --set-upstream origin ozellik/yeni-ozellik
Bu komut, yerel dalınız ile uzak depodaki dal arasında bir bağlantı kurar, böylece sonraki git push ve git pull komutlarında dal adını belirtmenize gerek kalmaz.
Değişiklikleri push ettikten sonra, GitHub'daki fork'unuzun sayfasına gittiğinizde, yeni dalınızın ve yaptığınız commit'in orada göründüğünü fark edeceksiniz.
Ana Depo ile Senkronizasyon (Upstream)
Orijinal depoda (fork ettiğiniz depo) yeni değişiklikler yapılmış olabilir. Kendi fork'unuzu ve yerel deponuzu bu değişikliklerle güncel tutmak önemlidir. Bunun için "upstream" adı verilen bir uzak depo eklememiz gerekir.
- Orijinal depoyu uzak olarak ekleme: Klonladığınız dizinde olduğunuzdan emin olun.
- Uzak depoları kontrol etme:
- Upstream'den değişiklikleri çekme: Ana dala geçin ve upstream'den değişiklikleri getirin.
- Değişiklikleri birleştirme: Getirdiğiniz değişiklikleri yerel
maindalınıza birleştirin.
git remote add upstream https://github.com/octocat/Spoon-Knife.git
Buradaki URL'yi fork ettiğiniz orijinal deponun URL'si ile değiştirin. Eğer SSH kullanıyorsanız: git@github.com:octocat/Spoon-Knife.git
git remote -v
# origin git@github.com:SizinKullanıcıAdınız/Spoon-Knife.git (fetch)
# origin git@github.com:SizinKullanıcıAdınız/Spoon-Knife.git (push)
# upstream https://github.com/octocat/Spoon-Knife.git (fetch)
# upstream https://github.com/octocat/Spoon-Knife.git (push)
git checkout main
git fetch upstream
git merge upstream/main
Bu adımlar, yerel main dalınızı orijinal deponun main dalıyla senkronize eder. Daha sonra kendi fork'unuzun main dalını da güncelleyebilirsiniz:
git push origin main
İşbirliği ve Kod İncelemesi: Pull Request
Değişikliklerinizi kendi fork'unuza push ettikten sonra, bu değişiklikleri orijinal projeye dahil etmek için bir Pull Request (PR) oluşturursunuz. Pull Request, projenin bakımcılarına "Ben bu değişiklikleri yaptım, lütfen bunları ana depoya birleştirir misiniz?" demenin resmi yoludur.
Pull Request (PR) Nedir?
Pull Request, bir projenin geliştiricilerine kendi dalınızdaki değişiklikleri ana dala (genellikle main veya master) birleştirmeyi önermenizi sağlayan bir mekanizmadır. Bir PR açtığınızda, GitHub diğer geliştiricilerin kodunuzu incelemesi, yorum yapması, test etmesi ve onaylaması için bir arayüz sağlar. Bu, kod kalitesini artırmak ve hataları erken yakalamak için kritik bir adımdır.
Pull Request Oluşturma
Kendi fork'unuzdaki dalı GitHub'a push ettikten sonra, bir Pull Request oluşturmak için aşağıdaki adımları izleyin:
- GitHub'daki kendi fork'unuzun sayfasına gidin (örneğin,
github.com/SizinKullanıcıAdınız/Spoon-Knife). - Genellikle, yeni push ettiğiniz dalı gösteren sarı bir banner veya "Compare & pull request" butonu görürsünüz. Bu butona tıklayın. Eğer görmüyorsanız, Pull requests sekmesine gidip New pull request butonuna tıklayın.
- Açılan sayfada, base repository (temel depo) olarak orijinal depoyu (örneğin,
octocat/Spoon-Knife) ve head repository (kaynak depo) olarak kendi fork'unuzu seçin. - compare kısmında ise, değişikliklerinizi içeren dalı (örneğin,
ozellik/yeni-ozellik) seçin. - GitHub, iki dal arasındaki değişiklikleri size gösterecektir. Her şey yolundaysa, Create pull request butonuna tıklayın.
- Bir başlık ve açıklama ekleyin. Başlık, değişikliklerin kısa bir özetini içermelidir. Açıklama ise neden bu değişiklikleri yaptığınızı, neyi çözdüğünü veya hangi özelliği eklediğini detaylandırmalıdır.
- Create pull request butonuna tekrar tıklayarak PR'ı oluşturun.
PR'ınız artık açık ve projenin bakımcıları tarafından incelenmeyi bekliyor.
Kod İncelemesi ve Birleştirme (Merge)
Pull Request'i oluşturduktan sonra, projenin bakımcıları ve diğer katkıda bulunanlar kodunuzu inceleyebilirler. Bu süreçte şunlar olabilir:
- Yorumlar: Kodunuzda iyileştirilebilecek yerler veya sorular hakkında yorumlar alabilirsiniz.
- Değişiklik İstemleri: Bakımcılar, PR'ınızın birleştirilebilmesi için belirli değişiklikler yapmanızı isteyebilirler. Bu durumda, yerel dalınızda istenen değişiklikleri yapın, commit edin ve tekrar push edin. PR otomatik olarak güncellenecektir.
- Testler: Otomatik testler çalıştırılabilir ve sonuçları PR sayfasında görüntülenebilir.
- Onay: Yeterli inceleme ve testlerden sonra, bir veya daha fazla bakımcı PR'ınızı onaylayacaktır.
PR onaylandıktan sonra, projenin bakımcısı Merge pull request butonuna tıklayarak değişikliklerinizi orijinal deponun ana dalına birleştirebilir. Birleştirme tamamlandığında, dalınızı (ozellik/yeni-ozellik) GitHub üzerinden silebilirsiniz, çünkü değişiklikler artık ana dalın bir parçasıdır.
Sonuç
Bu kapsamlı rehberde, Amazon Linux 2023 üzerinde Git'i kurmaktan başlayarak, GitHub'ın temel iş akışı olan Fork, Branch, Commit ve Pull Request adımlarını adım adım ele aldık. Artık bir projeyi nasıl fork edeceğinizi, yerel ortamınıza nasıl klonlayacağınızı, yeni bir dalda nasıl değişiklik yapacağınızı, bu değişiklikleri nasıl commit edip kendi fork'unuza push edeceğinizi ve son olarak bu değişiklikleri ana projeye bir Pull Request olarak nasıl sunacağınızı biliyorsunuz. Bu temel bilgilerle, hem kendi projelerinizde daha verimli çalışabilir hem de açık kaynak topluluğuna katkıda bulunabilirsiniz. Git ve GitHub, modern yazılım geliştirmenin temel taşlarıdır ve bu araçlara hakim olmak kariyerinizde size önemli avantajlar sağlayacaktır. Pratik yapmaya devam edin ve keşfetmekten çekinmeyin!
SSS (Sık Sorulan Sorular)
Git ve GitHub arasındaki fark nedir?
Git, yerel bilgisayarınızda çalışan bir sürüm kontrol sistemidir. Dosyalarınızdaki değişiklikleri takip etmenizi, farklı sürümler arasında geçiş yapmanızı ve değişiklikleri birleştirmenizi sağlar. GitHub ise, Git depolarını barındıran web tabanlı bir hizmettir. Git ile yaptığınız değişiklikleri uzak bir sunucuda depolamanıza, ekip üyeleriyle işbirliği yapmanıza ve açık kaynak projelerde yer almanıza olanak tanır.
Neden branch kullanmalıyım?
Branch'ler, ana kod tabanından izole bir şekilde yeni özellikler geliştirmek veya hataları düzeltmek için kullanılır. Bu, ana projenin kararlılığını korurken birden fazla geliştiricinin aynı anda farklı görevler üzerinde çalışmasına olanak tanır. Değişiklikler tamamlandığında ve test edildiğinde, güvenli bir şekilde ana dala birleştirilebilir.
git pull ile git fetch arasındaki fark nedir?
git fetch, uzak depodaki tüm değişiklikleri yerel deponuza indirir ancak yerel çalışma dizininizi veya dallarınızı güncellemez. Sadece neyin değiştiğini görmenizi sağlar. git pull ise, hem git fetch işlemini yapar hem de indirilen değişiklikleri mevcut yerel dalınızla otomatik olarak birleştirir (merge). Genellikle git pull, git fetch ve ardından git merge komutlarının birleşimidir.
Bir Pull Request reddedilirse ne yapmalıyım?
Pull Request'inizin reddedilmesi durumunda, genellikle bakımcılardan neden reddedildiğine dair geri bildirim alırsınız. Bu geri bildirimleri dikkatlice inceleyin, gerekli değişiklikleri yerel dalınızda yapın, commit edin ve tekrar push edin. PR'ınız otomatik olarak güncellenecektir. Ardından, bakımcılarla iletişime geçerek değişikliklerinizi tekrar gözden geçirmelerini isteyebilirsiniz. İletişim ve işbirliği bu süreçte anahtardır.
main dalına doğrudan commit yapmak neden kötü bir pratik?
main dalına doğrudan commit yapmak, projenin kararlılığını riske atar. Doğrudan yapılan değişiklikler test edilmeden veya incelenmeden canlı koda geçebilir, bu da hatalara ve bozuk bir uygulamaya yol açabilir. Ayrıca, ekip ortamlarında kod çakışmalarına neden olabilir ve yapılan değişikliklerin izlenmesini zorlaştırır. Branch'ler, bu tür sorunları önlemek için güvenli bir geliştirme ortamı sunar.