Versiyon Kontrolleri: Git ve GitHub Eğitimi Notları

Merhabalar 👋🏻 Veri Yapıları ve Algoritmalar serisine bir es verip hemen BTK Akademi’den Atıl Samancıoğlu’nun verdiği Versiyon Kontrolleri: Git ve GitHub eğitiminden aldığım notları sizlerle paylaşmak istedim🗒️🌟

Eğitimin tamamına ulaşmanız için linki buraya bırakıyorum ⤵️

️🔗 https://www.btkakademi.gov.tr/portal/course/versiyon-kontrolleri-git-ve-github-19439

Bu yazıyı, Muhammed Mustafa (muffafa) Savar ile birlikte kaleme alığımızı da önemle belirtmek isterim 💟

Artık başlayabiliriz 🫱🏻‍🫲🏻Keyifli Okumalar 🦥

Git Nedir ? Git bir versiyon kontrol sistemidir (VCS). Yani projelerimiz üzerinde çalışırken kodlarımızın sürümlerini kaydetmemizi ve bu sürümleri takip etmemizi sağlayan bir araçtır. Git sayesinde kodu güvenli bir şekilde değiştirebilir, önceki versiyonlara dönebilir ve ekip arkadaşlarımızla kolayca işbirliği yapabiliriz. Böylece projede yaptığımız değişiklikler kayıt altında olur ve istediğimiz zaman geri alabiliriz.

GitHub Nedir?

GitHub, Git versiyon kontrol sistemi içeren projelerimizi barındırmak, paylaşmak ve üzerinde işbirliği yapmak için kullandığımız bir platformdur.

Peki ne yapabiliriz GitHub’da?

• Kod Deposu: Projelerimizi GitHub üzerindeki “repository” (depo) alanında saklarız 🗄️
• İşbirliği: Ekibimizle birlikte aynı projede çalışarak yapılan değişiklikleri izleyebiliriz 🤝
• Sürüm Kontrolü: Kodlarımızın geçmiş versiyonlarını saklayarak gerektiğinde geri dönme imkanı sunar 🔄
• Açık Kaynak: Projelerimizi açık kaynak olarak paylaştığımızda, diğer insanlar da katkıda bulunabilir veya inceleyebilir 🌍
• Kod İnceleme: Kod değişikliklerini gözden geçirebilir, geri bildirim verebilir ve onaylayabiliriz 👀
• Sorun Takibi: Projeyle ilgili hataları veya görevleri “issues” kullanarak izleyebiliriz 🛠️
• Sürekli Entegrasyon: GitHub Actions ile otomatik testler ve dağıtım işlemleri yapabiliriz⚙️
• Wiki: Projemizle ilgili kapsamlı dokümantasyonlar ve rehberler oluşturabiliriz 📚 GitHub Wiki Dokümantasyonu
• Proje Yönetimi: Görevleri organize etmek ve ilerlemeyi izlemek için “Projects” veya “Boards” kullanabiliriz 📊
• Güvenlik: GitHub, projelerimizdeki güvenlik açıklarını tespit etmemize ve düzeltmemize yardımcı olur. Dependabot kütüphanelerdeki zafiyetleri tarar ve güncellemeler önerir. GitHub Advanced Security ile kod analizleri yaparak güvenlik açıklarını proaktif olarak bulabiliriz. Böylece projelerimizi ve kullanıcılarımızı siber tehditlere karşı koruma altına alabiliriz 🛡️

GitHub, projelerimizi daha düzenli bir şekilde geliştirmemizi ve toplulukla etkileşimde bulunmamızı sağlayan güçlü bir araçtır.

NOT: Git ve GitHub alanın tek örnekleri değillerdir fakat çoğunlukla bu iki araç kullanılmaktadır🌐

Git ve GitHub farkına baktığımıza göre Git’e detaylıca bakalım 👇🏻

Git versiyon kontrol sistemini Git Bash üzerinden komutlar ile kontrol edebiliriz. O zaman gelin bakalım bu komutlar neymiş ve ne işe yarıyorlarmış⭐

Not: Başında ‘git’ bulunmayan komutlar sadece Git Bash’de değil Linux tabanlı terminallerde çalışmaktadır 🐧

