Tag Archives: Git

Genel

Yararlı Git Numaraları #3

Zaman zaman gün içinde ihtiyaç duydukça kullandığım bazı ufak tefek git/shell tricklerini paylaşmaya devam ediyorum:

Belirli Bir İsim Desenine Sahip Git Dallarının Geliştirme Ortamından veya Uzak Uçtan Silinmesi:

İsimleri “mybranch-12-r001” – “mybranch-12-r095” arasında değişen git dallarını;

ggeliştirme ortamından toplu halde silmek için:

$ git branch | grep "mybranch-12-r" | xargs -I {} git branch -D {}

git branch: Geliştirme ortamında yeralan dal listesini döner.

grep “mybranch-12-r”: Bir önceki komutdan elde edilen dal listesindeki mybranch-12-r desenine uygun dal isimlerini filtreler.

xargs -I {} git branch -D {} : Bir önceki komut ile elde edilen filtrelenmiş dal listesindeki her satır için “git branch -D” komutunu çalıştırarak satırda adı geçen dalı geliştirme ortamından siler.

uzak uçtan toplu halde silmek için:

$ git branch -r|grep "origin/mybrnach-12-r"|awk -F/ '{print $2}'|xargs -I {} git push origin :{}

Yukarıdaki komut dizisinde komut borusu ile ayrılan ifadeleri inceleyelim:

git branch -r : Uzak uçda takip edilen dal listesini döner.

grep “origin/mybrnach-12-r”: Bir önceki komutdan elde edilen dal listesindeki mybranch-12-r desenine uygun dal isimlerini filtreler.

awk -F/ ‘{print $2}’ : Bir önceki komutdan dönen filtrelenmiş dal listesindeki her satırı “/” ifadesiyle bölerek dal ismini içeren ikinci bölümü döner.

xargs -I {} git push origin :{} : Bir önceki komut ile elde edilen filtrelenmiş dal listesindeki her satır için “git push origin :” komutunu çalıştırarak satırda adı geçen dalı uzak uçdan siler.

Master Dal ile Birleşmiş Olan Dalların Geliştirme Ortamından Silinmesi

Master dalla birleştirmiş olduğunuz dalları, geliştirme ortamında ayrıca saklamanıza gerek yoktur. Bu dalları geliştirme ortamınızdan silmek için aşağıdaki komutu kullanabilirsiniz.

$ git checkout master && git branch --merged | grep -v "\*" | xargs -n 1 git branch -d

Yukarıdaki komut dizisinde komut borusu ile ayrılan ifadeleri inceleyelim:
git checkout master && git branch –merged : master dalına checkout işlemini gerçekleştirir ve master ile birleştirilen dal listesini döner.

grep -v “\*” : Bir önceki komutda dönen dal listesinde * ile ifade edilen git reposunun içinde bulunduğu geçerli dalı listenin dışında bırakır.

xargs -n 1 git branch -d : Bir önceki komutdan dönen listedeki her bir dal ismi için “git branch -d” komutunu çalıştırarak listedeki dalları geliştirme ortamından siler.

Git Reposunda Belirli Bir Dal Veya Referansdaki Kodun Sürümden Çıkartılması (Kopyalanması)

Geçmişte svn kullanıcılarının hatırlayacağı “svn export” komutunun yaptığı işlemi gerçekleştiren bu komut, genellikle deployment için repodaki kodun belirli bir daldaki durumunun kopyasının sürüm kontrolü dışında biryerde oluşturulması için kullanılır.

$ git archive --remote=git@bitbucket.org:dagnet_d/zf2.git --format=tar --prefix=zf2/ master |tar -xvf -

Bu işlem, git@bitbucket.org:dagnet_d/zf2.git reposunda, master daldaki Zend Framework 2 kodunu tar formatında geçerli ortama aktarır. Aktarılan kod tabanına ait dosya ve klasörler, zf2 isimli klasörün altında olacak şekilde oluşturulur. Komut borusundan sonraki kısımdayse sıkıştırılmış veri geçerli ortam diskine açılarak kod tabanının sürüm kontrolü dışında master dalın HEAD referansındaki kopyası oluşturulur.

Versiyon kontrolü işlerini Github üzerinde gerçekleştiriyorsanız git archive işlemi, doğrudan uzak repodan gerçekleştirilememektedir. Github kullanıcıları bu işlemi şu şekilde gerçekleştirebilirler:

$ git clone git@github.com:ibrahimgunduz34/paranoia.git paranoia
$ cd paranoia
$ git archive --format=tar --prefix=paranoia_current/ master |tar -xv -C ../
$ cd .. 
$ rm -rf paranoia
Sürüm Yönetimi

