Git’in commit’leriniz ile ilgili kayıt altına aldığı tarihsel bilgileri görmek için git log komutunu kullanıyoruz.
git log komutu ile birlikte commit işlemi ile ilgili bilgilendirici çoğu bilgiyi görmekle birlikte parametre olarak -p değerini kullanırsanız dosyalarda yapılan değişiklikler de ayrıntılı olarak listelenecektir.
Son commit işleminizden sonra proje dosyalarınızda yaptığınız değişiklikleri listelemek için git status komutunu kullanabilirsiniz.
git status komutu ile git aşağıdaki 3 ana grupta yer alan dosyaları size listeler
- Changes to be committed (Commit edilmeye hazır dosyalar): Bu gruptaki dosyalar git add veya git rm komutu ile Staging Area’ya eklediğimiz dosyalardır. Bu dosyalar bir sonraki commit’imizin içinde yer alacaktır
- Changes not staged for commit (Commit için henüz hazır olmayan dosyalar): Bu gruptaki dosyalar değişiklik yaptığımız fakat henüz Staging Area’ya eklemediğimiz dosyalardır. Bu dosyalar bir önceki grubun içine eklemediğimiz sürece bir sonraki commit’e dahil olmayacaklarıdır
- Untracked files (Versiyon takibinde olmayan dosyalar): Bu gruptaki dosyalar ise henüz versiyon kontrolü altına almadığımız dosyalardır.
git rm komutu ile dosyanın bir sonraki commit’imizde yer almayacağını belirtebiliriz.
git add komutu ile dosyaların Staging Area’ya eklenmesini sağlayabiliriz.
git’de değişikliklerinizin kayıt altına alındığı üçüncü bir alan daha vardır ki buna Staging Area denir. Staging Area’yı, proje dosyalarımızdaki bir dizi değişikliği remote repository’ye göndermeden önce kayıt altında tuttuğunuz veri tabanı/alan olarak tanımlayabiliriz.
BRANCH
git branch deneme komutunu çalıştırdığınızda git sizin için projenizdeki dosyaların o anki halini barındıran deneme isimli bir branch oluşturur. Ölümcül hatalardan birisi de şudur; branch isminin repository ismi ile aynı olması durumu. Bu durum “böyle bir repo yok” hatası almanızı sağlar. En azından benim 15 dakikamı aldı 🙂
Branch’leriniz ile ilgili daha fazla ayrıntı görmek için ise git branch komutunu -v parametresi ile çalıştırabilirsiniz.
Commit işlemi ile dosyalarınızda yaptığınız değişiklikler kalıcı olarak repository’de kayıt altına alınır.
git stash ile üzerinde çalıştığınız ancak henüz commit etmediğiniz değişikliklerin geçici olarak Git tarafından kayıt altına alınmasını ve aktif branch’inizin herhangi bir değişikliğin olmadığı temiz bir duruma getirilmesini sağlarsınız.
git stash list komutunu kullanarak aktif branch’inizde geçici olarak kayıt altına aldığınız değişikliklerin listelenmesini sağlayabilirsiniz.
git stash pop komutu ile listenin en üstünde yer alan en son değişiklik geri yüklenecek ve bu değişiklik listeden silinecek.
git stash apply komutu ile istediğiniz değişikliği geri yükleyebilirsiniz. Ancak bu işlem sonrasında yüklediğiniz değişiklik listeden silinmeyecek.
Herhangi bir değişikliği listeden silmek için git stash drop komutunu kullanabilirsiniz.
Silinen git branch nasıl kurtarılır?
Geri gelmesi istenen branch ismi biliniyorsa “git reflog” komutunu çalıştır. Ardından bu branch’a en son atılmış commit id numarasını almalısın. Ardından:
git checkout -b silenen_brach_name commit_id
Stash Başka Hangi Durumlarda Kullanılabilir?
Stash işlemini üzerinde çalıştığımız aktif branch’imizi temiz bir duruma getirmek için kullanabiliriz. Bunun dışında aşağıdaki durumlarda da Git’in Stash özelliğini kullanabilirsiniz
- Farklı bir branch’i aktif hale getirmeden önce
- Remote Repository değişikliklerinizi yerel diskinize indirmeden önce
- Branch’inizi merge etmeden önce
Basit Bir Branching Akışı
git branch branchname komutunu kullanarak branch oluşturduk ve
git checkout branchname komutu ile bu branch’i aktif > hale getirdik
git merge branchname ile Commit ettiğiniz değişikliği stabil versiyonunu içeren master branch’imize merge ettik.
Daha önce üstünde çalışmakta olduğunuz yeni özellik ile ilgili değişiklikleri içeren branch’inizi aktif hale getirerek çalışmanıza kaldığınız yerden devam edebilirsiniz : git checkout yeniozellik
Checkout, HEAD ve Working Copy kavramları
Git’de bir branch otomatik olarak o branch’ın kendisi için yaptığınız en son commit işlemine bir işaretçi tutar ve hangi dosyaların o branch’e ait olduğunu bilir. Herhangi bir anda bir proje için tek bir branch aktif olabilir. Bu branch’e HEAD denir ve Working Copy içindeki (Working Copy’yi projenizin yerel diskinizdeki dosyalarının tamamı olarak düşünebilirsiniz) dosyalar aktif olan branch’e yani HEAD‘e aittir. Diğer branch’lerinizdeki dosyalar diskiniz üzerinde değil Git’in veri tabanında (.git klasörü içinde özel bir formatta) bulunur.
Farklı bir branch’i aktif hale getirmek için git checkout komutu kullanılır. Bu durumda Git otomatik olarak sizin için iki şey yapar (BURASI ÖNEMLİ!!) :
- Aktif hale getirdiğiniz branch’i HEAD yapar ve
- Aktif hale getirdiğiniz branch’e ait dosyaları Git veri tabanınızdan yerel diskinize kopyalar ve önceki branch’e ait dosyaları diskinizden kaldırır. Yani Working Copy’nize yeni branch’e ait olan dosyaları koyar.
MERGE
Stabil versiyonu olan master branch ile merge etmemiz gerekiyor (branch -> [merge] -> master). Merging en basit anlamda herhangi bir brach’de yaptığımız değişiklikleri master branch’imiz ile birleştirme veya master branch’e entegre etme işlemidir.
Kullandığınız Git çalışma pratiğine bağlı olarak herhangi bir branch’i başka bir branch’e merge edebilirsiniz.
günlük çalışmanız sırasında karşılaşacağınız diğer bir durum ise üzerinde çalıştığınız branch’e master branch’deki değişikliklerin merge edilmesidir (master -> [merge] -> branch). Bu durumu doğurabilecek aşağıdakilere benzer durumlar ile karşılaşabilirsiniz
- Büyük bir ekipte çalışıyorsunuz ve ekip arkadaşlarınız yaptıkları değişiklikleri sık sık master branch’e merge ediyorlar. Bu durumda siz de uzun zamandır üzerinde çalıştığınız branch’in master’dan geri kalmaması için merge işlemi yapmak isteyebilirsiniz.
- Tek başınıza çalışıyorsunuz ancak farklı zamanlarda farklı sebepler ile master branch’e merge ettğiniz bir çok düzeltme yaptınız. Diğer yandan da daha uzun soluklu bir çalışmanızı ayrı bir branch üzerinde yapıyorsunuz. Üzerinde çalıştığınız branch’in master’daki değişikliklerden geri kalmaması için merge işlemi yapmak isteyebilirsiniz.
Git’de merge işlemi çok basit iki adımda yapılır.
- git checkout komutu ile değişikliklerin aktarılacağı hedef branch’inizi aktif (HEAD) hale getirirsiniz.
- git merge komutu ile kaynak branch’deki commit edilmiş değişiklikler HEAD’e entegre edilir.
Git’de değişikliklerinizi merge etme işlemi sırasında kaynak branch’inizde tekil olarak hangi değişiklikleri (commit’ler) merge etmek istediğinizi teker teker söylemezsiniz. Bunun yerine Git’de doğrudan kaynak branch’inizin tamamını hedef branch’e merge edersiniz, çünkü git hangi değişikliklerin hedef branch’de bulunmadığını otomatik olarak tespit edip sadece bunların entegre edilmesini sağlar. Kaynak branch’deki değişiklikler her zaman HEAD’e yani aktif branch’iniz hangisi ise ona entegre edilir.
Merge işleminden sonra git log komutunu çalıştırdığınızda ise hangi değişikliklerimizin (commit) master branch’imize entegre edildiğini (merge) kolayca görebilirsiniz.
Kısa Vadeli / Konu Bazlı Branch’ler
Örneğin yeni özellikleri kodlarken, bug fix yaparken veya deneysel özellikler ile ilgili çalışırken istediğiniz şekilde kolayca ve hızlı bir şekilde üstelik düşük maliyetli branch’ler oluşturabilirsiniz. Bu tür amaçlar için oluşturulan branch’lerin iki ortak özelliği vardır
- Bu branch’ler tek konu veya değişiklik için oluşturulur. Örneğin size bildirilen bir hata için oluşturduğunuz branch üzerinde “GitHub İle Sisteme Giriş” benzeri yeni bir özelliği kodlamayız.
- Bu branch’ler üzerindeki çalışmanız göreceli kısa sürmektedir. Çalışmamız tamamlandığında bu branch’leri master veya daha geniş kapsamda tarif edilen bir branch’e merge edip sileriz.
Uzun Soluklu Branch’ler
İkinci türdeki branch’ler ise daha üst seviyede anlam taşırlar ve yeni özellikler, bug fix ve deneysel çalışmalar gibi odaklanmış konular yerine projenizi stabil, test ve development gibi aşamalarını temsil ederler. Bu tür branch’ler projeniz üzerinde geliştirme yaptığınız sürece varlıklarını sürdüreceklerdir. Tipik olarak bu tür branch’ler ile ilgili aşağıdaki kurallar geçerlidir
- Genelde bu tür uzun soluklu branch’ler üzerinde doğrudan değişiklik yapmazsınız. Çalışmalarınızı kısa vadeli branch’ler üzerinde yaparak değişiklikleri bu branch’lere entegre edersiniz.
- Uzun soluklu branch’ler arasında bir hiyerarşi vardır. Genellikle master branch projenizin stabil versiyonudur ve hiyerarşik olarak bir altında geliştirmelerinizi entegre ettiğiniz ve daha az stabil olabilen development branch’i yer alır.
Basit ve Faydalı Branching Stratejileri
- Sadece bir tane uzun soluklu branch kullanın
- Konu Bazlı Branchler’i Bolca Kullanabilirsiniz
- Remote ve Yerel Branch’lerinizi Senkronize Edin
- Değişikliklerinizi Sıkça Remote Branch’lere Yükleyin (Push)
Repository
Remote repository’lerde sadece Git’in veri tabanının tutulduğu .git klasörü yer alır. Local repository’ler geliştiricilerin kendi bilgisayarlarında yer alırken Remote repository’ler, çoğunlukla internet olmak üzere, ekipteki herkesin erişebileceği bir sunucuda yer alırlar.
Remote bir repository’yi yerel diskinize git clone komutu ile indirdiğinizde Git otomatik olarak bu işlemi yapmak için kullandığınız bağlantı bilgilerini hatırlar. Git bu bilgi’yi varsayılan olarak origin adı verilen remote bir repository olarak kayıt altına alır. git remote add ile local repository’miz ile remote repository’miz arasındak bağlantıyı kuruyoruz. İkinci komutumuz olan git remote -v ile de remote repositorymiz ile ilgili bilgileri görebiliriz.
fetch diğeri de push işlemleri için kullanılan iki adres bulunur. fetch adresini remote repository’den yapılacak olan okuma işlemleri, push adresini de remote repository’ye yapılan yazma işlemleri için kullanılır.
git clone komutu remote bir repository’yi yerel diskimize indirdikten sonra git branch -va komutunu çalıştırdığımızda aşağıdaki görüntüde yer alan bilgiler listelenecektir.
Dikkat edecek olursanız local repository’lerimiz hala yerinde duruyor ancak listemizde ilave olarak origin/HEAD ve origin/master isimli iki remote kaydı var.
Bu işlemin gerçekleşmesi ve sizin diğer takım arkadaşlarınızın yaptığı değişikliklerden haberdar olabilmeniz için Git’e bu bilgileri güncellemesini söylemeniz gerekir. Git’in remote repository ile ilgili yerel diskinizde tuttuğu bilgileri güncellemesini sağlamak için git fetch komutunu kullanmanız gerekir.
Fetch komutu yerel diskinizdeki branchlerinizi ve Working Copy’deki dosyalarınızı güncellemez veya değiştirmez. Bu komut ile sadece takım arkadaşlarınızın remote repository’de yayınladıkları değişikliklere ilişkin bilgiler yerel diskinize indirilir. Daha sonra bu değişikliklerden hangilerini hangi local branch’e entegre edeceğinize kendiniz karar verebilirsiniz.
git checkout komutunu –track parametresi ile kullanarak bir branch’de değişiklikler yapmak için öncelikle bu branch’i baz alarak yeni bir local branch oluşturup dosyaların Working Copy alanımıza kopyalanmasını sağlamamız gerekiyor.
git checkout –track komutu ile aşağıdaki işlemler gerçekleşir
- Remote branch ile aynı isimde local bir branch oluşturulur
- Yeni oluşturulan branch aktif hale getirilir
- –tracking parametresini kullandığımız için yeni oluşan local branch ile remote branch arasında “tracking relationship” adı verilen ve local branch’in hangi remote branch’deki değişiklikleri takip ettiğini gösteren ilişki kurulur
Remote branch’deki değişiklikleri indirmek için git fetch komutunu kullanıyoruz. Git fetch komutuna geçilen origin değeri ise daha önceki bölümlerde gösterdiğimiz remotes/origin/master isimli remote branch bağlantısına referans vermek için kullanılır.
origin değeri git fetch komutunun bir parçası değil sadece bir parametre. Origin yerine daha önce local branchimiz ile bağlantısını/ilişkisini kurduğumuz herhangi bir remote branch’i gösteren bir değer olabilir.
git fetch komutu ile remote branch’deki değişiklikleri indirdikten sonra ise git log komutunu kullanarak bu remote branch’deki değişiklikler ile ilgili bilgileri görebiliriz. (değişiklik tarihi, kimin yaptığı, değişen dosyalar ve commiti sırasında girilen mesaj gibi)
Değişiklikleri inceledikten sonra bunları local branch’inize entegre etmeye karar verdiğimizde ise git pull komutunu kullanmamız gerekecek . Git pull komutu aslında arka arkaya iki şey yapmanızı sağlar:
- Remote branch’deki değişiklikler ile ilgili bilgileri indirmek, yani git fetch
- Remote branch’deki değişiklikleri local branch’inize entegre etmek yani git merge
- git fetch : remote’dan güncelleme bilgilerini indir
- git diff : remote ve local arasındaki farkları incele
- git merge : değişiklikleri otomatik merge et çakışma varsa bir sonraki adıma geçin
- Çakışma olan dosyalarınızı açın ve çakışmaları düzeltin
- git add: çakışmanın giderildi ve değişiiklik Staging Area’ya alındı
Local Bir Branch’i Yayınlamak (Publish)
Önce git checkout komutu ile branch’imizi aktif hale getiriyoruz ve sonra git push komutu ve -u seçeneği ile local branch’imizi remote repository’mizde yayınlıyoruz. -u seçeneği ise local branchimiz ile remote branchimiz arasında, önceki bölümlerde de bahsettiğimiz, Takip İlişkisi (Tracking Relationship) kurulmasını sağlar.
Local branch’i remote repository’de yayınladıktan sonra local branch’de yaptığımız değişiklikleri git push komutunu parametresiz kullanarak remote branch’imizde yayınlayabiliriz.
Branch’leri Silmek
Bu branch’i kendi bilgisayarımızdan silmek için git branch -d name komutunu, remote repository’den silmek için de git branch -dr name komutunu kullanabiliriz.
Silmek istediğiniz local branch aktif ise git branch -d komutu hata verecektir. Silme işlemi öncesinde sileceğiniz local branch’den farklı bir branch’i git checkout komutu ile aktif hale getirmeyi unutmayın.
NOT : -d seçeneği, yalnızca ilgili branch önceden push edilerek merge işlemi yapıldı ise siler. Henüz push edilmemiş veya merge edilmemiş olsa bile branch’ı silmeye zorlamak istiyorsanız, bunun yerine -D’yi kullanın.
Remote branch’i git branch -dr komutu ile sildiğiniz halde remote repository’ye erişip branchleri kontrol ederseniz name isimli branch’in sunucuda hala durduğunuz göreceksiniz. Bunun nedeni git branch -dr komutundaki seçeneklerden r seçeneğinin sunucudaki branch’i değil yerel bilgisayarınızda remote branch bilgilerini siler. Bu değişikliğin sunucuda da geçerli olması için yani sunucudaki branch’i de silmek için git push origin :name komutu ile değişikliği bir anlamda remote repositry’de yayınlamanız gerekiyor.
Commit İşlemleri
Kısa Commit’ler ve Anlaşılır Commit Mesajları
İlgili branch’e commit yaparken bir seferde bütün her şeyi commit’lemekten ziyade kısa kısa paketler halinde yaptığınız geliştirmeleri commit edin ve anlaşılır commit mesajları kullanmaya çalışın. Böyle yaparak her şeyi step-by-step açıklamış olacaksınız ve hem review yapacak kişi için kolay anlaşılabilir olacak hemde kendiniz için geriye dönüp baktığınızda yaptığınız geliştirmeyi hatırlaması daha kolay olacaktır.
Dev ortamda yaptığınız geliştirmeleri review eden kişi eğer herhangi bir sorun görmez “OK” verir ise master branch’ine merge işlemini yapabilirsiniz.
Son commit işleminizi yeniden yapmak için git commit komutunu –amend seçeneği ile kullanabilirsiniz. Sadece commit mesajınızı değiştirmek istiyorsanız — amend -m seçenekleri ile git commit komutunu çalıştırabilirsiniz, eğer son commit’e dosya eklemek veya dosya çıkarmak isterseniz commit komutundan önce önceki bölümlerde de bahsettiğimiz git add ve git rm komutları ile önce Staging işlemini yapabilirsiniz. En son commit’in ismini değiştirir:
git commit --amend -m "New commit message.
git commit komutunun –amend seçeneği commit hatalarımızı hızlıca ve kolayca düzeltebilmemiz için oldukça faydalı bir seçenektir. Bu seçenek sadece son commit işlemimizi düzeltmemizi sağlar, önceki commitlerimizi bu seçenek ile düzeltemeyiz
Henüz commit etmediğimiz değişikliklere Local değişiklik denir. Dosyanın son commit edilmiş haline geri dönmek istediğinizde, önceki bölümlerde de sıkca kullandığımız, git checkout komutunu — seçeneği ile çalıştırmanız yeterli olacaktır.
git checkout — dosya1.md veya
$ git checkout — klasor/dosya2.md şeklinde kullanılır.
Tüm dosyalarda yaptığınız değişiklikleri geri almak istiyorsanız git reset komutunu –hard seçeneği ile kullanabilirsiniz. Yani local üzerinde eski commit’e dönebilmek için git-reset komutu yeterli olmaktadır.
$ git reset –hard HEAD
veya şöyle gösterilebilir —- > git reset --hard <commitID>
Bu komut ile Git tüm dosyaların son commit edilen değişiklikleri içeren HEAD versiyonundaki hallerinin Working Copy’nize geri yükler. Bu komut ile uzak depodaki verilen commit numarasına kadar olan kodlar getirilir. Local üzerinde yaptığınız değişikliğiniz bulunuyorsa da bunları da otomatik olarak silmektedir.
git checkout — ve git reset –hard komutları sonrasında kayıt altına alınmamış olan tüm değişiklikler geri dönüşü olmayacak şekilde yok olur. Bu nedenle bu komutları çalıştırırken dikkatli olmalısınız ve iki defa düşünmelisiniz.
git checkout <commitID>
git checkout <commitID> -- <filename>
Burada da ilk satırda tüm dosyalar verilen commit numarasına göre geri çekilir. İkinci satırdaki komut ile ise tek bir dosya eski versiyona geri döndürülür.
git revert komutu commit ettiğiniz herhangi bir değişikliği geri almak için kullanılır. Bu komut ile commit işleminizin kendisi veya bilgileri silinmez sadece commit işleminizdeki değişiklik geri alınır. Aslında git revert komutu değişikliğinizi geri almak için otomatik olarak yeni bir commit oluşturur ve geri alma işlemi bu commit sayesinde değişiklik tarihçesinde görünür hale gelir. Bu komutun en önemli parametresi geri almak istediğimiz commit’in hash değeri (hash’in ilk yedi karakterini kullanabiliriz).
Değişiklikleri geri almak için kullanabileceğimiz diğer bir komut ise git reset komutu. Bu komut da herhangi bir bilginizi silmeden işlemi gerçekleştirir, ancak git revert komutundan farklı olarak otomatik yeni bir commit üretmeden değişikliğinizi geri almanızı sağlar.
Bu komut için de git revert komutunda olduğu gibi geri almak istediğimiz commit’in hash değerini veriyoruz. Kullandığımız diğer bir seçenek olan –hard seçeneği ise local tüm commitlerinizi silerek geri alma işleminin yapılmasına neden olur, bu nedenle –hard seçeneğini kulllanırken dikkatli olmalısınız. Local commit’lerinizin korunmasını istiyorsanız –keep komutunu kullanabilirsiniz.
Git deposundan remote bağlantıyı kaldırma
Kaldırmak ve yeniden eklemek yerine bunu yapabilirsiniz:
git remote set-url origin git://new.url.here
Uzaktan kumandayı kaldırmak için şunu kullanın:
git remote remove origin
Kısaca remote depoyu ekleme ve güncelleme adımları :
- Repository oluştur
- git init
- yeni bir dosya oluştur veya bir doyanda değişiklik yap
- git branch -M main
- git add .
- git commit -m “ilk commit”
- git remote add origin https://github.com/deneme.git
- git push -u origin main
Git cherry-pick nedir?
Git cherry-pick, bir Git deposundan bir veya daha fazla commit’i seçerek ve bunları geçerli çalışma koluna uygulayarak bir commit dizisi oluşturmak için kullanılan bir komuttur. Bu, belirli bir düzeltmeyi veya özelliği bir geliştirme kolundan ana koluna veya başka bir koluna taşımak için kullanışlıdır.
Cherry-pick komutunu kullanmak için, önce cherry-pick etmek istediğiniz commit’leri seçmeniz gerekir.
İşte cherry-pick’in bazı yaygın kullanımları:
Bir düzeltmeyi veya özelliği bir geliştirme kolundan ana koluna veya başka bir koluna taşımak
Bir hata düzeltmesini veya özelliğini, çalışma kolunuzun tarihini değiştirmeden eski bir sürüme geri taşımak
Bir commit dizisini, çalışma kolunuzun tarihini değiştirmeden başka bir depoya taşımak
kaynak :
Salih's Space 