• ls konumdaki dosyaları listeler.
• ls -la komutu, gizli dosyalar dahil tüm dosyaları listeler.
• pwd içinde bulunduğumuz dizini verir.
• cd [klasör_ismi] komutuyla belirtilen klasöre gireriz.
• cd .. bir önceki klasöre geri dönmemizi sağlar.
• clear komutu ekrandaki komutları temizler.
• mkdir [klasör_ismi](make directory) klasör oluşturmak için kullanılır.
• touch [dosya_adi.uzanti]komutu dosya oluşturmamızı sağlar.
• rm (remove) dosyaları kaldırır. Örnek: rm notlar.txt (dosyayı siler).
• rm -rf [klasör] klasörü siler.
• git --help ile Git hakkında yardım alabiliriz.
• git --version ile yüklü olan Git sürümünü görebiliriz.
• git config --global user.name "[kullanıcı_adı]" kullanıcı adımızı değiştirmek için kullanılır.
• git config --global user.email "[e_mail]" ile e-posta adresimizi değiştirebiliriz.
• git config user.name ile mevcut kullanıcı adını, git config user.email ile mevcut e-postamızı görebiliriz.
• git status belgenin Git ile bağlantı durumunu gösterir.
• git init (initiate = başlatmak), klasörü Git'e bağlamak ve içindekileri takip etmek için kullanılır.
• git add [dosya_adı] komutu, commit edilecek dosyaları hazırlar.

Not: git init komutunu kullanmadan önce git status ile Git durumunu kontrol etmeliyiz. Eğer zaten Git’e bağlanmış bir klasör olabilir ve tekrar init yapmak karışıklıklara neden olabilir.

↪️Yanlış klasörde Git projesi oluşturduğumuzda, rm -rf .git komutuyla Git versiyon kontrol sistemini bu klasörden kaldırabiliriz.

Commit Nedir? 💭

Commit, yapılan değişikliklerin kaydedilmesi anlamına gelir ve Git’te belirli bir adıma not bırakmak gibidir 📝 Her commit, yapılan değişiklikleri kaydeder ve bu değişiklikler hakkında kısa bir açıklama (mesaj) eklenir.

commit mesajları

Yazını geri kalanını daha iyi anlayabilmek adına Git terimlerine bir bakalım hızlıca:

Index (Staging Area): — Tanım: Çalışma dizinindeki (working directory) değişikliklerin commit’e eklenmeden önce hazırlandığı yerdir. Yani, değişiklikleri commit’lemek üzere hazırladığınız ara alan olarak düşünülebilir. — İşlev: git addkomutuyla çalışma dizinindeki dosyaları index’e ekleyebilirsiniz. Index, bir sonraki commit’te hangi değişikliklerin yer alacağını belirler.

Working Directory (Çalışma Dizini): — Tanım: Git repository’sinde mevcut olarak üzerinde çalıştığınız dosyaların bulunduğu yer. Yani, dosyalarınızı düzenlediğiniz ve yeni dosyalar eklediğiniz alan. — İşlev: Çalışma dizinindeki değişiklikler, commit edilmeden önce index’e eklenmelidir.git statuskomutu ile çalışma dizinindeki değişiklikleri görebilirsiniz.

Local Repository (Yerel Repository): — Tanım: Bilgisayarınızda bulunan Git repository’sidir. Çalışma dizini ve index’in yanı sıra commit geçmişinizi ve tüm branch’leri içerir. — İşlev: Yerel repository’nizdeki değişiklikleri commit edebilir ve branch’leri yönetebilirsiniz. Yerel değişiklikleriniz, uzak (remote) repository’e gönderilmeden önce yerel repository’nizde saklanır.

Remote Repository (Uzak Repository): — Tanım: İnternet veya bir ağ üzerindeki başka bir bilgisayarda bulunan Git repository’sidir. Genellikle, projede birlikte çalışan ekip üyeleriyle paylaşım amacıyla kullanılır. — İşlev: Değişikliklerinizi uzak repository’ye gönderir (git push) ve uzak repository’den değişiklikleri alır (git pull). Uzak repository, projedeki ortak çalışmaların merkezi noktasıdır.

Özetle:

• Index: Commit için hazırlanan değişiklikler.
• Working Directory: Üzerinde çalıştığınız dosyalar. - Local Repository: Kendi bilgisayarınızdaki repository.
• Remote Repository: İnternetteki veya ağ üzerindeki başka bir bilgisayarda bulunan repository.

Untracked File Nedir?

Untracked file, Git tarafından izlenmeyen dosyalardır. Bu dosyalar henüz git add ile eklenmemiş ve commit edilmemiş dosyalardır.

git commit -m "[mesaj]" komutuyla daha önce git add komutu ile stage’ e aldığımız dosyalarımızı commit ederiz ve versiyon değişikliklerini kaydederiz. Commit mesajı eklememiz zorunludur çünkü bu mesaj yapılan değişiklikleri özetler.

Commit Mesajını Unutursak Ne Olur ? 🤷🏻‍♀️

Eğer commit mesajını unutur ve sadece git commit yazarsak, bir dosya açılır ve buraya commit mesajını yazmamız gerekir. Mesajı yazıp dosyayı kaydettikten sonra, terminalde Vim Editörü açılabilir. Buradan çıkmak için :q yapmamız yeterlidir.

Yani commit mesajı yazmadan kurtulamıyoruz :(

▶️ git log komutu, projede yapılan değişikliklerin geçmişini gösterir.

Örnek:

$ git log commit f8433fce2b8b72211599338a1be76aefbabf3aff (HEAD -> main) 
Author: Sudenaz Kalaycık <sudenazkalaycik@gmail.com> 
Date:   Sun Aug 18 19:10:55 2024 +0300      
ilkdefter.txt ve ornek.dart dosyaları oluşturuldu.

Burada her commit, belirli bir hash kodu ile temsil edilir. Bu hash kodları geçmişteki bir commit’e dönebilmemizi sağlar. Commitler arttıkça git log çıktısı da artar. Bu yüzden terminalde gezinme tuşları ile hareket etmemiz gerekebilir ve bu gezinmeden çıkabilmek için yine :q kullanırız🏃🏻‍➡️

Tüm Dosyaları Eklemek:

git add .: — Geçerli dizindeki ve tüm alt dizinlerdeki tüm değişiklikleri (yeni, değiştirilmiş ve silinmiş dosyalar) stage’ler. —.gitignoretarafından göz ardı edilen izlenmeyen dosyaları stage’lemez.

git add -a: — Tüm repository’deki (deponun tamamı) tüm değişiklikleri stage’ler (yeni, değiştirilmiş ve silinmiş dosyalar). — git add --all ile eşdeğerdir.

git add -u: — Sadece değiştirilmiş ve silinmiş dosyaları stage’ler, ancak yeni (izlenmeyen) dosyaları stage’lemez. — Mevcut dosyaların değişikliklerini commit’leyip yeni dosyaları eklemek istemediğinizde kullanışlıdır.

git add <file>: — Sadece belirtilen dosyayı veya dosyaları stage’ler. — Belirli değişiklikleri seçerek stage’lemek istediğinizde kullanılır.

Not: git add . sadece geçerli dizin ve alt dizinler için geçerlidir, oysa git add -a tüm repository için geçerlidir.

Bu seçenekler, commit’ten önce hangi değişiklikleri stage’lemek istediğinize bağlı olarak kullanılır.

.gitignore Dosyası Nedir? 👀

Gizli dosyalar ya da projenin repoya dahil edilmemesi gereken dosyalarını hariç tutmak için .gitignore dosyası kullanırız. .gitignore dosyasının içine Git tarafından izlenmemesini istediğimiz dosya ismini, klasör ismini ve dosya uzantılarını ekleyebiliriz 🔐

projenin .gitignore dosyası

• .gitignore dosyasına, takip etmek istemediğimiz dosyaları eklediğimizde Git bu dosyaları görmezden gelir ve versiyon kontrolüne dahil etmez.
• .gitignore dosyasına klasör eklemek için klasörIsmi/ şeklinde yazabiliriz.
• Aynı uzantıdaki tüm dosyaları gizlemek için *.uzantı şeklinde ekleme yapabiliriz.

➡️Bu dosyayı sadece önemli dosyalarız gizlemek için kullanmayız.

.gitignore Kullanım Amaçları:

👀 Gereksiz dosyaları hariç tutmak.

👀 Depolama boyutunu küçültmek.

👀 Hassas bilgilerin gizliliğini sağlamak.

👀 Çatışmaları önlemek.

Örnek Gitignore Dosyaları:

Farklı yazılım dillerinde .gitignore dosyası şablonları bulmak için "gitignore template [dil]" şeklinde arama yaparsak örnek şablonlar karşımıza çıkacaktır. Örnek:

Python .gitignore

Aşağıdaki bağlantıda tüm yazılım dilleri için .gitignore örneklerini bulabilirsiniz ⤵️ 🔗 https://github.com/github/gitignore/tree/main

Branch (Dal) Nedir?

Bir projede aynı anda farklı çalışmalar yapmak veya ekip halinde çalışmak için branch (dal) kullanılır. Böylece farklı kişiler aynı projede, aynı kod üzerinde bağımsız olarak çalışabilir.

Ana kısım (main/master) mavi, branchler ise mor ve yeşil ile gösterilmiştir.

Branch Ne İşe Yarar?

Branch’ler, projede yeni bir özellik eklemek veya değişiklik yapmak istediğimizde kullandığımız bir yöntemdir. Ana projeyi bozmadan, ayrı bir kopya üzerinde çalışmamızı sağlar. İşimiz bittiğinde bu değişiklikleri ana projeye ekleyebilir ya da gerekirse silebiliriz. Bu sayede projeyi düzenli ve güvenli tutmuş oluruz ✅

Main/Master Branch Nedir?

Main (veya master) branch, Git projesindeki ana dalı temsil eder. Bu dal, projenin en son stabil ve yayınlanabilir halini içerir. Tüm önemli değişiklikler ve yeni özellikleri genellikle yan dallarda geliştiririz ve test ederiz, ardından main/master branch’e birleştiririz. Main/master branch, projemizin temel ve en güncel sürümünü tutar. Bu nedenle projemizin dağıtımı veya yayınlanması için kullanırız.

Yeni bir branch oluşturmak için git branch_ismi komutunu kullanırız. Örneğin: git navigationBar

Master/Main branch’e geri dönmek için git switch main komutunu kullanabiliriz.

Not: Genellikle Git yazılım projelerinde ana branch main ya da master olarak adlandırılır. Eksi projelerde ana branchlerde master kullanılırken yeni projelerde main kullanılmakta. Bu konu yazılım camiasında açık kaynak yazılım adına bir tartışma konusudur ⚔️ GitHub şu anda main kullanımını destekler. Ben de konuyu açıkladığıma göre yazıda main kullanarak devam edeceğim. Daha detaylı bilgi edinmek isterseniz bu makaleye göz atabilirsiniz ⤵️ 🔗 https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main 🗒️

Peki Git Log’da Yer Alan HEAD Nedir?

HEAD, hem hangi commit’te hem de hangi branch’te bulunduğumuzu gösterir. Eğer HEAD -> main görüyorsak ana branch'te olduğumuzu anlarız.

Eğer yeni bir branch oluşturup commit atarsak, HEAD bu yeni branch’i gösterir. Çünkü HEAD her zaman en son yapılan işleme, yani en güncel duruma işaret eder.

Merge Nedir?

Farklı branchlerdeki çalışmaları bir araya getirme işlemidir. Branch’teki değişikliklerimizi main ile birleştirmek için git merge branch_ismi komutunu kullanırız.

Bugfix ve Feature adında 2 branch açılmış ve sonrasında merge işlemi ile ana branche bağlanmışlar

Main’de herhangi bir değişiklik yapmadan sadece branch’lerde çalışıp bu branch’leri main’e bağlamak “Fast Forward” olarak adlandırılır. Bash terminalinde bu durumu şu şekilde görebiliriz:

Updating 8d43a41..72cec3c
Fast-forward
 arkakapak.txt | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 arkakapak.txt

Fast Forward’da yeni bir commit oluşturulmaz, çünkü ana dosyaya (main’e) hiç dokunmadık. Sadece yan branch’te geliştirme yaptık ve bunu direkt main’e bağladık. Bu yüzden sanki main’de geliştirme yapıyormuşuz gibi bir durum oluşur ve commit’e gerek kalmaz.

Fast-Forward Avantajları:

• Commit geçmişi daha temiz ve basit kalır.
• Yeni bir merge commit oluşmaz.
• Çatışma olasılığı düşüktür, çünkü doğrusal bir commit geçmişi vardır.

new_feature adında bir branch açılmış ve bu branch üzerinde değişlikler yapılırken main branchde değişiklik yapılmamış. Bu durumda sanki branchde değil de mainde işlem yapmışız gibi olduğumuzdan bu işlem yeni bir commit almaz

Fast Forward Merge: Fast Forward Merge yöntemiyle birleştirme yaptığımızda commit grafiğini inceleyelim. Burada, tüm commit’lerin main branch’in bir parçası haline geldiğini ve bu commit’lerin feature branch’ten mi yoksa main branch’ten mi geldiğini ayırt etmenin imkansız olduğunu görebilirsiniz.

Non-Fast Forward Merge: Şimdi, Non-Fast Forward Merge yöntemiyle birleştirme yaptığımızda commit grafiğini inceleyelim. Burada, orijinal commit’leri doğrudan main branch’e entegre etmek yerine, feature branch’te yeni bir commit oluşturulduğunu gözlemleyebilirsiniz.

git merge feature_branch komutu ile git merge feature_branch--no-ff komutu arasındaki fark için bu makaleye göz atabilirsiniz ⤵️

🔗 https://www.linkedin.com/pulse/difference-between-fast-forward-merge-vibhor-agarwal-j8mjc/

Merge Conflict Nedir?

İki farklı branchde aynı kod satırında değişiklik yapılmış ve sonrasında dosyalar merglenmek istediğinde conflict yaşanmış

Conflicti düzeltmek için ikisinden birini seçebilir ya da ikisini de silebiliriz. Conflictten kurtulmak için çakışmayı ortadan kaldırmamız yeterli

Commit Yapmadan Başka Bir Branch’e Geçiş Sorunu 🤔

Commit yapmadan başka bir branch’e geçmeye çalıştığımızda hatalarla karşılaşabiliriz. Önceki branch’teki değişiklikler commit edilmediği için yeni branch’e aktarılabilir veya git switch ... yapamayabiliriz. Bu sorunu çözmek için git restore ... komutunu kullanarak önceki commit'e dönebiliriz. Ancak bu işlem branch'teki değişiklikleri kaybetmemize neden olabilir.

Eğer commit yapmadan branch’ler arasında geçiş yapmak istiyorsak, git stash komutunu kullanarak değişiklikleri mesajı olmayan bir commitmiş gibi geçici olarak saklayabiliriz. Bu yapıya stash ismini veriyoruz. Stash’ler stack halinde depolanır. Böylece bilgi kaybı yaşamadan branch'ler arasında geçiş yapabiliriz.

Not: Daha fazla bilgi için Veri Yapıları ve Algoritmalar dersinde anlatılan stack yapısına göz atabilirsiniz.

Stash’teki değişikliklere geri dönmek için git stash pop komutunu kullanırız🍿 Bu komut stash'teki saklanmış değişiklikleri geri getirir. Ayrıca git stash list komutuyla saklanan tüm stash'leri görebiliriz. Fakat git stash pop komutu geri getirdiği stash’i, stash listesinden siler.

Bu işlemi listeden silmeden yapmak için de git stash apply komutunu kullanırız. Bu komut stash'i uygular ancak pop komutundan farklı olarak uygulanan stash’i listesinden silmez.

Eğer belirli bir stash’i eklemek istersek git apply stash@{index} komutunu kullanırız. Burada index, stash listesindeki stashin sıralamadaki numarasıdır.

Gifte de göründüğü gibi stash stack yapısına sahiptir !

Tüm stash’leri silmek için ise git stash clear komutunu kullanırız.

git stash

Commit Geri Alma ve Geçmişe Dönme

**git reset**: Varsayılan olarak, sadece index (staging area) üzerinde değişiklik yapar, çalışma dizinindeki değişikliklere dokunmaz. Yani, staged (stage’lenmiş) dosyaları geri alır ve bunları unstage eder.

**git reset <commit>**:Belirli bir commit’e geri döner ve index ile çalışma dizinini bu commit’e göre günceller. Bu işlem, commit’leri geri alır ve değişiklikleri stage’ler.

Örnek: git reset HEAD~1 komutu, son commit'i geri alır.

**git reset --hard <commit>**:Belirli bir commit’e geri döner ve index ile çalışma dizinini bu commit’e göre tamamen günceller. Bu işlem, hem staged hem de çalışma dizinindeki değişiklikleri kaybeder.

Örnek: git reset --hard HEAD~1 komutu, son commit'ten geri döner ve tüm değişiklikleri kaybeder.

**git reset --soft <commit>**:Belirli bir commit’e geri döner ama sadece index’i bu commit’e göre günceller, çalışma dizinindeki değişiklikler korunur. Bu işlem, commit’leri geri alır ama değişiklikleri stage’ler.

Örnek: git reset --soft HEAD~1 komutu, son commit'i geri alır ve değişiklikleri stage'ler.

⚠️Önemli Uyarı: git reset, çalışma dizinini ve commit geçmişini düzenlemenize olanak sağlar, ancak dikkatli kullanılmalıdır çünkü bazı seçenekler (özellikle --hard) değişiklikleri kaybedebilir.

ilk darbe git reset ikinci darbe git reset — hard🥊

Git Revert ve Rebase

git revert <commit_id> komutu, belirtilen commit'in yaptığı değişiklikleri tersine çeviren yeni bir commit oluşturur. Bu işlem, mevcut commit geçmişinizi korur ve önceki commit'in değişikliklerini geri alır. Bu yöntem, paylaşılan branch'lerde değişiklikleri geri almak için kullanışlıdır.

Branch’ler arasındaki farkları görmek için git diffkomutunu kullanabilirsiniz. Örneğin, git diff main feat/branch_isim komutu, mainve feat/branch branch’leri arasındaki değişiklikleri gösterir. Bu komut, iki branch’teki dosya değişikliklerini karşılaştırmanıza olanak tanır.

git rebase, branch'lerimizi main'e eklemek için kullanılan bir komuttur. Ancak paylaşılan projelerde bu işlem dikkatli kullanılmalıdır, çünkü diğer kişilerin çalışmalarını etkileyebilir.

Diğer Komutlar

• **git branch -r**: Remote depo üzerindeki branch'leri listeler.
• **git fetch <branch_ismi>**: Remote depodaki değişiklikleri workspace'e indirir, ancak mevcut branch'inizi güncellemez.
• **git pull**: Remote depodaki değişiklikleri alır ve workspace branch'inizle birleştirir. (git pull, git fetch ve git merge işlemlerini bir arada yapar.)
• **git clone <git_url> **: komutu, uzak bir repository'yi yerel bilgisayarınıza kopyalar ve aynı zamanda bu uzak repository'yi origin adıyla yerel repository'nize ekler. Bu, git remote add origin <git_url> komutunun otomatik olarak çalışmış gibi olmasını sağlar. Yani, git clone komutu, uzak repository'yi indirir ve bağlantıyı ayarlar.

Veda etmeden önce sizlere bilgilerimi aktarmak için çaba gösteriyor ve zaman harcıyorum, bunu yaparken herhangi bir maddi kazanç sağlamıyorum ⭐ İçeriklere devam edebilmem için ihtiyacım olan şey motivasyon ve sizlerin geri bildirimleri. Yorum yaparak ve beğenerek (alkış bırakarak) bana destek olabilir ve içeriklerin gidişatı için bana yol haritası çizmem konusunda yardım edebilirsiniz. Beni takip ederek de yeni yazılarımdan haberdar olabilirsiniz 💚 Yeni yazılarda görüşmek üzere beni diğer sosyal medya hesaplarımdan takip etmeyi unutmayın🦥

Hoşça kalın🚀🧡

https://linktr.ee/sudenazkalaycik 🧡🚀

Sudenaz Kalaycık

Aşağıdaki gibi bir kişi 50'ye kadar alkış bırakabiliyor! Tek yapmanız gereken şey tuşa basılı tutmak!