Yararlı Git Numaraları 2: Stash

Bir iş üzerinde çalışırken aniden başka bir işe geçmeniz istendi ve yaptığınız değişiklikleri commit etmek istemiyorsunuz git stash komutunu kullanabilirsiniz.

Örnek:

$ git stash

Bu işlem sonunda indexlenen/indexde olmayan tüm değişiklikleriniz yerel bir bölgede repoya commit edilmeden, branch ın en son commit yorumu ile saklanır.

stash ile farklı branchlardan birden fazla değişikliği saklayabilirsiniz. Sakladığınız tüm değişikliklerin listesini görmek için git stash list kullanabilirsiniz.
Örnek:

$ git stash list

Çıktı:

stash@{0}: WIP on ab-802: 2042b39 ab-802 url routes updates.
stash@{1}: WIP on ab-856: 7188b7e ab-856 changed request xml of ykb return transaction

Spesifik bir saklama işlemine ait değişikliklerin listesini görmek için git stash show <stashid> kullanabilirsiniz.

Örnek:

$ git stash show stash@{0}

Çıktı:

  apps/product/management/commands/solrimport.py |   81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 apps/product/models.py                         |    6 +++---
 libs/solr/__init__.py                          |   13 ++++++++++--
 libs/solr/caster.py                            |   49 +++++++++++++++++++++++++++++++-------------
 requirements                                   |    4 +---
 5 files changed, 131 insertions(+), 22 deletions(-)

Daha önce yaptığınız spesifik bir saklama işlemini tekrar geri almak istiyorsanız git stash pop komutunu kullanabilirsiniz.

Örnek:

$ git stash pop stash@{1}

Çıktı:

 # On branch ab-802
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#   new file:   apps/product/management/commands/solrimport.py
#
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   apps/product/models.py
#   modified:   libs/solr/__init__.py
#   modified:   libs/solr/caster.py
#   modified:   requirements
#
Dropped stash@{0} (d129b2d356782da4cf223d02de09e3e8655622fd)

pop komutu, sakladığınız değişiklikleri tekrar geri alarak saklama alanından kaldırır.

Bu işlemi aynı zamanda git stash apply komutunu kullanarak da gerçekleştirebilirsiniz. Apply komutu pop komutundan farklı olarak yapılan değişiklikleri yerel alanda saklamaya devam eder.

Sürüm Yönetimi

Yararlı Git Numaraları

Belki günlük hayatta sıkca kullanmayabilirsiniz, ancak yarın birgün ufak tefek git hookları yazmak isterseniz bu küçük numaralar işinize yarayacaktır.

Indekslenen eklenen(A)/kopyalanan(C)/değiştirilen(M) dosyaların listesini almak için:

$ git diff --name-only --cached --diff-filter=ACM

Kafadaki commit kimliğini almak için:

$ git rev-parse HEAD

Geçerli branch ismini almak için:

$ git rev-parse --abbrev-ref HEAD

Belirli bir dosyanın, belirli bir commitdeki içeriğini görüntülemek için:

$ git show --source 7e112e7728f7af8727ce2aaa29ee027474dcca91:file.php

Indekse eklenen dosyanın, indeksdeki içeriğini görüntülemek için:

$ git show --source :file.php
Sürüm Yönetimi

Git Farklarını Yan Yana Karşılaştırmak

Geliştirme yaptığınız projede değişiklik yaptığınız program blokları belirli bir büyüklüğün üstünde olduğunda git diff, zaman zaman değişimi alakasız bir bloğun içinde yapılmışcasına gösterir.

Pek çok IDE side by side karşılaştırmayı destekler. Ancak sizde benim gibi vim veya türevi text editörlerini kullanıyorsanız vimdiff ile yanyana karşılaştırma işlemini rahatlıkla yapabilirsiniz.

Kullanım:

 $ git difftool --tool=vimdiff 

Ekran Görüntüsü :
Screenshot from 2013-09-19 15:05:34

Sürüm Yönetimi

Git Kullanımında Geliştirme Yapılan Dalların Doğru Güncellenmesi ve Önemi

Kalabalık geliştirici gruplarının çalıştığı projelerde sürüm paketlerinin düzgün oluşturulabilmesi için çıkılan dalların doğru güncellenmesi oldukca önemlidir. Genellikle böyle yapılarda geliştiricilerin bu konuyla ilgili en çok yaşadığı ikilem, pull ve rebase komutlarının kullanımıdır. Cevabı aslında çok net olan bu ikilemi ortadan kaldırmak için öneclikle pull ve rebase komutlarını yakından tanıyalım.

1. Git Pull ve Rebase Komutlarını Tanıyalım:

pull ve rebase komutları, genel olarak uzak depoda gerçekleşen değişikliklerin yerel depodaki değişikliklerle geçerli yerel dalda farklı metodolojilerle birleştirilmesi için kullanılırlar.

1.1. Git Pull:

Git pull, uzak depoda gerçekleşen değişiklikleri yerel depoda ilgili dalda birleştirmek için kullanılır. Birleştirme işlemi, commit sırasına göre gerçekleştirileceğinden birleştirme sonrasında sürüm günlüğünde iki commit arasında uzak depodan gelen farklı geliştiricilerin yaptığı commitleri görmeniz olasıdır.

Pull işleminden önce sürüm günlüğü

commit e572de2efb567fc71c4b1514c7187f5d07eac6c2
Author: Ali Veli <ali.veli@gmail.com>
Date:   Wed Jul 17 02:13:50 2013 -0430

    ISSUE-1 - Soap adapter'ı için son committe eksik kalan fonksiyonlar eklendi.

    Change-Id: Iee83313671916bfb1e13fbc8f5b71408be202749

commit 89cc1c898ff01ff945c3423d22ed143dda52e475
Author: Ali Veli <ali.veli@gmail.com>
Date:   Tue Jul 16 09:38:35 2013 -0430

    ISSUE-1 - required function sendRequest implemented for Soap Adapter

    Change-Id: Id4f7ffdaef1f905b029d4818e1e07d1d5bc60bf1

Pull işleminden sonra sürüm günlüğü

commit e572de2efb567fc71c4b1514c7187f5d07eac6c2
Author: Ali Veli <ali.veli@gmail.com>
Date:   Wed Jul 17 02:13:50 2013 -0430

    ISSUE-1 - Soap adapter'ı için son committe eksik kalan fonksiyonlar eklendi.

    Change-Id: Iee83313671916bfb1e13fbc8f5b71408be202749

commit 70c6059f32b5569ef32875d38da564d7a6d128ed
Author: Ibrahim Gunduz <ibrahim.gunduz@markafoni.com>
Date:   Tue Jul 16 16:54:20 2013 +0300

    ISSUE-2 - Event listener communication kutuphanesiyle iliskilendirilmesi-devam ediyor.

commit 87f166fa0460db40a240200dd093196f2195bb88
Author: Ibrahim Gunduz <ibrahim.gunduz@markafoni.com>
Date:   Tue Jul 16 13:13:26 2013 +0300

    ISSUE-2 - EventManager soyutlamasiyle ilgili gelistirme yapildi.

commit 89cc1c898ff01ff945c3423d22ed143dda52e475
Author: Ali Veli <ali.veli@gmail.com>
Date:   Tue Jul 16 09:38:35 2013 -0430

    ISSUE-1 - required function sendRequest implemented for Soap Adapter

    Change-Id: Id4f7ffdaef1f905b029d4818e1e07d1d5bc60bf1

Git pull, aynı zamanda git fetch + git merge komutlarının birlikte kullanımıyla gerçekleşen işlem için bir kısayol komutudur.

git fetch+git merge ile uzakdaki değişikliklerin alınması :

$ git fetch origin
...
$ git merge origin/master

git pull ile uzakdaki değişikliklerin alınması :

$ git pull origin master

1.2. Git Rebase:

Git rebase komutu, uzak depodaki daldan ayrıldığınız noktadan itibaren yaptığınız tüm değişiklikleri daha sonra kullanmak üzere kenara alır, uzak depodaki değişiklikleri yerel depodaki dalda birleştirir ve sizin yaptığınız değişiklikleri dalın en üstüne taşır.

Biraz önce git pull komutunda kullandığımız örneği git rebase ile gerçekleştirelim.

Yerel depomuzdaki dalda gerçekleştirdiğimiz değişiklikler :

commit e572de2efb567fc71c4b1514c7187f5d07eac6c2
Author: Ali Veli <ali.veli@gmail.com>
Date:   Wed Jul 17 02:13:50 2013 -0430

    ISSUE-1 - Soap adapter'ı için son committe eksik kalan fonksiyonlar eklendi.

    Change-Id: Iee83313671916bfb1e13fbc8f5b71408be202749

commit 89cc1c898ff01ff945c3423d22ed143dda52e475
Author: Ali Veli <ali.veli@gmail.com>
Date:   Tue Jul 16 09:38:35 2013 -0430

    ISSUE-1 - required function sendRequest implemented for Soap Adapter

    Change-Id: Id4f7ffdaef1f905b029d4818e1e07d1d5bc60bf1

Rebase işleminden sonra gelen değişikliklerle yerel deponun son durumu:

commit e572de2efb567fc71c4b1514c7187f5d07eac6c2
Author: Ali Veli <ali.veli@gmail.com>
Date:   Wed Jul 17 02:13:50 2013 -0430

    ISSUE-1 - Soap adapter'ı için son committe eksik kalan fonksiyonlar eklendi.

    Change-Id: Iee83313671916bfb1e13fbc8f5b71408be202749

commit 89cc1c898ff01ff945c3423d22ed143dda52e475
Author: Ali Veli <ali.veli@gmail.com>
Date:   Tue Jul 16 09:38:35 2013 -0430

    ISSUE-1 - required function sendRequest implemented for Soap Adapter

    Change-Id: Id4f7ffdaef1f905b029d4818e1e07d1d5bc60bf1

commit 70c6059f32b5569ef32875d38da564d7a6d128ed
Author: Ibrahim Gunduz <ibrahim.gunduz@markafoni.com>
Date:   Tue Jul 16 16:54:20 2013 +0300

    ISSUE-2 - Event listener communication kutuphanesiyle iliskilendirilmesi-devam ediyor.

commit 87f166fa0460db40a240200dd093196f2195bb88
Author: Ibrahim Gunduz <ibrahim.gunduz@markafoni.com>
Date:   Tue Jul 16 13:13:26 2013 +0300

    ISSUE-2 - EventManager soyutlamasiyle ilgili gelistirme yapildi.

Rebase işleminden sonra yerel depoda Ali Veli kullanıcısının değişikliklerinin bazı commitlerin tarihi daha eski olduğu halde en üst sıraya taşınması dikkatinizi çekti mi ?

2. Pull ve Rebase Hangi Durumlarda Kullanılmalı ?

pull komutu uzaktan gelen değişiklikleri, zamana bağlı olarak yerel dalla birleştirir. Dolayısıyla geliştirme yaptığınız dalları pull ile güncellemek, birden fazla commit e sahip olan işlerde araya giren farklı işlerin commitleri nedeniyle sürüm günlüğünün okunmasını güçleştirecektir. Bu nedenle git pull (veya fetch+merge) komutunu yalnızca ana dalı güncellemek için kullanmak daha doğru bir yaklaşım olacaktır.

git pull ile gerçekleşen güncelleme :

commit e572de2efb567fc71c4b1514c7187f5d07eac6c2
Author: Ali Veli <ali.veli@gmail.com>
Date:   Wed Jul 17 02:13:50 2013 -0430

    ISSUE-1 - Soap adapter'ı için son committe eksik kalan fonksiyonlar eklendi.

    Change-Id: Iee83313671916bfb1e13fbc8f5b71408be202749

commit 70c6059f32b5569ef32875d38da564d7a6d128ed
Author: Ibrahim Gunduz <ibrahim.gunduz@markafoni.com>
Date:   Tue Jul 16 16:54:20 2013 +0300

    ISSUE-2 - Event listener communication kutuphanesiyle iliskilendirilmesi-devam ediyor.

commit 87f166fa0460db40a240200dd093196f2195bb88
Author: Ibrahim Gunduz <ibrahim.gunduz@markafoni.com>
Date:   Tue Jul 16 13:13:26 2013 +0300

    ISSUE-2 - EventManager soyutlamasiyle ilgili gelistirme yapildi.

commit 89cc1c898ff01ff945c3423d22ed143dda52e475
Author: Ali Veli <ali.veli@gmail.com>
Date:   Tue Jul 16 09:38:35 2013 -0430

    ISSUE-1 - required function sendRequest implemented for Soap Adapter

    Change-Id: Id4f7ffdaef1f905b029d4818e1e07d1d5bc60bf1

Geliştirme yaptığınız dalları güncel tutmak içinse rebase komutu kullanmak, geliştirme yaptığınız commitleri bir arada tutabilmek adına çok daha doğru bir yaklaşım olacaktır. Böylelikle sürüm günlüğünde belirli bir işle ilgili tüm değişiklikleri bir arada tutarak günlüğün okunmasını kolaylaştırmış olursunuz.

rebase komutu ile geliştirme dalının güncellenmesi :

commit e572de2efb567fc71c4b1514c7187f5d07eac6c2
Author: Ali Veli <ali.veli@gmail.com>
Date:   Wed Jul 17 02:13:50 2013 -0430

    ISSUE-1 - Soap adapter'ı için son committe eksik kalan fonksiyonlar eklendi.

    Change-Id: Iee83313671916bfb1e13fbc8f5b71408be202749

commit 89cc1c898ff01ff945c3423d22ed143dda52e475
Author: Ali Veli <ali.veli@gmail.com>
Date:   Tue Jul 16 09:38:35 2013 -0430

    ISSUE-1 - required function sendRequest implemented for Soap Adapter

    Change-Id: Id4f7ffdaef1f905b029d4818e1e07d1d5bc60bf1

