Code Versiyon Yönetim Sistemi

1. GIT
Ddemirel / 20190403

2. Versyion Kontrolü
• Çalıştığımız bir belge üzerinde çalışırken
belgenin daha önceki hallerine erişmek isteriz.
Bu durumda belgenin önceki hallerinin bir yerde
saklanması gerekir.
• Bu durumda belgenin her bir haline belgenin
versiyonu denir.

3. Versyion Kontrolü
• Git sisteminde dosyaların ve dosya
versiyonlarının saklandığı yapılara «repository»
denir.
• Herhangi bir dosyanın geçmiş versiyonlarına
repository üzerinden erişebiliriz.
• Bir dosyanın kim tarafından ne zaman
değiştirildiğini izleyebiliriz.
• Değişiklik yapıldığında iz bırakmadan repo
üzerine değişiklik eklenemez.

4. Çeşitleri
• Local
▫ Ör. Microsoft Office belge saklama yöntemi
• Merkezi
▫ Subversion(SVN)
• Dağıtık
▫ Git

6. Distributed Version Control

7. Temel Git İşlemleri

8. Depo Oluşturma
• git init
▫ .git : git’in veritabanıdır. Repo üzerinde yapılan
tüm işlemler dosyalar aracılığıyla bu dizinde
tutulmaktadır.

9. Depoya Dosya Ekleme
• git status
▫ Repositorynin durumunu kontrol eder
• git add –all
▫ Repoya eklenmemiş tüm dosyalar repoya eklenmek
üzere işaretlenir
▫ Fakat tam olarak repoya eklemek için commit yapmak
gereklidir
• git commit –m «initial commit»
▫ Artık dosyalar kalıcı olarak bir log ile birlikte local
repoya eklenmiş durumdadır.
▫ -m parametresi zorunlu olarak commit mesajı girmeyi
sağlar
• git status

10. Depodan Dosya Silme
• git status
• git rm «filename»
• git commit –m «mesaj»
• git status

