Git & Git Workflows
- 1. GIT & WORKFLOWS GIT, CENTRALIZED, FEATURE BRANCH, GITFLOW
- 2. 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
- 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
- 5. 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.
- 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.
- 11. GIT BASICS BRANCHING & REMOTE TRACKING 11
- 12. GIT BASICS BRANCHING & REMOTE TRACKING 12
- 14. GIT BASICS BRANCHING & REMOTE TRACKING 14
- 15. GIT BASICS BRANCHING & REMOTE TRACKING 15
- 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(-)
- 19. GIT WORKFLOWS GIT WORKFLOWS 19 •Centralized Workflow •Feature Branch Workflow •Gitflow
- 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.
- 42. 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