commit 70c6059f32b5569ef32875d38da564d7a6d128ed
Author: Ibrahim Gunduz <ibrahim.gunduz@markafoni.com>
Date:   Tue Jul 16 16:54:20 2013 +0300

    ISSUE-2 - Event listener communication kutuphanesiyle iliskilendirilmesi-devam ediyor.

commit 87f166fa0460db40a240200dd093196f2195bb88
Author: Ibrahim Gunduz <ibrahim.gunduz@markafoni.com>
Date:   Tue Jul 16 13:13:26 2013 +0300

    ISSUE-2 - EventManager soyutlamasiyle ilgili gelistirme yapildi.
Sürüm Yönetimi

Yar Yaban Ellere `Git` miş.

Bir sabah IT den sorumlu devlet bakanınız “ya allah” diyip GIT`e geçmeye karar vermiş ve siz hayatınızda böyle birşey duymamışsanız vah halinize. Commit mi edeyim push mu edeyim ne pull u noluyor lan derken iki satır kodu yayına alamaz sinirinizden klavyeyi yersiniz. Konuyla ilgili Türkçe kaynak kıtlığı olayın vehametini birkaç kat daha arttırır.

Bugün sizlerle GIT de yapabileceğiniz günlük işlerle ilgili olarak küçük ipuçları paylaşmaya çalışacağım.

GIT reposundaki bir projeye nasıl dahil olurum?

GIT , SVN den farklı olarak dağıtık bir yapıya sahipdir. Merkezi bir reponun olması zorunlu değildir. Üyeler değişiklikleri kendi aralarında paylaşabildikleri gibi merkez olarak belirlenen ortak bir makineye (Git jargonunda bu makineye origin deniliyor.) de gönderebilirler. Günümüzde bu işler için genelde GITHub ve BitBucket gibi servislerden yararlanılıyor. Özetle projeye dahil olmak yerine merkez reponun kopyasını bilgisayarınıza alıyorsunuz. Bu işlemi gerçekleştirmek için aşağıdaki komutu kullanabilirsiniz.

git clone 

Örnek:

$ git clone git@github.com:ibrahimgunduz34/mytest.git

Sonuç:

Cloning into 'mytest'...
remote: Counting objects: 29, done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 29 (delta 3), reused 24 (delta 1)
Receiving objects: 100% (29/29), done.
Resolving deltas: 100% (3/3), done.

Hangi dosyaların değiştiğini nasıl anlayabilirim ?

SVN’de olduğu gibi GIT ‘de de status komutunu kullanarak değişen/eklenen dosyalarınızın listesini görebilirsiniz.
Örnek:

$ git status

Şayet herhangibir ekleme veya değişiklik yapmadıysanız aşağıdaki gibi bir sonuç görebilirsiniz:
Sonuç:

# On branch master
nothing to commit (working directory clean)

Şayet birşeyler değiştirdiyseniz veya eklediyseniz;
Sonuç:

# On branch master
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#	modified:   test1.php
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#	NEW.txt
no changes added to commit (use "git add" and/or "git commit -a")

Yukarıda gördüğünüz üzere ilk örnekde herhangibir değişiklik yokken ikinci örnekde test1.php isimli dosyada değişiklik olduğunu, NEW.txt isimli dosyanın eklendiğini ve untracked (takip edilmeyen: buradan bu dosyanın henüz projeye dahil edilmediğini anlıyoruz.) durumda olduğunu anlıyoruz.

Yaptığım değişiklikleri merkez repoya nasıl gönderirim ?

GIT in SVN e göre majör farklarından biri de değişikliklerin merkez repoya gönderilmesi konusudur.

SVN`de değişiklikleri merkez repoya göndermek için commit etmeniz yeterlidir. Yalnızca yeni dosya eklediğiniz durumlarda add komutu ile dosyayı projeye dahil etmeniz ve sonrasında commit işlemini gerçekleştirmeniz gerekir.

