Git Kullanımı

Merhaba, bu yazıda git ve github’tan bahsedeceğim. Bu yazıyı hazırlarken BTK Akademi de Atıl Samancıoğlu’nun eğitiminden yararlandım.

Git nedir?

Git versiyon kontrol sistemidir. Git gibi birkaç tane daha versiyon kontrol sistemi bulunur fakat git aralarında en çok kullanılandır. Git’ten önce projelerimizi diskte saklıyorduk ve bu tehlikeliydi, fakat şimdi git sayesinde projemizi internet üzerinde saklayabilir, takım arkadaşlarınla daha verimli ve kolay biçimde çalışabilir ve projenin bütünlüğünü daha rahat sağlayabilirsiniz. Git ve Github birbiriyle aynı sanılmasının aksine farklı şeylerdir. İlk cümlelerde belirttiğimiz gibi git versiyon kontrol sistemidir, github ise repolarımızı sakladığımız bir websitesidir.

Git Kurulumu

Git kurulumunu Git — Downloads (git-scm.com) adresinden işletim sisteminizi seçip indirerek kurabilirsiniz.

Git Kullanımı

Git’i kullanmak için ilk önce kaydolmamız gerek.

Bunun için ilk önce “Git Bash” uygulamamızı açıp e‑posta ve kullanıcı adını ayarlamamız gerek:

git config --global user.name "example_name"
git config --global user.email "[email protected]"

Ardından projemiz hangi klasördeyse “git bash” terminalinden oraya gidip git status komutu ile daha önce git init edilmiş mi diye bakmamız gerek. Eğer init edilmemişse git init komutunu yazarak dizini Git deposu haline getiriyoruz.

git status komutu güncel durumu kontrol eder.

git init komutu dizinde .git klasörünü oluşturur ve dizini Git repository haline getirir.

Git Katmanları

Git 4 katmandan oluşur. Bunlar working directory, staging(index), local repository ve repository katmanlarıdır.

1- “Working directory” katmanı bizim çalıştığımız dizindir.

2- “Staging” katmanı ise biz projemizde “git add” yaptığımızda fakat henüz commit etmediğimiz de aktif olan katmandır. Yani projemiz henüz local reposityory içine kaydedilmedi.

3- “Local Repository” katmanı ise “staging” katmanında indexlenen verileri commit ederek local repository içine kaydettiğimiz yerdir.

4- “Repository” ise son katman olup commitlediğimiz projenin githubtaki halidir.

Örneğin bir dosya yarattık ve üzerinde bazı değişiklikler yaptık yada varolan bir dosya üzerinde değişiklikler yaptık. Bunu commit etmeden önce staging katmanına almamız gerek. Bunun için komutlar var fakat en basit komut olarak:

git add .

komutunu kullanabiliriz. Bu komut ile “working directory” katmanındaki değişiklikleri “Staging” katmanına alır yani indexlenir.

“Staging” katmanındaki indexlenmiş verileri commit ederek “Local Repository” katmanına almalıyız. Bunun için de:

git commit -m "msg"

komutunu kullanabiliriz.

git log

komutu ile commitlerimizin hikayesini ve sırasını görebiliriz. Ayrıca her commite bir hash atanır. Bu hash i daha sonra önceki commitlere geri dönmek için kullanacağız.

Eğer hiç commitimiz yok ise çıktımız şuna benzer olur:

fatal: your current branch ‘master’ does not have any commits yet

Eğer commitlerimiz var ise Örnek log çıktısını aşağıda görebilirsiniz.

“HEAD->master“ nedir bunu branch kısmında anlatacağım.

Şu ana kadar git’e kayıt dışında projemizi oluşturup ilk commitimizi attık. Gelin bunu görselleştirelim.

cd komutu ile dizin değiştirdim ve Desktop ta “blog” isimli bir klasör oluşturdum. Bu klasör “Working Directory” olacak.

Burada yukarıda da yazdığım gibi git projesini init etmeden önce kontrol ediyorum. Bunu yapmak zorunda değilsiniz hele ki yeni klasör yarattıysanız fakat sonradan ortaya karmaşıklık çıkmasını istemediğimiz için gösteriyorum. Aşağıda görüyoruz ki projemiz init edilmemiş.

Projemizi:

git init

komutu ile başlattık. Artık “blog” klasörümüzün içinde “.git” klasörünü görebiliriz.

Burada 1 yazan kısımdan önce şu komutu kullandım:

touch first_part.txt introduction.txt

böylece iki tane dosya açmış oldum. Bunu yaptığımız anda git status komutunu çalıştırsam git bana bu iki dosyayı indexlemedin diyecek. Fakat bunu daha sonra yapacağız. 2. kısımda echo komutu ile “introdution.txt” dosyasına “giris bolumu yazildi” yazısını yazıyoruz. Bunu gidip dosyayı text editörü ile açıp ta yapabilirsiniz. 3. kısımda ise git add . komutu ile yarattığımız dosyaları ve dosyaya eklediğimiz yazıları (bu silinme, güncelleme yada yeni bir dosya yaratma da olabilir) “staging” katmanına alıp indexledik. Şu an git status çalıştırsak önceki çalıştırdığımızda olan hata gibi görünen yazıyı almayız. 4. kısımda ise “staging” katmanındaki verileri commit ederek “Local Repository” katmanına aldık.

Şu anda git log komutunu çalıştırdığımızda ise ilk commitimizi ve hash değerimizi görebiliriz.

“.gitignore” dosyası nedir

Örneğin projemizde bize özel olan yerler var (API key vs) yada görülmesini istemediğimiz yerler var. Bunun için working directory de “.gitignore”dosyası oluşturmamız gerek ve bunun içini görünmesini istemediğimiz dosyaları yazabiliriz. Örnek gitignore dosyası için google da arama yapabilirsin.

Aşağıda ilk önce

touch .gitignore komutu ile dosyamızı oluşturdum (Aşağıda yazmıyor ama ilk önce bunu yaptım).Ardından git durumuna baktım ve bana .gitignore dosyasını commit et diyor. Commit ettim. Ardından

echo “ignore example line” > gitignoreExample.txt komutu ile hem gitignoreExample.txt dosyasını oluşturdum hem de ilk satırı yazdırdım. Bundan sonra ise

echo “gitignoreExample.txt” >> .gitignore komutunu kullanrak .gitignore dosyasına görünmesini istemediğimiz dosyanın ismini yazdırdık ve git status yaptığımızda bize sadece .gitignore dosyasında değişiklik yapıldığını söylüyor ve gitignoreExample.txt dosyasını görmüyor.

Branch Nedir ?

Branch, dallanmak demek. Örneğin bizim projemiz hastane kayıt sistemi olsun. Biz ilk önce arayüzü tasarladık ve commit ettik(1. commit) ardından login ekranını tasarladık ve commit ettik(2. commit) ve şimdi veritabanı tasarımını yapacağım fakat başka bir arkadaş ta sistemin diğer fonksiyonlarını yapacak ver oradan devam edecek. Bu arkadaşın devam etme biçimi branch olarak adlandırılır, arkadaş diğer fonksiyonları tasarlarken biz aynı projede veritabanı tasarımını yapıyoruz. Bu yüzden o arkadaş

git branch branch_name komutu ile branch açıyor. Aşağıda feat(feature) isimli bir branch açtık.

git branch feat

Ardından diğer fonksiyonlar ile çalışan arkadaş ilk görevini bitirdi ve commit etti. “git commit -m “feature ilk commit””

git commit -m “feature ilk commit”

Ardından biz de diğer göreve geçersek ve arkadaş ta geliştirmeye devam ederse görüntü şöyle olur.

HEAD ise geçerli branchi gösterir. Bizim default olarak gelen ilk branchimiz “master” branchimizdir. Bunun ismini

git branch -M new_name şeklinde değiştirebiliriz.

git branch komutu komutu bize branchleri gösterir ve o anki branchi işaretler.

git switch branch_name komutu ile branch değiştirebiliriz. (git switch master=> master branchine geri döner.)

Switch yaptığımızda bir branchtaki kaydedilenler diğerinde gözükmez. Peki bunu nasıl çözebiliriz. Bunu çözmek demek aslında branchleri birleştirmek demektir. branchleri birleştirme komutu

git merge branch_name -m “msg” Örneğin yukarıdaki örneği baz alırsak biz master branchte iken “git merge feat -m “msg”” yazarsak aslında görüntü aşağıdaki gibi olur ve artık master dan devam edilebilir.

Şimdi bunları uygulayalım.

İlk önce master da hızlıca 2. ve 3. commitlerimizi atalım ve log a bakalım.

Şimdi feat isimli branch oluşturalım.

