3. GIT BASICS
WHAT IS GIT
▸ A Version Control System
▸ Linus Torvalds in 2005 (Linux
Creator)
▸ Distrubuted, Local Repository
support, Fast Speed, Strong
support for branch based
development.
▸ Everybody use git (Facebook,
Eclipse, PHP, GittiGidiyor:)
4. GIT BASICS
$ mkdir uberproject
$ cd uberproject
$ git init
Initialized empty Git repository in /Users/kivanc/Projects/uberproject/.git/
Bir repository yaratmak için, herhangi bir dizinde git init komutunu çalıştırmanız yeterlidir.
Dizinin boş olmasına gerek yoktur.
—bare parametresi kullanıldığında working directory’si olmayan bir repository yaratılır. Central
repository bare repository olarak yaratılması tercih edilir.
git init
git init --bare /dir/uberproject.git
INITIALIZE REPOSITORY
4
6. GIT BASICS
$ git clone https://github.com/kivancerten/php_game_of_life.git
Cloning into 'php_game_of_life'...
remote: Counting objects: 38, done.
remote: Total 38 (delta 0), reused 0 (delta 0), pack-reused 38
Unpacking objects: 100% (38/38), done
git clone uzak repository’i kopyalar. Clone işlemi, otomatik olarak uzak repository ile origin isminde
bir bağlantı yaratır.
Eğer bir proje halihazırda uzak bir repository de bulunuyor ise git clone, local geliştirmeye
başlamak için en çok tercih edilen yöntemdir.
git clone <repo> <directory>
CLONE A REPOSITORY
6
7. GIT BASICS
GIT CONFIG
7
Git config, git le ilgili tüm konfigurasyonların yapıldığı komuttur. Kullanıcı kimlik bilgisinden,
varsayılan text editöre kadar birçok ayar bu komut ile yapılır.
git config user.name “Kivanc Erten"
git config --global user.name “Kivanc Erten"
git config --global user.email kivanc@kivanc.com
git config --system core.editor vim
git config alias.st status
<repo>/.git/config – Repository’e özgü ayarlar.
~/.gitconfig – Kullanıcıya özgü ayarlar —global parametresi kullanıldığında buraya yazılır.
$(prefix)/etc/gitconfig – Sisteme özgü ayarlar. —system parametresi. O makinedeki tüm repository
ler için geçerli ayarlar.
8. GIT BASICS
GIT AREAS : WORKING DIRECTORY - STAGE - REPOSITORY
8
Git’te dosyalarınızın olabileceği 3 farklı durum vardır. Modified, Committed, Staged.
Committed : Değişikliklerin veritabanına kaydedilmiş ve verinin güvenli olduğu durum. Snapshot.
Staged : Değişiklik yapılan dosyanın bir sonraki commit ile kaydedilmek için işaretlenmiş olduğu durum.
Modified : Değişiklik yapılmış ancak kaydedilmemiş durum.
9. GIT BASICS
SAVING CHANGES 1/2
9
git add komutu working directory deki değişlikleri staging area ya taşımaya yarar. Değişikliklerin bir sonraki
commit de güncellenmesini istediğimizi bu şekilde belirtiriz.
git add <dosya>
git add <dizin>
$ git status
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
# test.txt
$ git add test.txt
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: test.txt
10. GIT BASICS
SAVING CHANGES 2/2
10
git commit komutu staging area daki değişikliklerin repository’ye kaydedilmesi için kullanılır.
Commit edilmiş değişiklikler local repository de (veritabanı da diyebiliriz) saklanır.
Git’te delta değişiklikler değil snapshot lar tutulur. Her commit eşsiz bir SHA-1 hash codu ile git history’sine
kaydedilir.
git commit #Commit mesajı girilmesi için text editör açar
git commit -a #Değişiklik yapılmış tüm dosyaları ekleyerek commit
git commit -m “<mesaj>” #Commit mesaji belirtilerek commit.
git commit -a —m “<mesaj>”
git commit —ammend #Bir önceki commite değişiklik eklemek için kullanılır.
16. GIT BASICS
LOOKING THE REPOSITORY 1/2
16
git status komutu hangi dosyaların, hangi durumda olduğunu görmek için kullanılır.
Bu durumlar şunlardır : staged, unstaged, untracked
# Edit hello.php
$ git status
# hello.php is listed under "Changes not staged for commit"
$ git add hello.php
$ git status
# hello.php is listed under "Changes to be committed"
$ git commit
$ git status
# nothing to commit (working directory clean)
17. GIT BASICS
LOOKING THE REPOSITORY 2/2
17
git log komutu daha önce commitlenmiş snapshot’ların listelenmesi, filtrelenmesi ve aranması için
kullanılır. Repository’nin geçmişini gösteren bir listedir.
git log
git log -n <limit>
git log --oneline
$ git log
commit ae5be5af8f4a9808e94580a79a68ce36f59eb946
Author: kivancerten <kivanc@kivanc.com>
Date: Mon Feb 3 10:03:30 2014 +0200
Update Game.php
commit 42964c4acc3f2848a703e5e4f3ca389bec755797
Author: kivancerten <kivanc@kivanc.com>
Date: Mon Feb 3 09:59:52 2014 +0200
Update Display.php
commit 0c7bd79d07521923484c4766366860bf8279d4f9
Author: kivancerten <kivanc@kivanc.com>
Date: Mon Feb 3 09:32:47 2014 +0200
Update README.md
18. GIT BASICS
BRANCHING & MERGING
18
Git birbirinden tamamen bağımsız birçok yerel branch’iniz olmasına imkan sağlar. Bu branchlerin yaratılması,
birbirleri ile merge edilmesi ve silinmesi sadece saniyeler alır. Git bu işlemlerin yapılmasını oldukça
kolaylaştırır.
$ git checkout -b new-branch
Switched to a new branch “new-branch“
$ vim index.php
$ git commit -am “Kullanıcı verisi validasyonu eklendi"
Created commit 670e353: Kullanıcı verisi validasyonu eklendi
1 files changed, 15 insertions(+), 1 deletions(-)
$ git checkout master
Switched to branch "master"
$ git merge new-branch
Updating e53ac7a..670e353
Fast forward
index.php | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
20. GIT WORKFLOWS
CENTRALIZED WORKFLOW
20
Merkezi repository birisi tarafından yaratılır.
ssh user@host git init --bare /path/to/repo.git
Geliştiriciler, projeyi merkezi repodan kendi çalışma
ortamlarına git clone komutu ile download ederler.
Git clone repository’yi download ettikten sonra, origin adında
bir remote bağlantı ile clone edilen central repository ile local
repository arasında bağ oluşturur.
git clone ssh://user@host/path/to/repo.git
21. GIT WORKFLOWS
CENTRALIZED WORKFLOW
21
Centralized Workflow’u bir örnek üzerinden açıklamaya çalışalım.
Ali ve Ayşe git clone komutu ile remote repository’yi kendi
çalışma ortamlarına download ederler.
git clone ssh://user@host/path/to/repo.git
22. GIT WORKFLOWS
CENTRALIZED WORKFLOW
22
Ayşe kendi geliştirmelerini yapıp commit ler.
Henüz centralized repository’ye push etmez.
git status # View the state of the repo
git add <some-file> # Stage a file
git commit # Commit a file</some-file>
23. GIT WORKFLOWS
CENTRALIZED WORKFLOW
23
git status # View the state of the repo
git add <some-file> # Stage a file
git commit # Commit a file</some-file>
Ali de kendi geliştirmelerini yapıp commit ler.
O da centralized repository’ye push etmez.
24. GIT WORKFLOWS
CENTRALIZED WORKFLOW
24
Ayşe kendi yaptığı değişiklikleri central repository’ye
göndermek ister ve git push komutunu kullanır.
git push origin master
origin in daha önce Ali ve Ayşe’nin git clone komutu ile
remote repository’den projeyi download ederlerken oluşan
uzak bağlantı olduğunu unutmayalım.
Ayşe projeyi git clone ile download ettiğinden beri central
repository’de herhangi bir güncelleme olmadığından, git
push komutu beklendiği gibi çalışır. Herhangi bir conflict
olmadan commitler local repository den central repository’ye
gönderlilir.
25. GIT WORKFLOWS
CENTRALIZED WORKFLOW
25
Ali kendi yaptığı değişiklikleri central repository’ye göndermek
ister ve git push komutunu kullanır.
git push origin master
error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
?
Ali central repository’deki değişiklikleri kendi local çalışma ortamına
alabilmek için iki ayrı yaklaşımdan birini seçmek durumundadır.
merge veya rebase
26. GIT WORKFLOWS
CENTRALIZED WORKFLOW - REBASE
26
git pull --rebase origin master
—rebase parametresi Git’e ilk önce centralized repository’deki değişiklikleri local’e almasını, ardından
Ali’nin yaptığı değişiklikleri bunların üzerine eklemesini söyler.
Ali’nin değişiklikleri commit history de en sonda görüntülenecektir.
—rebase parametresi kullanılmaz ise Git varsayılan olarak merge işlemi yapıp, fazladan bir merge
commit oluşturacaktır. Centralized Workflow yaklaşımında rebase işlemi doğrusal bir history oluşturduğu
için ve fazladan bir merge commit’e gerek kalmadığı için tercih edilmektedir.
27. GIT WORKFLOWS
CENTRALIZED WORKFLOW - REBASE
27
git pull --rebase origin master
—rebase parametresi ilk önce centralized repository’den gelen commit’leri, local repository’ye çekip,
local ve remote repository’yi senkronize eder.
Daha sonra local deki yeni commitleri (Ali’nin commitlerini) tek tek merge etmeye çalışır. Tüm
commitlerin bir seferde merge edilmesi yerine, her commit tek tek merge edilir. Bu sayede büyük bir
conflict resolve etmek yerine her adımda küçük değişiklikler resolve edilir.
Bu method, History nin daha okunabilir olmasını ve olası bir geri dönme durumunu kolaylaştırmayı
sağlar.
Ali eğer var ise merge conflict’lerini resolve etmelidir.
28. GIT WORKFLOWS
CENTRALIZED WORKFLOW - REBASE
28
CONFLICT (content): Merge conflict in <some-file>
git rebase —continue Git’e conflict çıkan commit in resolve edildiğini, sıradaki commit in merge
işlemine geçilmesini söyler. Tüm commitler merge edildikten sonra origin’e push edilir.
Git commitleri sıra sıra merge ederken conflict çıkar ise aşağıdakine benzer
bir mesaj ile karşılaşırız.
$ git status
# Unmerged paths:
# (use "git reset HEAD <some-file>..." to unstage)
# (use "git add/rm <some-file>..." as appropriate to mark resolution)
#
# both modified: <some-file>
git add <some-file>
git rebase --continue
git push origin master
29. GIT WORKFLOWS
FEATURE BRANCH WORKFLOW
29
‣ Feature Branch modelinde central repository hala kullanılır ve master branch
projenin tüm history’sini tutmaya devam eder.
‣ Geliştiriciler direkt olarak master branch’e commit’lemek yerine, yeni bir iş üzerinde
çalışmaya başlarken o işe özel bir branch (feature branches) yaratılır. Tüm
geliştirmeler o branch üzerinden yürütülür.
‣ Feature branch’ler anlamlı bir isme sahip olmalıdır. Örneğin: feature/issue-6729
ya da navigation-bar
‣ Git’in işleyişi açısından master branch ile feature branch’ler arasında teknik bir ayrım
yoktur. Geliştirici master branch üzerinde yaptığı hertürlü işlemi feature branch
üzerinde de yapabilir (commit, add, stage, merge, vs).
‣ Feature branch’ler central repository’ye gönderilir ve gerekiyorsa diğer geliştiriciler
ile ortak çalışılablir.
‣ master branch nihayetinde tüm branch’lerdeki değişiklikleri içerecek olan, güvenilir,
test edilmiş, çalışan kodların bulunduğu tek branch dir.
‣ master branch tüm proje varlık süresi boyunca hayatta olan tek branch’dir.
30. GIT WORKFLOWS
FEATURE BRANCH WORKFLOW - PULL REQUEST
30
Geliştirici bir iş üzerinde çalışmasını bitirdiğinde feature branch’i master’a merge etmek
yerine Bir Pull Request ya da Merge Request oluşturur.
Pull Request direkt olarak git in bir özelliği değil, github, bitbucket, gitlab gibi repository
yönetim araçlarının bir özelliğidir.
Gitlab Bitbucket Github
31. GIT WORKFLOWS
FEATURE BRANCH WORKFLOW
31
git checkout -b new-feature-branch master
Feature Branch Workflow’u bir örnek ile açıklayalım.
Ayşe master branch den yeni bir feature branch yaratarak çalışmaya başlar.
32. GIT WORKFLOWS
FEATURE BRANCH WORKFLOW
32
git push -u origin new-feature-branch
Ayşe new-feature-branch üzerinde geliştirmelerini yapar.
Central rapository’ye push edip yemeğe çıkar. Bir süre bilgisayardan
uzaklaşırken yapılan değişiklikleri push etmek faydalıdır, çünkü yaptığımız
değişikliklerin bir yedeğini central repository’ye göndermiş oluruz.
git status
git add <some-file>
git commit
33. GIT WORKFLOWS
FEATURE BRANCH WORKFLOW
33
git push
Ayşe yemekten döndükten sonra çalışmalarını tamamlar. İşlerini master a merge
etmeden önce Pull Request (github) ya da Merge Request (gitlab) oluşturur.
Bunu yapmadan önce tüm çalışmalarını central repository’ye gönderdiğinden
emin olmak için git push yapar.
34. GIT WORKFLOWS
FEATURE BRANCH WORKFLOW
34
Ali, Pull Request’i alır. Bu aşamada code review yapılır, kod üzerinde tartışılır vs.
Gitlab, Github ve Bitbucket bu aşamada yeni gelen değişikliklerin
görülebildiği, yorum yazılabilen bir arayüz sunar.
Ali işi Ayşe’ye geri göndemeye karar verir. Ayşe değişiklikleri yaptıktan sonra
tekrar tekrar push eder bu işlem iki kişi hem fikir olup kod master a gidecek
duruma gelene kadar tekrarlanır.
35. GIT WORKFLOWS
FEATURE BRANCH WORKFLOW
35
Ayşe konuşulan değişiklikleri yapar (add, commit) ve central repository’ye push
eder. Push edilen her değişiklik daha önce yaratılan Pull Request’te görünür.
Ali isterse Ayşe’nin çalıştığı branch’i pull edip kendisi de değişiklikler yapabilir.
Gitlab, Github veya Bitbucket üzerinden Pull Request merge edileblir veya aynı
işlemi elle yapmak için :
git checkout master
git pull
git pull origin new-feature-branch
git push
git checkout master
git pull
git merge new-feature-branch
ya da
36. GIT WORKFLOWS
GITFLOW WORKFLOW
36
Feature Branch Workflow’dan farklı olarak kalıcı olarak iki branch vardır: master ve develop
1.Master branch, release geçmişimizin tag ler ile tutan ana branch dir.
2.Feature branchler yine mevcuttur ancak master yerine develop branch’inden yaratılırlar.
3.Geliştirilmesi tamamlanan feature branchler develop branch ine merge edilir.
4.Develop branch inde yeni bir sürüm çıkacak kadar feature biriktiğinde veya önceden belirlenmiş
olan release zamanı geldiğinde, develop branch’inden yeni bir release branch’i yaratılır. (release
in version numarası yada adı ile, örneğin release-1.1.2 ya da release/ubersearch ).
5.release branch üzerinde sadece bugfix ler yapılabir. Yeni feature kesinlikle geliştirilmez.
6.Release branch’i production ready hale geldiğinde, master branch’a merge edilir ve version
numarası ile taglenir.