GIT`de ise eklenen veya değişen her dosyanın bir sonraki commit ile gönderilebilmesi için görüntülerinin add komutu ile alınarak index ismli geçici bir alanda saklanması gerekmektedir. Aksi halde yapılan değişiklikler commit edilemez.

Kullanım:

git add   

Örnek:
Git add komutunu aşağıdaki gibi her dosya için tek tek çağıraiblirsiniz

$ git add test1.php
$ git add NEW.txt

veya dosya isimlerini peş peşe yazarak kullanabilirsiniz

$ git add test1.php NEW.txt

ya da (.) işaretini kullanarak eklenen ve değişen tüm dosyaların görüntüsünü index e alabilirsiniz.

$ git add .

Şimdi git status komutunu çalştırarak durumdaki değişikliği görelim.

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#	new file:   NEW.txt
#	modified:   test1.php
#

Status komutunu anlatırken ikinci örneğin en altında gördüğünüz no changes added to commit (use “git add” and/or “git commit -a”) ibaresi, değişikliklerimizi index e eklediğimizden dolayı artık yok.Bu durum eklenen veya değişen tüm dosyaların başarıyla indeks e eklendiğini gösteriyor. Artık dosyalarımızı commit etmeye hazırız.
Örnek:

$ git commit -m "Filanca konuda değişiklik yaptım."

Sonuç:

[master 51655a4] Filanca konuda değişiklik yaptım.
 1 file changed, 1 insertion(+)
 create mode 100644 NEW.txt

Değişen veya eklenen tüm dosyaları commit komutuna -a parametresini vererek bir kerede hem indekse eklenip hem de repoya gönderilebilmesi mümkündür. Ancak kontrolünüz dışında repoya birşey gönderilmemesi açısından add komutu ile dosya listesi göndermek her zaman için daha doğru bir yaklaşımdır. Zira kimse .tmp .swp .bak uzantılı dosyalarla reposunu çöp haline getirmek istemez. :)

Bitti mi ? Bitmed… Yazının başnda hatırlayacak olursanız GIT tarafında her kullanıcının proje reposunun bir klonuna sahip olduğundan bahsetmiştik. Commit komutunu çalıştırdığınızda indekse aldığınız tüm değişiklikler işte bu yerel repo ya gönderilecektir. Yerel reponuzun origin e göre ne kadar eski veya yeni olduğunu görmek için status komutunu çalıştırmalısınız.

$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

Gördüğünüz üzere az önce yerel repoya yaptığımız commit nedeniyle origindeki repodan 1 commit ilerideyiz. Diğer kullanıcıları bu değişiklikten mahrum etmemek ve origin i güncellemek için push komutunu kullanıyoruz.
Kullanım:

$ git push  

repo adı veya url: Bu parametre ile değişikliklerin gönderileceği repo tanımlanır. Boş bırakılması durumunda değişiklikler, projenin kopyalandığı kaynağa (origin) gönderilir.
branch adı: Değişikliklerin gerçekleştirildiği branch ın adıdır. Boş bırakılması durumunda varsayılan olarak master branch ı gönderilir.

Örnek:

git push origin

Sonuç:

Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 389 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To git@github.com:ibrahimgunduz34/mytest.git
   39b5963..109014a  master -> master

Merkez repodaki değişiklikleri nasıl alabilirim ?

SVN kullanırken merkezdeki değişiklikleri yerel e alabilmek için update komutunu kullanırken GIT tarafında bu işlemi gerçekleştirmek için pull komutunu kullanmamız gerekir.
Kullanım:

git pull  

repo adı veya url: Bu parametre ile değişikliklerin alınacağı repo tanımlanır. Boş bırakılması durumunda değişiklikler, projenin kopyalandığı kaynaktan (origin) alınır.
branch adı: Değişikliklerin alınacağı branch ın adıdır. Boş bırakılması durumunda origin repoda değişen tüm branchlar alınır.

Örnek:

$ git pull origin
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From github.com:ibrahimgunduz34/mytest
   d89fbf9..486cfa0  master     -> origin/master
Updating d89fbf9..486cfa0
Fast-forward
 NEW.txt |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

@berkerpeksag dan sonra gelen edit:
GIT in güzel özelliklerinden biri de pull ile kullanılan –rebase parametresidir (Bir de git rebase var ki tadından yenmez. Ayrıca söz edeceğim.) git pull –rebase, çalıştığınız branchda yaptığınız değişiklikleri originden alacağınız değişikliklerin üzerine uygular. Bu ne demek ? Örneğin bir patch çıkmayı planlıyorsunuzdur ancak siz bu işi yapana kadar yayına giren başka işler vardır. Doğal olarak sizin öncelikle güncellemeleri kendi lokalinize almanız gerekir. Peki ya sizin yaptığınız güncellemeler ne olacak ? :( Git pull –rebase origin de ilgili branch daki değişiklikleri aldıktan sonra sizin yaptığınız değişiklikleri aynen HEAD e uygulayacaktır. Tabi önce kendi yaptığınız değişiklikleri yerel reponuzdaki branch a commit etmiş olmanız gerekiyor.
Kullanım:

git pull --rebase  

Örnek:

git pull --rebase origin master

Teşekkürler Berker :)

Nasıl yeni bir branch oluştururum ?

Bunu SVN le karşılaştırmak bile istemiyorum. Zira SVN kullandığım günler aklıma geliyor da fena sövüyorum… Neyse… SVN de branch oluşturmak için copy ile referans branch ınızın bir kopyasını oluştururken GIT tarafında bulunduğunuz branch dan branch oluşturmak için branch komutu ile birlikte oluşturmak istediğiniz branch ın adını yazmanız yeterlidir. Branch komutu, branch adı belirtilmeden kullanıldığında reponuzdaki branchları listeler ve bulunduğunuz branch ı (*) işareti ile gösterir.

Kullanım:

git branch 

Örnek:

$ git branch akbank_uyarlamasi

Nasıl branchlar arasında geçiş yapabilirim ?

SVN de bu işlemi gerçekleştirmek için switch komutu kullanılırken GIT tarafında checkout komutu kullanılır. GIT in güzel özelliklerinden birisinin de branchlar arasındaki geçiş hızı olduğunu söylemeden geçemeyeceğim. SVN kullanıcısıysanız, projenizdeki dosya sayısı hatırı sayılırsa ve geçiş yaptığınız branchlar arasında değişiklik sayısı birkaç committen fazlaysa o switch toprakta biterken GIT tarafında bu işlem komutu yazıp elinizi enter dan kaldırmanız ile sonlanır.
Kullanım:

git checkout 

Örnek:

$ git checkout akbank_uyarlamasi

Checkout komutundan bahsetmişken küçük bir ipucu vermekte yarar var. Checkout komutu ile birlikte -b parametresini kullanarak aynı anda hem branch yaratıp hem de yarattığınız branch a geçiş yapabilirsiniz.
Örnek:

$ git checkout -b yeni_branch

Commit etmediğim bir değişikliği nasıl geri alabilirim ?

Yaptığınız bir değişikliği henüz commit etmemiş ve indeks e de almamışsanız checkout komutunu kullanarak dosyayı revert edebilirsiniz.
Örnek:

$ git checkout NEW.txt

Eğer dosyayı indekse eklediyseniz öncelikle reset sonra checkout komutlarını çalıştırmanız gerekiyor.

$ git reset NEW.txt
Unstaged changes after reset:
M	NEW.txt
$ git checkout NEW.txt

Commit ettiğim bir değişikliği nasıl geri alabilirim. ?

Commit ettiğiniz dosyayı daha önceki sürümlerden birine almak istiyorsanız dosyayı ilgili commite checkout etmeli ve tekrardan commit etmelisiniz.
Kullanım:

git checkout  
git commit -m 

Örnek:

$ git checkout 3a6576743bea41635296e1721de89b5e1e6770ab NEW.txt
$ git commit -m "Filanca işe geri döndük."
[master 7ae70a1] Filanca işe geri döndük.
 1 file changed, 3 deletions(-)

Belirli bir sürüme komple dönmeyi planlıyorsanız:

git reset 

Örnek:

git reset 3a6576743bea41635296e1721de89b5e1e6770ab

Bu işlemi gerçekleştirdikten sonra dosyalarınız indexlenmemiş belirtilen commit id deki durumlarına geri dönecektir. Gerçekleşen değişikliği (geri dönüşden kaynaklanan değişiklik) indekse ekleyerek commit etmeniz gerekmektedir.

git reset 3a6576743bea41635296e1721de89b5e1e6770ab
git add .
git commit -m "Filanca sürüme geri dönüldü."
git push origin

Tabi bu işin legal yolu. Dilerseniz reset –hard <commitid> yapabilirsiniz. Böylece hem belirttiğiniz commit id li işe geri döner hem de bu commit id den sonraki işlerin logdan silinmesini sağlarsınız. Ancak bu işlemi gerçekleştirdiğinizde GIT, push ile normal yoldan reponuzu merkeze senkronlamanıza izin vermeyeceğinden push –force kullanmanız gerekecektir. Kalabalık bir ekiple çalışıyorsanız bu yöntem başkalarının yaptığı değişiklikleri ezmenize neden olacağından gerekmedikçe kullanmamanızı öneriririm.

Sürüm geçmişi günlüğüne nasıl ulaşırım ?

Geçmiş günlüğüne SVN de olduğu gibi log komutu ile ulaşabilirsiniz.

$ git log

Son 5 commit i görüntülemek için:

$ git log -5

Bir branch da yaptığım değişiklikleri başka bir branch ile nasıl birleştirebilirim ?

GIT’de bir branch içinde yaptığımız güncellemeleri başka bir branch ile birleştirmek için merge komutu kullanılır. merge komutu bulunduğunuz branch ile merge komutuna parametre olarak gönderdiğiniz branch yada branchlarda varolan değişiklikleri birleştirir.

Örneğin yeni_branch branchındaki değişiklikleri master isimli branch`da birleştirmek istiyorsak

