42
GIT & WORKFLOWS GIT, CENTRALIZED, FEATURE BRANCH, GITFLOW

Git & Git Workflows

Embed Size (px)

Citation preview

Page 1: Git & Git Workflows

GIT & WORKFLOWSGIT, CENTRALIZED, FEATURE BRANCH, GITFLOW

Page 2: Git & Git Workflows

GIT & GITWORKFLOWS

*  ae5be5a  -­‐  (origin/master,  master)  GittiGidiyor/eBay  (Haziran  2012)  <kivancerten>  *  42964c4  -­‐  Octeth  -­‐  Sendloop.com  (Aralik  2010)  <kivancerten>  *  0c7bd79  -­‐  CNT  Bilisim  Teknolojisi  -­‐  Tamindir.com  (Kasim  2007)  <kivancerten>  *  523656c  -­‐  Reklamarasi  Advertising  &  Web  Technologies  (Eylul  2006)  <kivancerten>

Senior Software Engineer at GittiGidiyor/eBay

2006’dan beri yazılım geliştiriyorum.

Zend Certified Engineer - 2012

KIVANÇ ERTEN - 1984 IZMIR

tr.linkedin.com/in/kivancerten

Page 3: Git & Git Workflows

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:)

Page 4: Git & Git Workflows

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

Page 5: Git & Git Workflows

GIT BASICS

REPO-TO-REPO COLLABORATION

5

Git’in çalışma sistemi repository den repository olacak şekilde dizayn edilmiştir. Commit ler bir repository den diğerine gönderilip - alınır.

Page 6: Git & Git Workflows

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

Page 7: Git & Git Workflows

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 [email protected]

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.

Page 8: Git & Git Workflows

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.

Page 9: Git & Git Workflows

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

Page 10: Git & Git Workflows

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.

Page 11: Git & Git Workflows

GIT BASICS

BRANCHING & REMOTE TRACKING

11

Page 12: Git & Git Workflows

GIT BASICS

BRANCHING & REMOTE TRACKING

12

Page 13: Git & Git Workflows

GIT BASICS

REMOTE BRANCHING

13

Page 14: Git & Git Workflows

GIT BASICS

BRANCHING & REMOTE TRACKING

14

Page 15: Git & Git Workflows

GIT BASICS

BRANCHING & REMOTE TRACKING

15

Page 16: Git & Git Workflows

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)

Page 17: Git & Git Workflows

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 logcommit ae5be5af8f4a9808e94580a79a68ce36f59eb946Author: kivancerten <[email protected]>Date: Mon Feb 3 10:03:30 2014 +0200

Update Game.php

commit 42964c4acc3f2848a703e5e4f3ca389bec755797Author: kivancerten <[email protected]>Date: Mon Feb 3 09:59:52 2014 +0200

Update Display.php

commit 0c7bd79d07521923484c4766366860bf8279d4f9Author: kivancerten <[email protected]>Date: Mon Feb 3 09:32:47 2014 +0200

Update README.md

Page 18: Git & Git Workflows

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(-)

Page 19: Git & Git Workflows

GIT WORKFLOWS

GIT WORKFLOWS

19

•Centralized Workflow

•Feature Branch Workflow

•Gitflow

Page 20: Git & Git Workflows

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

Page 21: Git & Git Workflows

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

Page 22: Git & Git Workflows

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>

Page 23: Git & Git Workflows

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.

Page 24: Git & Git Workflows

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.

Page 25: Git & Git Workflows

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

Page 26: Git & Git Workflows

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.

Page 27: Git & Git Workflows

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.

Page 28: Git & Git Workflows

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

Page 29: Git & Git Workflows

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.

Page 30: Git & Git Workflows

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

Page 31: Git & Git Workflows

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.

Page 32: Git & Git Workflows

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

Page 33: Git & Git Workflows

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.

Page 34: Git & Git Workflows

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.

Page 35: Git & Git Workflows

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

Page 36: Git & Git Workflows

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.

Page 37: Git & Git Workflows

GIT WORKFLOWS

GITFLOW WORKFLOW

37

Page 38: Git & Git Workflows

GIT WORKFLOWS

GITFLOW WORKFLOW

38

Page 39: Git & Git Workflows

GIT WORKFLOWS

GITFLOW WORKFLOW

39

Page 40: Git & Git Workflows

GIT WORKFLOWS

GITFLOW WORKFLOW

40

Page 41: Git & Git Workflows

GIT WORKFLOWS

GITFLOW WORKFLOW

41

Page 42: Git & Git Workflows

GIT WORKFLOWS

REFERANSLAR

42

• https://git-scm.com• https://www.atlassian.com/git/tutorials/• http://www.sbf5.com/~cduan/technical/git/• http://gitready.com/

tr.linkedin.com/in/kivancerten