11. Git Ignore
• Ide’lerin ya da build araçlarının oluşturduğu
dosyaları repolarda tutmak istemeyiz, bu
durumda ignore listesi bize yardımcı olur.
• .gitignore
▫ *.iml
▫ /*/target
▫ /.idea

12. git config
• Git için genel ve kullanıcı bazlı konfigürasyon
yapmayı sağlar
• git config --global user.name Dilaver Demirel
• git config --global user.email dilaver@gmail.com
• Git komutları için alias oluşturabiliriz
▫ git config --global alias.st status
▫ git st = git status

13. Bare(Yalın) Depo
• Git dosyalar üzerinde yapılan işlemleri .git
klasöründe tutar. Fakat dosyaların orjinalleri üst
klasörde tutulur.
• Bir repo klonlandığında oluşan local repo
working copy olarak adlandırılır.

14. Bare(Yalın) Depo
• Merkezi sunucuda tutulan reponun yalın olarak
tanımlanması tercih edilmektedir.
• Yalın repo ; önceki slaytta bahsettiğimiz gibi
repodaki dosyaların tüm bilgisi .git üzerinde
tutulmaktadır. Dosyaların kopyalarının olmadığı
orijinal dizinde olmadığı repolara yalın repo
denilmektedir.
• Yalın depolara doğrudan dosya eklenemez, clone
yapılıp add,commit,push ile yapılabilir.

15. Yalın Depo Yapısı

16. git clone
• Git reposunun kopyasını oluşturmayı sağlar
• git clone demo1.git demo1-clone
▫ cd demo1-clone
▫ touch test.txt
▫ echo «test» > test.txt
▫ git status
▫ git add --all
▫ git commit –m «ilk commit»
▫ git push

17. git clone
• git clone demo1.git demo1-clone2
▫ ls
 test.txt
• Doğru bir şekilde dosya eklemenin merkez
repoya eklendiğini gördük.

18. git pull
• Merkez repoya eklenmiş olan değişikliklerin
clone repolara alınabilmesi için «pull» komutu
kullanılmaktadır.

19. git log
• Repo üzerinde yapılan her işlem bir log olarak
eklenir. Eklenen bu logların ya da yapılan
değişkliklerin neler olduğunu bu komut ile
görebiliriz.
• git log
• git log --oneline
• git log –n 3 --oneline
• git log --stat
▫ istatistikler
• git log -p
▫ Dosya içeriklerinin detayları
• git log --author =«Dilaver Demirel»
• git log «fileName»

20. git log
• 0f242f1294ee393a8d3c6f6b98c52d0f767c8465
▫ Bu numara commit hash olarak
adlandırılmaktadır.
▫ Commit işlemi yapılırken git SHA-1 algoritması ile
bir hash değeri hesaplamaktadır.
• git show 0f242f1
▫ O commit ile yapılan değişiklikler bu komut ile
izlenebilir.
▫ Commit hash kodunun ilk 7 hanesini kullanmak
yeterlidir.

21. git log

22. Son Commitin Değiştirilmesi
• Son yaptığımız commite eklemeyi unuttuğumuz
bir dosyayı sonradan ekleyebiliriz.
• --amend parametresi ile yapılır
▫ touch dosya1.txt
▫ git add dosya1.txt
▫ git commit -m «dosya1 eklendi»
▫ git log --oneline
▫ git status
▫ touch dosya2.txt
▫ git add dosya2.txt
▫ git commit --amend
▫ git log --oneline

23. git revert–Değişikliklerin Geri Alınması
• Mevcut bir commitin geri alınmasını sağlar
• Geri alma işlemi yaparken loglara bu işlemin
yapıldığına dair bir log kaydı oluşturur.
• Aynı dosya üzerinde farklı commitler varsa
aşamalı revert yapılabilir.
▫ touch dosya3
▫ git add dosya3
▫ git commit –m «dosya3 eklendi»
▫ git log --oneline
▫ git revert 8683a1c
▫ git log --oneline

24. Tag – Etiket Kullanımı
• Yazılımda bazı zamanlarda örneğin yeni
versiyon geçişinde, kodların etikenmesi
gerekmektedir.
• Kodun o halinin bir kopyasını oluşturur
• Oluşturulan etiket kopyalarına sonradan
erişilebilir
▫ git tag
▫ git tag –a v1.0 –m «1.0 versiyonu tamamlandı»
▫ git tag –v1.o
• Komutlar son commiti baz alarak etiket
oluşturur

25. Tag – Etiket Kullanımı
• Eski bir commit referans alınarak da tag
oluşturulabilir.
▫ git tag -a v1.0 -m 'version 1.0' 55962fc
• Oluşturulan etiketleri remote depoya iletmek
gereklidir
▫ git push origin --tags
• Tag’e erişme
▫ git checkout tags/<tag_name>
▫ Tag’den branch oluşturma
 git checkout tags/<tag_name> -b <branch_name>

26. Akış

27. Branch Yönetimi
Commit-1 Commit-2
İstenen Yeni Özellik – 1
Tamamlandı
İstenen Yeni Özellik – 2
Yarım Kaldı
Hafta - 1 Hafta - 2
Commit-3-4-5 Commit-6-7
Release
MainBranch

28. Branch Yönetimi
Commit-1
İstenen Yeni Özellik – 1
Tamamlandı
İstenen Yeni Özellik – 2
Yarım Kaldı
MainBranch
Commit-2
Commit-1
Commit-1
Branch-1
Branch-2

29. Branch Yönetimi
• Main Branch : Sürüm oluşturmak için kullanılan
ve yan dallarda yapılan değişikliklerin toplandığı
daldır.

30. Branch Yönetimi
• Branch listesi
▫ git branch
• Branch oluşturma
▫ git branch branch-1
• Branch silme
▫ git branch -d branch-1
• Branch değiştirme
▫ git checkout branch-1
▫ Branch değiştirildiğinde working-copy git
tarafından değiştirilir

31. Branch Yönetimi
• Branch’lar genelde aynı kod üzerinde farklı
konularda izole olarak çalışmayı sağlar
• Bu durum istenilen özellik bazında
değerlendirilebilir.
• Bu konsepte «feature-branch/bugfix-branch»
adı verilmektedir.

32. Dalların Budanması
• Yan dallar üzerindeki değişiklikler süreç
tamamlandıktan sonra ana dala aktarılmalıdır.
• Yan dallar ana dala birleştirilmezse farklı kod
yapıları oluşur ve bu kargaşaya sebep olabilir.
• Yan dal ana dala aktarıldıktan sonra silinmelidir.

33. Branch Yönetimi
Commit-1
İstenen Yeni Özellik – 1
Tamamlandı
MainBranch
Commit-2
Commit-1
Branch-1

34. Dal Budama Örnek
• Yapının oluşturulması
▫ mkdir demo2.git
▫ cd demo2.git
▫ git init
▫ touch dosya1 dosya2 dosya3
▫ echo «dosya1 içerik» > dosya1
▫ git add --all
▫ git commit –m «dosyalar eklendi»
▫ git checkout –b branch-1
▫ touch dosya4 dosya5
▫ git add --all
▫ git commit –m «dosya 4-5 eklendi»
▫ git checkout master
▫ git log --oneline
▫ git checkout branch-1
▫ git log --oneline
▫ git checkout master
▫ git branch

35. Dal Budama Örnek – Fast-Forward
• Branch-1 deki «dosya1» üzerinde eklemeler
yapılır
▫ git checkout branch-1
▫ cat dosya1
▫ echo satir2 >> dosya1
▫ git status
▫ git commit –m «dosya1 değiştirildi»

36. Dal Budama Örnek – Fast-Forward
• Branch-1 deki değişiklikler «master» branch’e
alınır
▫ git checkout master
▫ git merge branch-a
▫ cat dosya1
• «Fast-forward» merge işlemi yapılırken
herhangi bir conflict olmadan işlemin
tamamlandığını ifade eder.

37. Dal Budama Örnek – Conflict
• Branch-1 ve master da olan «dosya2» üzerinde hem
branch-1 de hemde master’da değişiklik yapalım
▫ git checkout branch-1
▫ echo «satir1» >> dosya2
▫ git commit –m «branch-1 dosya2 değiştirildi»
▫ git checkout master
▫ echo «satir2» >> dosya2
▫ git commit –m «master dosya2 değiştirildi»
▫ git merge branch-1
 Auto-merging dosya2
 CONFLICT (content): Merge conflict in dosya2
 Automatic merge failed; fix conflicts and then commit the
result.

38. Dal Budama Örnek – Conflict
• Branch-1 ve master da olan «dosya2» üzerinde
hem branch-1 de hemde master’da değişiklik
yapalım
▫ cat dosya2
▫ git diff
▫ git mergetool
▫ git commit –m «branch-1 merge edildi»
▫ git log --oneline
▫ git log –graph
▫ git reflog
 Deponun tarihçesi

39. git reset --hard HEAD@{4}
• Reset komutuyla tarihçedeki herhangi commite
geri dönebiliriz
▫ git reflog
▫ git reset --hard HEAD@{4}

40. Dal Budama Örnek – Rebase
▫ /--commit—commit---branch1
▫ |--commit---|---commit—commit---master
▫ /---commit---branch1
▫ |--commit------commit…--|--master
▫ Branch1 masterdaki ilk commiti referans almıştır
fakat master dal üzerinde de geliştirmeler
yapılmıştır.
▫ Branch1’i masterdaki son commitin üzerine
taşımak için rebase işlemi yapılır.

41. git rebase - Örnek
• mkdir demo3
• Cd demo3
• Git init
• Touch dosya1 dosya2
• Echo «satir1» >> dosya1
• Git add –all
• Git commit –m «dosyalar eklendi»
• Git branch branch-1
• Git checkout branch-1
• Echo «satir2» >> dosya1
• Git add –all
• Git commit –m «satir2 eklendi»
• Git checkout master
• Echo «satir3» >> dosya1
• Git add –all
• Git commit –m «satir3 eklendi»
• Echo «satir4» >> dosya1
• Git add –all
• Git commit –m «satir4 eklendi»

42. git rebase - Örnek
Master Branch-1
------------------------------------------------
Satir1 Satir1
Satir3 Satir2
Satir4
Sonuç
------------------------------------------------
Satir1
Satir3
Satir4
Satir2
• Git checkout branch-1
• Git rebase master

43. git clean
• Dizinde bulunan fakat henüz «add» komutu ile
indexe eklenmemiş tüm değişiklikleri
temizlemeyi sağlar.
▫ touch dosya7
▫ touch dosya8
▫ git clean –n
 Nelerin silineceğini gösterir
▫ git clean -f

44. git checkout
• Dallar arası geçiş yapmamnın yanı sıra
commitler arası geçiş yapmayı da sağlar.
▫ git log --oneline
▫ git checkout 0dd227f dosya1
▫ git checkout 0dd227f
 Tüm commitin içeriğine geri dönebiliriz
 Bu işlem sonrası detach moda düşülür ve kod
üzerinde yapılan işlemlerin anlamı olmaz, çünkü
commitlenemez

45. Özet
• Git checkout komutu ile hem yeni bir dal oluşturmak hem de mevcut bir
dala yan geçiş yapmak mümkündür
• Git branch komutu ile depoda yer alan dalların listesi edinilebilir.
• Git merge komutu ile dalların içerikleri birleştirilebilir.
• Git reflog komutu ile yerel bir deponun tarihçesini yani dal bünyesinde olup
bitenlerin listesini edinmek mümkündür.
• Rabase işlemi esnasında fast-forward-merge yöntemiyle mevcut dalın temel
aldığı daldaki değişiklikler mevcut dala aktarılır. Mevcut dal üzerinde
yapılan tüm değişiklikler bu merge işlemi esnasında oluşan en son commit
nesnesini baz alacak şekilde yeniden yapılandırılırlar. Rabase işleminin
başlıca sebebi, bir uygulama özelliğini implemente ederken oluşan
değişiklikleri ana dalda meydana gelen değişiklikler üzerine inşa etme
arzusudur.
• Git revert komutu ile deponun tarihçesini değiştirmek mümkün iken, git
reset komutu ile mevcut çalışma alanının (working copy) ve indexin
içeriğini değiştirmek mümkündür.
• Clean komutu ile dizin içinde bulunan ve indexe henüz eklenmemiş tüm
değişiklikleri yok edebiliriz.