//master branch ına geçiyoruz.
$ git checkout master
Switched to branch 'master'

//yeni_branch isimli branchdaki değişiklikleri master ile birleştiriyoruz.
$ git merge yeni_branch
Updating 3a65767..2e8dfa8
Fast-forward
 NEW.txt |    1 +
 1 file changed, 1 insertion(+)

GIT, branchlardaki değişiklikleri birleştirmek için bize cherry-pick isimli farklı bir alternatif daha sunuyor. Cherry-pick, bir branchdaki commitleri başka bir branch a kopyalayabilmemizi sağlar. Böylelikle sürüm hazırlarken yayına almak istediğimiz işle ilişkisi olmayan commitlerin sürüme girmesinin önüne geçmiş oluyoruz.
Kullanım:

git cherry-pick 

Örneğin master da İlk Commit. ve İkinci Commit olarak iki tane commit imiz olsun ve yeni_is diye isimli bir branchımız ve bu branchda da Üçüncü commit, Dördüncü commit ve Beşinci commit isimli commitlerimiz olsun. Yeni bir sürüm çıkacağımızı ve bu sürüme yalnızca Üçüncü commit ve Beşinci commit commitlerinin gireceğini varsayalım.

Mevcut Durum:

$ git log master
commit 3a6576743bea41635296e1721de89b5e1e6770ab
Author: İbrahim Gündüz 
Date:   Sat Nov 3 23:40:15 2012 +0200

    İkinci commit.

