Git ve GitHub Nedir? Farkları Nedir? Nasıl Kullanılır ?
Herkese Merhaba, bu yazımda Yazılım camiasında çokça duyup ve çokça kullandığımız Git ve Github’dan bahsedeceğim. Elimden gelidiğince Git ve Github’ın amacını ve temel yapısını en basit şekilde anlatmaya çalışacağım. Çünkü bende bu yapının temel mantığını anlamadan kullanamaya çalışıp biraz zorluk çekmiştim fakat sonradan temel mantığını kavrayıp kullandıktan sonra anlayabilmiştim. Git ve GitHub Nedir? sorusundan önce Versiyon Kontrol Sistemi Nedir bunu anlamak Git ve GitHub’ı anlamayı kolaylaştıracaktır. Haydi başlayalım.
Versiyon Kontrol Sistemi Nedir ?
Git ve GitHub bir versiyon kontrol sistemidir cümlesini her yerde görümüşüzdür peki nedir bu versiyon kontrol sistemi. Oynadığımız herhangi bir bilgisayar oyununu düşünün, oyunlarda haritanın belli yerlerinde oyunu kaydetme alanları olur bunun amacı oyunda ilerleyişinizi kayıt altına almaktır daha sonraki bölümlerde öldüğünüzde yeniden başlamaktansa en son kaydettiğiniz yere gelip devam ederiz. Kısacası versiyon kontrol sistemi yazdığımız projenin kodlarında veya herhangi bir döküman üzerinde yaptığımız değişiklikleri adım adım kaydetmemizi sağlar. Böylece projede yaptığımız bir yanlışlıkta önceki adımlara geri dönebiliriz.
Git Nedir ?
Git bir versiyon kontrol yazılımıdır. Yani yukarıda da bahsettiğimiz gibi projemizde yaptığımız değişiklikleri adım adım kaydetmemizi sağlar ama bunu bizim bilgisayarımızda yani yerel de yapar , internet bağlantısı olmadan veya kayıt olmadan kullanabiliriz. Bunun için bu yazılımı bilgisayarımıza indirmemiz lazım.
GitHub Nedir ?
GitHub ise projelerimizin cloud (bulut) tabanlı bir sistemde online olarak yer aldığı bir servistir. Bunun için www.github.com’a üye olmamız gerekir. GitHub ile başkalarının projelerine bakabiliriz, projelerine destek verebiliriz ve anlatacağımız bir çok işlevi yapabiliriz. GitHub’ı offline(çevrimdışı) olarak kullanamayız.
Kurulum Ve Repository Kavramı
İlk olarak https://git-scm.com/downloads adresinden işletim sistemimiz neyse ona uygun versiyonu indirip kurmamız gerekiyor. Kurulum adımlarını burada anlatmayacağım bunun hakkında YouTube’da videolar bulabilirsiniz.
Kurulumu bitirdikten sonra repository kavramını nedir bunu öğrenelim. Repository versiyonladığımız proje veya dökümanımızdır diyebiliriz. Localimizdeki bir projeyi versiyonlamak için projemizin bulunduğu klasörün içine gidip terminalde git init komutunu yazmamız yeterli olacaktır artık bu proje dosyası bizim repomuzudur. Versiyonlama işlemini bu repo yani projemiz üzerinde yapacağız.
Git Terminalini çalıştırdığımızda önümüze böyle bir ekran gelecektir;
yeşil ile yazan kısım bilgisayar ismimizdir. Terminal üzerinden belirli komutları yazarak Git’i kullanmış olacağız.
Şimdi mail adresimizi ve adımızı, soyadımızı Git’e kaydedelim hem Localde hemde Çevrimiçi olarak GitHub’da yapacağımız projelerde veya başkalarının projesine destek verirken veya daha farklı durumlarda yapılan işlemlerin bizim tarafımızdan yapıldığının anlaşılması için git terminale gelip git config — global user.mail ‘ornek@gmail.com’ (ornek@gmail.com kısmına mail adresinizi yazın) ardından Enterlayın daha sonra git config — global user.name ‘Ornek Ornek’ (ornek ornek kısmına ad ve soyadınızı yazın) ve enterlayın.
Bir Projeyi Versiyonlamak için;
Projenin bulunduğu klasöre gelmemiz lazım bunun için terminale pwd komutu yazıp nerede olduğumuzu öğreniyoruz ardından projemizin bulunduğu klasöre gidiyoruz bunun için cd (klasör ismi) komutunu kullanıyoruz artık projemizin bulunduğu klasörün içindeyiz. Ardından git init komutu ile bu projemizin bulunduğu dosyayı versiyonluyoruz.
Not: pwd ve cd komutu terminalde kullandığımız komutlardandır. pwd komutu konumumuzu gösteriri. cd komutu ile bir sonraki veya bir önceki klasöre geliriz.
Artık projemizi istediğimiz adımda kayıt altına alıp istediğimiz zaman veya bir hata aldığımızda veya eski sürümüne dönmek istediğimizde bu istekleri gerçekleştirebileceğiz. Projemizin içinde versiyonlamak istemediğimiz dosyalar olabilir örneğin kütüphaneler veya daha farklı dosyalar bu istemediğimiz dosyalar için projeye .gitignore uzantılı dosyayı eklememiz lazım. Artık bazı kavramları analdık ve yapıyı azda olsa kavradığımızı düşünüyorum.
Projemize başladık ve bir web sitesi yapıyoruz diyelim. İlk olarak projenin Anasayfasını tasarlıyalım ve ardından bunu commit edelim.
Yukarıdaki resimde gördüğünüz gibi Anasayfa’yı tasarladıktan hemen sonra git status diyerek proje durumunu öğrendik ve bize commit etmemiz gerektiğini söyledi bunun içinde önce git add. ile projeyi Staging Area kısmına aldık (bu kısmın ne olduğunu aşağıda anlatacağım). Ardından git commit -m “ ” komutu ile projemizi commit ettik yani bir nokta oluşturduk (“ ” ifadesi içerisine commit mesajmızı yazıyoru ben Anasayfa Eklendi mesajı yazdım). Commit ederek Git’de bir geri dönüş noktası oluşturmuş olduk (hani ilk başta bahsettiğimiz oyun kaydetme gibi) ve istediğimiz zamanda bu kayıt noktasına geri dönebiliriz. Şimdi bu projeyi local’den herkesin ulaşabileceği GitHub hesabımıza göndermek için ;
Tarayıcıdan GitHub hesabımıza girip repository oluşturuyoruz önümüze yukarıdaki gibi bir ekran gelecek. (Ben for-medium-article adında bir repository oluşturdum) Yaptığımız projeyi ilk defa GitHub hesabımız ile bağlayacağımızdan dolayı yıldızlı kısımdaki kodlar ile işlem yapacağız.
git remote add origin (buraya repo adresimizi yapıştıracağız ) komutu ile projemizi uzak sunucuya eklemiş oluyoruz buradaki origin URL şeklindeki adresi teslim eden bir kelimedir yani origin = URL adresi diyebiliriz.
Daha sonra git branch -M main komutunu kullanıyoruz fakat benim branch ismim yani projeyi yaptığım yolumun veya dalımın ismi master olduğundan dolayı git branch -M master diyeceğim. (Branch kavramını aşağıda detaylı olarak anlattım fakat şimdiden branch’i projeyi tasarladığımız yol olarak düşünebiliriz).
git push -u origin master ile projemizi repomuza pushluyoruz yani gönderiyoruz. Artık bundan sonra yaptığımız değişiklikleri daha kısa komutlarla GitHub’da bulunan repomuza göndereceğiz. Buradaki -u ise origin ve master’ı push edeceğini aklında (origin’i yukarıda bahsetmiştik urlmiz) tutar yani her seferinde git push -u origin master demek yerine aynı branchde push işlemi yaparsak sadece git push diyebiliriz.
Şimdi Git Sistemini anlatan bir resim ile devam edelim.
Working Directory kısmı proje üzerinde çalıştığımız zamanki kısım diyebiliriz. Ardından git add komutu ile projeyi Staging Area kısmına alıyoruz Staging Area kısmına projemizi .git Directory kısmına atmadan önce beklettiğimiz alan diyebiliriz. .git Directory kısmına ise yaptığımız değişikliklerden eminsek git commit komutu ile projemizi attığımız alan diyebiliriz.
Şimdi bu anlattıklarımızı terminalde uygulamalı yapalım;
Anasayfamızı tasarlarken Working Directory kısmındaydık. git status komutunu kullanıp projemizdeki güncel durumumuzu yani hangi alanda olduğumuzu öğrenebiliriz. Resimde Anasayfa.html’ in takip edilmeyen (git tarafından) bir dosya olduğunu anlıyoruz. Şimdi git add . komutu ile bunu Staging Area alanına alıyoruz eğer sadece belirli dosyayı Staging Area kısmına almak istersek git add (“klasör ismi”) yazarak sadece ismini yazdığımız klasörü Staging Areaya almış oluyoruz.
Şimdi projemiz Staging Area kısmında yine git status komutunu kullanarak nerede olduğunu öğrenebiliriz.
Şimdi (oyunlarda oluşturulan kayıt noktaları gibi) git commit -m “ (komit mesajı yazılacak buraya) ” komutu ile projemizi .git Directory alanına almış oluyoruz böylece yukarıdaki resimde de görüldüğü gibi ilk commiti oluşturmuş olduk yani ilk noktamızı oluşturduk.
Şimdi projemizde İletişim Sayfası diye bir sayfa tasarlıyalım. Visual Studio kullanarak projemizi yapıyoruz. Anasayfayı tasarlayıp commit etmiştik. Şimdi İletişim Sayfasını tasarladık ve hemen terminale gidip
git status diyip güncel duruma bakıp takip edilmeyen bir dosya olduğunu görüyoruz buda bizim yeni tasarladığımız İletişim Sayfası Ardından git add iletisimSayfasi.html yazarak (veya git add . ) bu dosyayı Staging Area kısmına aldık ardından git commit -m “İletişim Sayfasi Eklendi” diyerek 2.commit noktamızı oluşturduk sonra bunu git push komutu ile uzaktaki repomuza yani GitHub’a göndermiş olduk artık hem localde 2 commitimiz var hemde GitHub’da yani iki yerde güncel.
Projemizde 2 tane commit noktamız var. Bu commit noktaları sayesinde bir önceki noktaya geri dönebiliriz veya iletişim sayfasını oluştururken bir hata aldık diyelim tekrardan ilk noktamıza yani Anasayfayı oluşturduktan sonraki halimize dönebiliriz.
Git yapısını anlatmanın aslına bakarsanız pekde sırası yok bu yüzden sıralamaya bağlı kalmadan genel yapıyı anlatmaya çalışıyorum bazı yerlerde daha önce anlatmadığım kavramları kullancağım fakat bunları yazının devamında anlatmış olacağım bu yüzden herhangi bir sıkıntı olmyacak ,bu durum sizi endişelendirmesin. Dediğim gibi bir sıralama yok. Umuyorum ki yazının sonunda Git ve Github’ın temel yapısını öğrenip artık kullanabileceksiniz. Tabi tam kavramak için her projenizde kullanmaya çalışın.
Şimdi gelelim Head Kavramına;
Head Nedir?
Head bizim hangi konumda olduğumuzu gösterir. Yani genelde son commitimizi gösterir. Head bize hangi branch ve commitde olduğumuzu gösterir. Branch kavramına dediğim gibi aşağıda deyineceğim.
Şimdi aşağıdaki resmi inceleyelim.
Şuana kadar 2 tane commit noktası oluşturmuştuk. Terminale gelip git log komutu yazdığımızda kaç tane commit noktamız varsa onları gösterecektir. Toplamda 2 commitimiz olduğundan dolayı 2 adet commit gösterdi. Aynı zamanda yukarıda bahsettiğimiz Head → master kavramınıda görüyoruz. İşte Head bize nerede olduğumuzu söylüyor. Şuanda commit 9d031e7bff … diye başlayan commitde olduğumuzu söylüyor. Buradaki uzunca yazı commitlerin hash değerlerini gösteriyor. Commitler arası geçişlerde her commite özel bu hash değerini kullancağız. Turuncuyla çizili yerde bu commitin mesajın gösteriyoru bu commiti oluştururken “İletişim Sayfasi Eklendi” diye yazmıştık. Onun altındaki commit ise ilk oluşturduğumuz commit. Pempe ile çizi yerler ise bu commitleri kimin oluşturduğunu ve bu kişin mailini gösteriyor aynı zamanda tarih bilgisini veriyor.
Branch Nedir?
Bir önceki kısımda Head kavramının ne olduğunu görümüştük. Ve en son commitin yanında HEAD → master olduğunu görmüştük. Masterı açıklamadım çünkü burada açıklamam lazım. Branch kavramını türkçesi ile “dal” ağaç dalı olarak düşünebiliriz. Projemize başladık 2 tane sayfa tasarladık commit ettik , ardından 3.sayfayı ekleyeceğiz fakat ekleyeceğimiz 3. sayfa tüm projeyi kötü yönde etkileyebilir bu yüzden projemizi farklı bir dal üzerinden götürmemiz lazım git branch (yeni branch ismi) komutu ile bu yeni dalı, yeni yolu oluşturabiliriz. Şimdi master kavramına gelelim, işte master da bu dalın, branch’in adıdır. Yani biz projemizi master Branch i üzerinde geliştiriyoruz. Bu branch’in adını değiştirebiliriz bize bağlı. Şimdi branch kavramını aşağıdaki resim üzerinden inceleyelim
Normalde master adlı branch üzerinde projemizi geliştirecektik. Ama yeni bir branch yani dal açıp projemizi bu yeni branch üzerinden geliştiriyoruz. Bu 2.branch’in ismide genelde Featur olur veya daha farklı isim verebilirsiniz. Ben Featur’un kısaltması olarak Feat diyeceğim.
Senaryo şöyle ilk başta Anasayfamızı oluşturduk ve commitledik sonra İletişim sayfamızı oluşturduk ve commitledik ardından yeni bir özellik eklemek istedik ve bu özellik tüm sistemi etkileyebilir o yüzden yeni bir branch açtık Feat adında. Bu yeni Branch’i oluşturduğumuz anda commit alarak bir commit noktası oluşturduk ve yeni geliştirmeleri yapıp bir tane daha commit attık. Sonra projenin herhangi bir sorunla karşılaşmadığını gördük ve bu Branch’i Merge yani birleştirip yine ana branch’imiz üzerinden yani master üzerinden devam edebiliriz.
Burada yeni branch açma nedenimizin birden fazla sebebi olabilir.
1- Çalıştığınız şirkette proje üzerinde birden fazla kişi çalıştığı için herkesin görevide farklı olabilir bu yüzden herkes projeyi alıp kendi branchlerinde geliştirip ardından Merge edebilir yani birleştirebilir.
2- Projenize ekleyeceğiniz yeni modül projeyi patlatabilir bu yüzden yeni branch açıp bu modülü yeni branch de uygulayıp ardından durma göre ana branch’e merge edebilirsiniz.
Şimdi terminal üzerinde branch oluşturma ve merge işlemini yapalım.
git branch komutu ile kaç tane branch olduğunu ve bunların isimlerini görebiliriz.
git branch feat komutu ile yeni bir branch oluşturduk. (feat yerine başka bir isim yazabilirdik fakat genelde 2.branch ismi olarak feat kullanılır) ve ardından git branch dediğimizde 2 tane branch’in olduğunu gördük ve master branchi yeşil gözükmekte yani biz şuan bu master branch de bulunuyoruz diyor.
git switch (branch ismi) yani git switch feat komutu ile feat branch’in e geçiyoruz.
Şimdi bu yeni Branch’ e yeni bir modül ekleyelim.
Feat Branchin de yeni bir sayfa KayitSayfasi.html adlı bir dosya daha oluşturduk tabi bunları Visual Studio Code’dan yapıyoruz isterseniz terminalden’de dosya klasör ekleyebilirsiniz.
Projemize yeni bir modül ekledik ve aşağıdaki gibi git status dedik durumu görmek için sonra bunu commit ettik ve yeni branch’de artık 1 tane commitimiz var.
Aynı işlemleri uygulayım bir tane daha commitleme yapalım
Commit ve branchlerimizin görseli aşağıdaki gibi oldu.
Solda aşağıda bulunan resim Master Branch’ine geçiş yapınca göreceğimiz dosyalar. Sağ tarafdaki resim ise Feat Branch’ine geçiş yapınca göreceğimiz dosyalar. Şimdi aradaki farkı daha iyi anladığınızı düşünüyorum.
Şimdi master Branchin de 2 commit daha atıp en sonunda merge işlemi yapalım. Master branchinde 2 tane daha dosya oluşturdum Projeler sayfası ve çalışanlar sayfasi adlı bunlarıda comitledim ve projenin commit haritası en son şu şekilde oldu;
Birleştirme işlemi yapmak için master branch’e dönüp git merge (birleşime alacağımız branch ismi) yani git merge feat diyoruz. Merge noktasınıda otomatik olarak bir commit noktası olarak alıyor.
Şimdi master branch de git log diyelim;
git log dedikten sonra en son commit’in “çalışanlar sayfasi eklendi” olduğunu görüyoruz. Yani feat branch’de yaptığımız tüm commitleride getirdi ve bunları birleştirdi. Master branch’de bulunurken proje dosyamıza gidelim aşağıda görüldüğü gibi feat branch’in de oluşturduğumuz tüm dosyalar artık master branchinde de mevcut.
Proje dosyamıza feat branch’de yapılan commitlerde eklendi ve artık master branch’de bulunuyoruz. Yapının en son halinin görsel şekli;
Fast Forwarding
Fast Forwarding kavramını anlamak için önce Branch kavramını iyi anlamamız lazım. Master Branch’de herhangi bir işlem yapmadan Feat Branche geçip orada commit işlemleri yaparak bunu Master Branch ile Merge etme işlemidir. Bu işlemi yapmamızın amacı Conflit hatasını almamak önüne geçmek Fast forwarding en büyük amacı budur.
Yukarıdaki resimde görüldüğü gibi normalde master Branch’de ilerlerken Feat adında branch açtıktan sonra orada 2 tane commit attık ve bunu Merge ettik, branch’de hiç bir değişiklik yapmadık işte böyle bir durumda 2.resimdeki gibi bir durum olacak Feat Branch’de bulunan 2 commiti aşağı alıyor ve Feat’de ki son commiti Master Branch’in son commiti olarak varsayıyor. Kısacası Feat Branchi açdıktan sonra tekrardan master Branch’e gidip değişiklik yapmamışsak bu durum gerçekleşir. Git Log dediğimizde durum aşağıdaki gibi…
Merge Conflict
Merge Conflict, genellikle aynı proje üzerinde çalışan kişilerin, projedeki aynı satırı veya aynı dosyayı değiştirmesi veya birinin dosyayı silmesiyle ortaya çıkan bir problemdir. Şimdi bu konuyu daha iyi anlamak için bir senaryo kuralım;
Deneme isimli bir proje klasörü oluşturup bunun içinde index.html adlı bir dosya oluşturalım. Bunun için terminale gidip aşağıdaki 2.resimde bulunan komutları sırasıyla yazıyoruz tabi bunun için DENEME klasörüne gelmemiz lazım bunun için terminalden cd komutunu kullanarak dosyalar arasında dolaşıp istediğiniz dosyaya ulaşabilirsiniz veya oluşturduğunuz dosyanın üzerine sağ tıklayıp açılan pencerede aşağıdaki ilk resimde görülen ok işaretli kısma tıklarsanız git terminali direk bu klasör üzerinden başlatacaktır.
Yukarıda gördüğümüz 2.resimde deneme isimli dosyamıza git init diyerek projemizi versyonlamış olduk ardından touch index.html diyerek index.html adlı bir dosya oluşturduk ve bunu commitledik.
Master branch’de bulunan dosya ve kodu yukarıdaki gibidir.
Şimdi yeni bir branch açalım feat adında ve style.css adlı bir dosya daha oluşturalım aynı zamanda index.html klasörünüde ufak bir değişiklik yapalım.
style.css dosyasını oluşturduk ve index.html dosyasında ufak bir değişiklik yaptık ve bunları commitledik.
feat branch’de dosya ve içerikleri yukarıdaki gibi. index.html dosyasındaki değişikliği kolayca anlamışsınızdır master branch’de ki index.html dosyasında WEB ANASAYFA HTML KODU yazıyordu. feat branch’de ise WEB ANASAYFA yazıyor yani 2 kelime silmiş olduk.
Şimdi master branch’e geri dönüp index.html dosyasını silip yeniindex.html adında bir dosya açalım ve commit edelim daha sonra feat barnch ile merge işlemi yapalım ve neler oluyor birlikte görelim.
Yukarıda ki resimde kurguladığımız adımları uyguladık git rm index.html komutu ile index.html dosyasını sildik, touch.yeniindex.html ile dosya oluşturduk. Dosyamızın içeriğide aşağıdaki gibi;
git merge feat dedikten sonra terminalde “merge conflict ” hatasını alırız. Çünkü dosyalar arası çakışma oldu. Master branch’de index.html adlı dosyamız vardı ve biz bunu silip yeniindex.html adında yeni dosya oluşturduk ardından feat branch’de index.html dosyamızı değiştirdik.
git merge feat dediğimizde yukarıdaki hatayı alacağız otomatik merge etmeyecek yani conflict hatasını almış olduk. Bunu çözmek için Visual Studio Code’ a gidelim ve deneme dosyamızda feat branch’den gelen style.css dosyasını ve diğer değişiklikleri göreceğiz artık duruma göre ister dosyayı sileriz veya değişikliği kabul etmeyiz istersek kabul edip kayıt ederiz ben sadece style.css dosyasını kabul ettim ve yeniindex.html dosyasını değiştirmedim olduğu gibi kabul edip kayıt ettim artık bu işlemi commit etmemiz lazım commit ettikten sonra çakışma durumunu ortadan kaldırmış olacağız. son durum artık böyle;
Git Stash
Git stash komutunu anlamak için yine ufak bir senaryo kuralım :) Master branch’de çalışıyoruz ve ardından feat adında yeni bir branch açtık burada yeni özellikler eklerken proje liderimiz veya takım arkadaşımız bize master branch’e geçmemizi ve orada bir kaç işlem yapmamızı söyledi ama biz feat branch’de yeni özellikler eklemiştik ve bunu commitlemedik bu durumda master branch’e geçtiğimizde bu branch karışabilir ve tekrardan feat branch’e döndüğümüzde eklemiş olduğumuz özelliklerin kaybolduğunu görürüz işte böyle bir durumda stash komutunu kullanırız. Stash komutu bu gibi durumlarda commit işlemi yapamadığımzda kodlarımızın gitmemesi ve karışıklık çıkarmamsı için yazmış olduğumuz kodları farklı bir alanda bekletir.
Şimdi deneme2 adlı bir klasör oluşturduk ve içinde index.html adlı bir dosya oluşturduk. index.html içinde sadece 1 satır yazdık “stash özelliğini deniyorum” diye ve bunu commit edelim. Şimdi 2.satıra “merhaba” kelimesini yazalım fakat bunu commit etmeyelim.
Şimdi git stash komtunu kullanalım.
Visual Studio Code’a geri döndüğümüzde 2.satırdaki merhaba komutunu görmeyeceğiz. Bunu farklı bir alana almış olduk istediğimiz zaman getirip projemizin istediğimiz kısmına ekleyebiliriz.
Şimdi 2.satıra sakladığımız kodu getirelim bunun için git stash pop diyoruz ve sonuç aşağıdaki gibi;
Bunuda commit etmemiz lazım.
git stash list güncel stashlerin listesini çıkarır.
hangi stash’i ekleyeceksek git stash apply stash@{0} veya daha farklı bir stash numarası yazarak istediğimiz stash’i ekleyebiliriz.
git stash clear komutu ile tüm stashleri silebiliriz.
Git Checkout
Commitler arasında dolaşmamızı sağlar. Senaryolara devam :) Bir proje yapıyoruz ve bu projede sadece bir tane branch var (master) ve toplamda 4 tane commit attığımızı varsayalım;
git log komutu yaptığımızda terminalde 4 tane commitimizi görüyoruz ve kırmızı yıldız ile çizilmiş alana dikkat edelim son commiti HEAD → master şeklinde görüyoruz. Şimdi 3.commite gitmemiz gerekti ve 3.committe bulunan kodlarımıza bakmak istiyoruz bunun için;
git checkout (commitin hash kodu) şeklinde terminale komutu yazıyoruz. hash kodlarınıda git log komutu yazdıktan sonra terminalde karşımıza çıkan uzunca olan kısım zaten yukarıdaki resimde pempe kalemle altı çizili.
git checkout komutunu yazdıktan sonra yukarıdaki gibi bir uyarı gelecek. Uyarıda Head kısmı kopuk diyor , normalde head bulunduğumuz commiti gösterirdi bu senaryoda yani 4.commiti gösterirdi bizde 3.commite geri döndüğümüzden dolayı artık Head kısmı 3.commiti gösteriyor fakat bu durum yanlış bir durum bu yüzden uyarı aldık. Bu durumda git switch master diyerek en son commitimize döneceğiz ya da yeni bir branch açıp buradan devam edeceğiz.
Yukarıdaki resimde görüldüğü gibi c6829b… kısmı bize 3.commit’de olduğumuzu söylüyor. git switch master dediğimizde o kısmın master’a döndüğünü görüyoruz yani artık en son commitimiz olan 4.committeyiz.
git reset ve git revert komutları
Peki 3.commite dönmek isteyip artık o commitden devam etmek istersek ne yapacağız. Yani 4.commiti silip en son commiti 3.commit yapmak istersek ne yapacağız? git reset (hash kodu) yazıyoruz ve ardından git log yazıp terminalde sonuçları görüyoruz.
artık 4.commit yok silindi fakat git reset komutu silinen commitin içeriğinide bırakır kod kısmında yani Visual Studio Code’da projemize baktığımızda 4.commitin kodlarıda kalacaktır isteğimize göre kod kısmından da silebiliriz. Değişiklik olduğundan dolayı bu durumuda commite etmeliyiz örneğin git commit -m “4.commit silindi ” gibi…
git reset - -hard (hash kodu) : hem kod içeriğinin hemde comitlerin silinmesini sağlar. Artık geri dönüşü olunmaz bir yola girmiş oluyoruz.
git revert (hash kodu) ile yaptığımız commit işlemlerini geri alabiliyoruz ve yine aynı branch üzerinden devam ediyoruz fakat bu geri alma işlemi içinde yeni bir commit oluşturuyoruz.
Örneğin 3 tane commitimiz olsun ve biz 2.commiti ve 3.commiti geri almak istiyoruz fakat yine master branch’de devam etmek istiyoruz burada her geri alma işlemi için yeni bir commit atmamız gerekiyor. git log dediğimizde 2.commitin ve 3.commitin kayıtları yine görmüş olacağız bunlara ek olarka 2 tane daha commit eklenecek ve revert edildiği yazılmış olacak yani anlayabileceğiz.
git restore (dosya ismi) komutu ile commitlemediğimiz fakat staging are’ya aldığımız yani git add . ‘lediğimiz dosyayı son committeki haline yani bir önceki hale geri getirebiliriz.
git diff komutu commitler arası ve branchler arasındaki farkları görmek amacıyla kullanılan komuttur.
git diff (1.commitin hash kodu) (2.commitin hash kodu) komutu ile 2 commit arasındaki farkları görebiliriz.
git diff master feat komutu ile master ve feat barnchleri arasındaki farklılıkları gösterir.
git rebase
Merge commitleri silmek için kullanılır tüm branchleri tek bir dal üzerine alır ve aradaki tüm merge commitlerini siler.
Pull Request
Ekip halinde bir proje gerekleştirdiğimizi düşünelim. Herkesin ayrı bir görevi var Takım Liderimizde projemizi yönetiyor ve repo sahibi kendisi. Geliştirme ekibi projede yaptığı değişiklikleri projenin sahibine pull request olarak gönderebilir ardından proje sahibi bu isteği kendi kararına göre kabul edebilir veya etmeyebilir. Örnek olarak bir proje açtık ve bu projeyi ana branchimizde (master) ilerletiyoruz ve diğer ekip arkdaşımız yeni bir branch açtıp (feat) bu branch’e yeni bir dosya ekledi ve commitledi ardından pushladı. Proje sahibi biz olduğumuzu varsayalım bize GitHub repomuza gittiğimizde bildirim gelecek ve pull request isteğini göreceğiz bunu kontrol edip conflict yoksa merge edebiliriz yani projeye ekleyebiliriz.
Fetch ve Pull Kavramları
Pull requesti anlatırken proje sahibine GitHub sayfasında bildirim geldiğini söyledik bildirim geldikten sonra proje sahibi değişikliği onayladığını varsayalım ve GitHub’da proje değişiti ama localde bulunan projemiz bu değişikliklerden geride kaldı kısacası localdeki repomuz remote’da bulunan projemizden geride kalırsa git fetch ve git pull komutlarını kullnacağız.
fetch komutu ile, GitHub’da önde olan repodaki değişiklikleri , geride olan Local repomuza getirebiliriz. Fakat bu işlem local repomuza sadece bu değişiklikleri getirir fakat bunları local’de ki repomuza eklemez. Eee ne işimize yaradı bu komut dersek cevap şu olur; yapılan değişiklikleri önce kontrol etme imkanı sağlayacak.
pull komutu ise bu değişiklikleri local’de bulunan repoya getirir ve aynı zamanda merge işleminide yapar yani değişiklikleri ekleyip kayıt eder.
Terminalde’de görüldüğü gibi ilk önce git fetch origin master komutunu kullandık ve GitHub repomuzdaki (remote repo) bilgileri localimize getiriyoruz. git branch -r ile uzak repodaki branchleri görebiliriz. Bilgileri getirdiğimiz için git checkout origin/master ile remote’da ki repolarda bulunan branchler arasında geçiş yapabiliriz. Bunu yaptıktan sonra bize detached head uyarısı veriyor, yani Head koptu uyarısı veriyor. Hatırlarsanız commitler arasında gezerkende bu uyarıyı veriyordu
git log diyerek bu remot’da ki commitleride görebiliriz. Ardından git checkout master ile localdeki repomuza geliyoruz
şimdi localdeki repoda bulunurken git log dersek aradaki farkı daha iyi kavramış oluruz. Şimdi bu bilgileri git pull origin master komutu ile merge edelim.
git clone
GitHub’da beğendiğimiz bir projeyi veya ekipçe yapılan bir projeyi local’e getirmek için kullandığımız bir komuttur. Bunun için git clone url , url kısmına reponun url adresini yazıyoruz. Örneğin bir projeyi çok beğendik ve bilgisayarımıza git clone url komutu ile indirdik ve bu projeye katkı vermek istiyoruz yeni özellikler ekledik bu özellikleri commitlersek git terminalinde hata alacağız buna yetkimizin olmayacağını söyleyecek.
git fork
Herhangi bir projeye katkı vermek istiyorsak Projenin reposuna gelip Fork tuşuna basıyoruz. Ardından bu repoyu GitHub’da bulunan repolarımızın içine alıyor ve bunu git clone komutu ile local repomuza getirip değişiklikleri yapıp yani commitleri atıp ardından push edip ve daha sonra projenin asıl sahibine pull/request gönderebiliriz. Böylece projelere katkı verebiliriz.
ISSUES
GitHub’da herhangi bir repoya girdiğimizde aşağıda işaretlenmiş alanda Issues (sorunlar) kısmını görüryoruz. Bu alan bir projedeki bugları,hataları veya yapılacak geliştirmeleri barındıran bir alandır. Açık kaynaklı projelerde sıklıkla kullanılır. Açık kaynaklı projelerde, projeyi inceleyen insanla bu alandan hataları belirtebilir.
Uzunca bir yazı olduğunun farkındayım :) git, github’ın temel mantığını anladığınızı umuyorum ve git,github’da unttuğunuz kısımlar oldukça dönüp bakabileceğiniz bir makale oldu. Elimden gelidiğince detaylı anlatmaya çalıştım fakat buna rağmen eksik yerler olabilir. Herhangi bir problem veya fikriniz olursa yorumlar kısmına yazabilirsiniz veya Linkedin, GitHub gibi yerlerden ulaşabilirsiniz. Diğer yazılardan haberdar olmak için takipte kalın buraya kadar okuyup sabır ettiğiniz içinde ayrıca tebrik ederim. :)
Kaynakça
Not: Bana göre Türkçe kaynaklar arasında en iyisi Atıl Samancıoğlu Hoca’nın BTK Akademi ile birlikte hazırlamış oldu Git ve GitHub kursudur.