Şimdi “git branch” komutu ile branch listesini görelim. Ardından “git switch feat” ile feat branch ına geçiş yapalım ve ilk commitimizi atalım. En son log a baktığımızda en üstte featteki commiti görebiliyoruz fakat alttakiler master’ın bunun sebebi ise biz feat branchını masterda yarattık. fakat şu andan itibaren master ve feat branchlarındaki commitler birbirinden bağımsız olacaktır.

Gördüğünüz gibi master brancha geçtim ve logta feat’in commitini göremiyorum.

Hızlıca featte ikinci commiti atalım

Ardından masterda 4. ve 5. commitleri atalım ki resimdekiler ile aynı diagramı oluşturalım.

Şimdi ise master branchte iken master ile feat’i birleştirelim. bunun için masterda iken

git merge feat -m “merged with feat” komutunu yazıyoruz ve loga bakıyoruz. Gördüğünüz gibi feat’in commitleri de artık bizde görünüyor. Birleştirme işlemi başarılı.

Stash nedir?

Şu ana kadar commit yapıpı merge ettik peki biz farklı bir branchta iken master branchına dönmemiz gerekirse ve commit etmemişsek ne olacak? Bunun için stash kullanabiliriz. Stash commit edilmemiş bilgileri diskte saklar. Bunu Staging ve Local Repository katmanları ile karıştırmayın. Bunlardan ayrı bir yerde saklar. Stash yapmak için komutumuz

git stash Bilgiyi stash’ten geri almak için ise

git stash pop komutunu kullanırız. Stash içinde birden fazla veri saklayabiliriz. Bunları görüntülemek için

git stash list komutunu kullanabiliriz. Burada saklanma sentaksı şu şekildedir: stash@{0}, stash@{1},.., stash@{i}.

git stash clear komutu ile stash listesini temizleyebiliriz.

İlk önce yukarıdaki senaryoyu uygulayalım.

feat branchına geçtim ve file.txt dosyasına “stash denemesi 1” yazdırdım. sonra master branchına geçtim ve feat e geri geldim. “git stash list” ile listeyi kontrol ettim. ve “stash denemesi 1” yazmadığından emin olmak için file.txt dosyasını yazdırdım. daha sonra “git stash pop” komutunu çalıştırdım. ve tekrardan dosyayı yazdırdığımda “stash denemesi 1” yazısını gördüm. Ardından “git stash list” komutu ile listedeki stashe baktım ve silindiğini gördüm.

Dikkat: “git stash pop” işi bittikten sonra listeyi temizler.

Dikkat:Henüz commit etmedim!!

İkinci senaryoda ise ilk senaryodaki gibi dosyaya “stash denemesi 2” yazdırdım ve “git stash” komutunu çalıştırdım. Ardından dosyayı yazdırdım ve içinde “stash denemesi 2” yok. Ayrıca fark ettiyseniz “stash denemesi 1” de yok sebebi henüz commit etmemem. Ardından master’a geçip tekrardan feat’e geçtim.“git stash list”ile listeyi yazdırdım ve stash@{0} gördüm. Şimdi ise stash listesindeki hepsini değilde bir tanesini pop etmeyi göreceğiz. Bunun için komutumuz şu:

git stash apply stash@{i}

Bunu çalıştırıp yazdırdığımda stash denemelerini görebilirsiniz. İlkini dikkate almanıza gerek yok. Fakat sonradan stash listesine baktığımızda ise stash’in silinmediğini görüyoruz.

Dikkat: git stash apply stash@{i} komutu listeden silmez.

En son bunları commit ettim.

Checkout

Şu ana kadar nasıl geriye dönüş yapacağımızı görmedik. Eğer commit yapmadıysak belirli dosya üzerinde

git restore file.txt komutu çalıştırabiliriz. Peki commit yaptıysak ne olacak? Bunun için önceki commitlere geri dönmemiz gerekli. Bunu da “git log” komutu çalıştırdığımızdaki bize verilen hashler sayesinde yapacağız. Örnek olarak şu komutu çalıştırabiliriz:

git checkout hash_value Fakat dikkat edin bunu yaptığımızda head ile branch aynı yerde bulunmayacak. Bunu gidermek için bazı yöntemler var. En basiti switch ile master a geri dönebilirsin.

Head ve branch durumunu şöyle göstereyim:

Diğer yöntem ise yeni bir branch açıp oradan devam edebiliriz. Fakat burada da bir sorun var. Ben belki aynı branchten devam etmek istiyorum.