commit dd879a82049e3f80d8ea07b150b3b29e45f3bb37
Author: İbrahim Gündüz 
Date:   Sat Nov 3 23:21:59 2012 +0200

    İlk commit.

$ git log yeni_branch
commit b6d44d862c6f8b93f0468218eaf060fd1ce95989
Author: İbrahim Gündüz 
Date:   Sun Nov 4 00:00:04 2012 +0200

    Beşinci commit.

commit 5e79f8c1b28d5a52bb658efbc59b854746880b11
Author: İbrahim Gündüz 
Date:   Sat Nov 3 23:59:54 2012 +0200

    Dördüncü commit.

commit 2e8dfa800eb9941c3853946ed8359091f3da3f0f
Author: İbrahim Gündüz 
Date:   Sat Nov 3 23:40:48 2012 +0200

    Üçüncü commit.

commit 3a6576743bea41635296e1721de89b5e1e6770ab
Author: İbrahim Gündüz 
Date:   Sat Nov 3 23:40:15 2012 +0200

    İkinci commit.

commit dd879a82049e3f80d8ea07b150b3b29e45f3bb37
Author: İbrahim Gündüz 
Date:   Sat Nov 3 23:21:59 2012 +0200

    İlk commit.

3. ve 5. commit leri master a alalım.

$ git checkout master
Switched to branch 'master'

$ git cherry-pick 2e8dfa800eb9941c3853946ed8359091f3da3f0f b6d44d862c6f8b93f0468218eaf060fd1ce95989

[master e2b3fa3] Üçüncü commit.
 1 file changed, 1 insertion(+)
error: could not apply b6d44d8... Beşinci commit.
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit'

Oh.. Yea… Bir taşla iki kuş. cherry-pick anlatalım derken conflict olduk. Hadi hayırlısı. Gelin şimdi conflict i resolve edelim.

Öncelikle hangi dosya veya dosyaların conflict olduğunu öğrenelim.

$ git status
# On branch master
# Unmerged paths:
#   (use "git add/rm ..." as appropriate to mark resolution)
#
#	both modified:      NEW.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Bakalım dosyaya ne olmuş.

ASDF
QWER
<<<<<<< HEAD
=======
qwer
QWER
>>>>>>> b6d44d8... Beşinci commit.                                      

Conflict in oluştuğu bölgede master ın HEAD inde birşey yokken Beşinci coommit commitinde yeni 2 satır eklenmiş. Kabuülümüzdür diyoruz ve dosyayı aşağıdaki şekilde güncelleyip kaydediyoruz.

ASDF
QWER
qwer
QWER

ve… değişen dosyamızın görüntüsünü indekse alıp yola devam ediyoruz.

$ git add NEW.txt
$ git cherry-pick --continue
[master f238560] Beşinci commit.
 1 file changed, 2 insertions(+)

Aklıma geldikçe paylaşmaya devam edeceğim. Kısa vadede günü kurtarmanızı sağlayacağını umuyorum.