Bunun için de reset ve revert işlemleri devreye giriyor. Bundan sonrasını yazı ile anlatacağım kafanızda canlandırabilirsiniz.

Örneğin 6 tane commitim var ve ben 4. commit’e geri dönmek istiyorum. Ayrıca 5 ve 6. committin de silinmesini istiyorum. Bunun için

git reset hash_value komutunu kullanabilirim fakat bu komut 4. committen itibaren dosyalardaki değişiklikleri silmez. Bunları manuel olarak silmek durumundayız. Şimdiki göstereceğim komut dosyalardaki değişikliği de siler ve logta tutulmaz. Yerinde kullanılmadığında birçok sorun sebebiyet verebilir. Komutumuz

git reset — hard hash_value Bir de revert işlemi var. Bu geri alma işlemidir. İlk başta 6 tane commitimiz var demiştik ve diyelim ki 6. committi çıkarmak istiyoruz projeden. bunun için revert de kullanılabilir.

git revert hash_value Fakat bunu sırayla yapmamızda fayda var yoksa karışabilir. Örneğin ilk örneğimizdeki gibi 4. commit lazım. Bunun için sırasıyla 6. ve 5. commiti revert etmeliyiz. Revert bunu logtan silmez. Yani projeye gelen yeni biri yaptığımız revert işlemini loglardan görebilir.

Ben burada reset ve reset — hard örneklerini yapacağım.

İlk önce resetExperiment.txt dosyasını açıyorum ve içine ayrı olarak sırasıyla echo komutu ile “reset exp. first line” ve “resetExp. second line” yazıyorum ve commit ediyorum. Ardından logu açıyorum ve son iki logu görüyorum.

sonra

git reset 7f1891ab8ac737564f7bf8ffc8b2b1f87fefcf14 komutunu çalıştırıyorum. ardından logu açıp son logun (en üstteki) gittiğini görüyorum. Sonra dosyayı açıp “resetExp. second line” yazısının gitmediğini görüyorum.

Şimdi de reset — hard komutuna bakalım.

Öncelikle “resetExp. second line” yazısını yazdırıp yeniden commit ediyorum. ardından logu açıp en son commiti görüyorum.

Sonra dosyayı yazdırıyorum ve iki satırı da görüyorum ardından

git reset — hard 7f1891ab8ac737564f7bf8ffc8b2b1f87fefcf14 komutu çalıştırıyorum ve bu sefer ilk önce dosyayı açıyorum 2. satırın silindiğini görüyorum ardından logu açıp son commitin silindiğini görüyoruz.

İki Commit, Dosya, Branch Arasındaki Farkı Nasıl Görürüm ?

Bunun için temel olarak

git diff komutunu kullanabiliriz. Eğer veriyi “Staging” katmanına almadıysak direk olarak “git diff” komutu çalışır.

Aşağıdaki örnekte ilk önce “diff_1” yazısı intorduction.txt’ nin içine yazdırılmıştır.

Eğer veriyi “Staging” katmanına aldıysak yani indexleme yapmışsak aradaki farkları

git diff HEAD komutu ile görebiliriz.

İki commit arasındaki farkı görmek istersek

git diff hash_1 hash_2 komutunu kullanabiliriz. Eğer yazımdan dolayı hata ile karşılaşırsanız hash1 ve hash2 arasındaki boşluk yerine “:” koyup deneyebilirsiniz.

Rebase

Bunu bir örnek ile anlatmaya çalışayım. Örneğin bizim projede iki tane branch var master ve feat. Biz feat brachında toplamda 2 sefer commit yaptık ve aynı zamanda master branchta da commitler yaptık ve ilerde feat ile master branchını merge commit yaptık. Böyle devam ede ede 3–4 tane merge commitimiz oldu. Biz bunları masterda birleştirip tek branchtan devam edebiliriz. Bu yüzden rebase işlemi yaparız. Rebase yaptığımızda öncelikle master branchler sıralanır ardından feat branchindeki commitler sıralanır. Bu işlem git loglarını (tarihlerini) değiştirir. Eğer projede çalışan başka kişiler bizim commitlerimizi kullanmaya başladıysa ve biz rebase edersek kullanan kişilerin projeleri kullanılamaz hale gelebilir. Bu yüzden dikkatli kullanmalıyız.

Kullanımı şu şeklindedir.

git rebase master