Github - 2

Kaldigimiz yerden... 

Branch 

Branch projenin gidisinde ayri bir kol olusturarak kodun paralel evrenini yaratmaktir diyebilirim. (Fringe yapti beni boyle) 

Neden ? 

Ekip olarak bir ekleme yapacaksiniz ve birbirinizin dosyalarina girme ihtimaliniz var. Kodun orjinal halini korurken bir degisikligi denemek ve sonuclarini gormek istiyorsunuz ama orjinal halinin korunmasini da istiyorsunuz. iste o zaman branch lazim olabiliyor bize.

Orneklere gecelim yine

yenidal diye bir branch yaratarak ise basliyoruz.

git checkout -b yenidal

-b : branch yerine kisa kullanim icin.. bu cumleyi git checkout branch yenidal olarak da yazabilirdik

simdi Code/lib/test2.rb diye bir dosya olusturdum ve icine birseyler yazdim ve commit ettim.

cd lib

subl test2.rb

git add .
git commit -m "test2.rb dosyasini ekledim"

hatta ilk dosyami da degistirip kaydediyor ve commit ile gonderiyorum

subl test1.rb

git add .

git commit -m "test1.rb dosyasini degistirdim"

simdi projede iki tane branch var.

git hist --all
* 807fd32 2013-10-18 | test1.rb dosyasini degistirdim (HEAD, yenidal) [Macrop]
* eb86530 2013-10-18 | test2.rb dosyasini ekledim [Macrop]
* cf5ccc3 2013-10-17 | Amending ext (master) [Macrop]
* 913f1bf 2013-10-17 | 3rd commit (v1) [Macrop]
* 9c46dcb 2013-10-17 | My Second Commit (v0) [Macrop]
* 3beabaf 2013-10-17 | My First commit on test1.rb [Macrop]

master branch'e gecmek icin asagidaki komutu kullaniyorum

git checkout master

Master dayken readme diye bir dosya olusturdum kaydettim commit ile gonderdim. (su anda master branch'de oldugumuzdan bu commmit de master'a gitti)

subl readme

git add .
git commit -m "readme eklendi"

simdi projenin tarihcesini aldigimizda text formatinda da olsa grafik sekilde projenin iki branch ustunde yurudugu ve en son yapilan commitler gozukuyor. (Satir baslarindaki cizgilere bakin )

git hist --all
* 218bf8c 2013-10-18 | readme eklendi (HEAD, master) [Macrop]
| * 807fd32 2013-10-18 | test1.rb dosyasini degistirdim (yenidal) [Macrop]
| * eb86530 2013-10-18 | test2.rb dosyasini ekledim [Macrop]
|/  
* cf5ccc3 2013-10-17 | Amending ext [Macrop]
* 913f1bf 2013-10-17 | 3rd commit (v1) [Macrop]
* 9c46dcb 2013-10-17 | My Second Commit (v0) [Macrop]
* 3beabaf 2013-10-17 | My First commit on test1.rb [Macrop]

Merge

olusturulan iki dali tekrar birlestirme islemine de merge deniyor.
Once olusturdugumuz dala (branch) geciyoruz ve merge komutu ile bagliyoruz.

git checkout yenidal
Switched to branch 'yenidal'

git merge master
Merge made by the 'recursive' strategy.
 readme |    1 +
 1 file changed, 1 insertion(+)
 create mode 100644 readme

git hist --all
*   2d06fdb 2013-10-18 | Merge branch 'master' into yenidal (HEAD, yenidal) [Macrop]
|\  
| * 218bf8c 2013-10-18 | readme eklendi (master) [Macrop]
* | 807fd32 2013-10-18 | test1.rb dosyasini degistirdim [Macrop]
* | eb86530 2013-10-18 | test2.rb dosyasini ekledim [Macrop]
|/  
* cf5ccc3 2013-10-17 | Amending ext [Macrop]
* 913f1bf 2013-10-17 | 3rd commit (v1) [Macrop]
* 9c46dcb 2013-10-17 | My Second Commit (v0) [Macrop]
* 3beabaf 2013-10-17 | My First commit on test1.rb [Macrop]

yine ASCII de olsa grafik formatinda projenin iki dala ayrilip tekrar birlesmesini gorebiliriz.
peki bir cakisma olursa ne olacak ?

Conflict

simdi master'daki readme'yi degistirip kaydediyor ve add - commit ile gonderiyorum
ardindan yenidal'a geciyor ve readme'yi degistirip add - commit ile onu da gonderiyorum

simdi icleri birbirinden farkli ayni isimde iki tane dosya iki ayri branch'da bekliyor.
birlestirmeye kalkinca

 git merge master
error: 'merge' is not possible because you have unmerged files.
hint: Fix them up in the work tree,
hint: and then use 'git add/rm <file>' as
hint: appropriate to mark resolution and make a commit,
hint: or use 'git commit -a'.
fatal: Exiting because of an unresolved conflict.

o halde birlestirelim bunun icin dosyanin icine bakiyoruz

subl readme

soyle birsey var

file for master branch

<<<<<<< HEAD
bunu da yenidal dan degistirdim
=======
Master'dayken degistirdim
>>>>>>> master

cakismanin oldugu yer ve hangi dosyada nasil yer aldigina dair bir bilgi aldik. Simdi bunu elle cozmemiz lazim. yani hangisini dogru kabul edeceksek o bolumu birakiyor digerini siliyoruz

file for master branch
bunu da yenidal dan degistirdim

bu cakisma duzeltildigine gore simdi birlestirmeye devam edebilirim

git add readme
git commit -m "cakisma cozuldu"

Normalde git merge islemi icin grafik tabanli bir arac saglamiyor ancak baskalari ile calisabiliyor. "Meld" benim gordugum ve isini iyi yapan bir arac gibi. Asagidaki gibi kurabilirsiniz

sudo apt-get install meld

sonra git'in global konfigurasyon dosyasi uzerinde yapacaginiz bir degisiklikle conflict cozmek icin artik meld kullanilacagini soyleyebilirsiniz.
 bunun icin subl ~/.gitconfig yazip dosyanin icine sunlari eklemek

~/.gitconfig

[merge]
tool = meld
[diff]
tool = meld

conflict mesaji aldiginizda git mergetool yazarsaniz artik meld acilacak

git mergetool
Merging:
readme

Normal merge conflict for 'readme':
  {local}: modified file
  {remote}: modified file
Hit return to start merge resolution tool (meld):

oklari kullanarak conflicti cozmek mumkun artik. Daha kolay degil mi ?
sonrasi gene ayni

git add readme
git commit -m "cakisma gene cozuldu"

Rebase 

Merge ile cok benziyor aslinda. Farki commit agacinin (tarihcesinin) farkli olmasi. Rebase yapdiginizda daldaki commit tarihcesine materdaki commit tarihcesi de getiriliyor. boylece master aslinda branch'in commit tarihcesinin bir parcasi oluyor. Okumasi daha kolay bir tarihce olusmasina ragmen acik kaynak kodu gibi cok kullanicinin calistigi durumlarda tarihce bozuldugundan kullanicilarin kafasini karistirabilir. 

Birden cok repository (clone)

Simdiye kadar yaptigim ornekleri gittest diye bir klasorun icinde yaptim. simdi o klasorden bir uste cikiyorum ve asagidaki komutu veriyorum

git clone gittest gittest_clone

klonlanmis repository tarihcesini de tasiyarak gelir. klonladigimiz dizine girip tarihcesini alirsak gittest'teki tarihce ile ayni oldugunu goruyoruz.

git hist --all

Origin

projenin orjinal halini ifade ediyor. (asil ilk merkezi repository)

git remote
origin
git remote show origin

* remote origin
  Fetch URL: /home/aliiybar/Code/gittest
  Push  URL: /home/aliiybar/Code/gittest
  HEAD branch (remote HEAD is ambiguous, may be one of the following):
    master
    yeni
  Remote branches:
    master  tracked
    remove  tracked
    yeni    tracked
    yenidal tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

Remote Branch

biraz once olusturdugumuz klon icinde branch'lara baktigimizda bir tek master'i goruyoruz. 

git branch
* master

-a parametresini verdigimizde tamami goruntuleniyor

git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/remove
  remotes/origin/yeni
  remotes/origin/yenidal

Fetch

orjinal repo'daki degisiklik durumunda (once orjinalde bir degisiklik yapalim)

cd ..
cd gittest
subl readme
git add readme
git commit -m "readme degisti"

klona gecip fetch komutunu calistiralim

cd ..

cd gittest_clone

git fetch

git hist --all

....

73076dd 2013-10-18 | master'a readme eklendi (HEAD, origin/master, origin/HEAD, master) [Macrop]

....

fetch komutu commit tarihcesini getirdi ama merge etmiyor. reame dosyasina bakinca degismemis oldugunu goruyorum
merge edebilmek icin su komutu veriyorum

git merge origin/master

Pull

aslinda iki komutun birlesimi diyebiliriz

git fetch 

git merge origin/master 

diyecegimize 

git pull diyoruz o kadar . 

Tracking branch

clone ile aldigimiz repoda yenidal diye bir branch yok ama orjinalde vardi. yenidal'i takip etmek icin tracking branch kullaniyoruz

git branch --track greet origin/greet
git branch -a
git hist --max-count=2

Remote Add

cd gittest_remote
git remote add shared ../hello.git

Push

yapilan degisiklikleri lokal repository'den server'a veya uzak repository'e gondermek icin push kullanilir. 

git push shared master

Lokal repository yayinlamak

once calisilan klasor icinde asagidaki komutu verip bir cesit web server calismasini sagliyoruz

git daemon --verbose --export-all --base-path=

Sonra baska bir terminal penceresi acarak 

git clone git://localhost/hello.git network_hello
cd network_hello
ls

Dip Not : Windows kullanicilari icin satir sonundan dolayi degismis gibi gorunen dosyalar icin

Ø    git config --global core.autocrlf true

Devam edecek ...

Github - 1

Github'a baslarken

Guncellemeye bugun github ile basliyorum. Bu konuyu tamamen anlamak cok cok onemli.

Yalniz program yazan bir programci ile, ekip ile yazan programci arasinda ciddi bir fark var. Ekip buyukse bu fark da buyuyor.

Github aslinda bir disiplin. Kullandiginiz araclar hem yalniz hem ekip ile yazmaniza imkan veriyor.

Kullanim mantigi diger benzerlerinden oldukca farkli.

Daha once Visual Source Safe ve SVN kullanmistim ama git bambaska birsey.

Once teknik olarak en bariz farktan yola cikalim. github'da server'dan bagimsiz hareket edebilmenizi saglayan bir altyapi var. Yani kodlari yazdiginiz alan, kodlari kendi bilgisayariniz uzerinde arsivlediginiz alan, ve sunucu uzerinde arsivlenen baska bir alandan olusan 3 asamali bir kod saklama mekanizmasi var.

Basitce github uzerinde bir hesap acarak ise basliyorsunuz.  (nasilini anlatarak zaman harcamayalim klasik yontemlerle deyip gecelim)

Hesabi acar acmaz iceridesiniz. Kullanici adi ve Parolaniz her zaman lazim olacak unutmayin

Isterseniz sag ustte isminizin ustune basip "Edit Profile" a basarak kendinize ait detay bilgiler ve fotograf koyabilirsiniz. Yani github aslinda size kodlarinizin arsivlenmesi ve paylasilmasinin otesinde bir de sosyallesme imkani taniyor.

Ubuntu Linux uzerinde bu islemleri gerceklestiriyor olacagim ama windows veya mac ile de ayni sonuclari alacaksiniz cunku hep command prompt'ta olacagiz

Altta kaynaklar kisminda linkini bulabileceginiz gitimmersion sitesinde adim adim ilk asamalarin nasil gecildigi var.

Sifirdan Basliyoruz

Ben sirayla yaptiklarimi ve gerekli yerlerde ne anlama geldigini yazarak ilerleyecegim.

cd Code
mkdir gittest
cd gittest
git init

Code dizinine gecip gittest diye bir klasor yaratip icine girdim. Sonra da git init ile bu klasorun git ile versiyon takibi yapilacagini bildirdim .

subl test1.rb

sublime ile test1.rb diye bir dosya olusturup icine "My First File" yazdim. Kaydedip ciktim

klasordeki dosyalarin durumlarini sorgulamak icin git status komutunu kullaniyorum.

git status

# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# test1.rb
nothing added to commit but untracked files present (use "git add" to track)

git bana test1.rb diye bir dosyanin bulundugunu ama takip edilmedigini soyluyor.

o halde takip edilmesi icin ekleyelim

git add test1.rb

bu sekilde dosya dosya ekleme yapilabildigi gibi "git add ." ile tum klasoru bir kerede ekleyebiliriz
Tekrar git status ile klasore bakiyorum

git status

# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
# new file:   test1.rb

Commit

simdi test1.rb adli dosyanin takip edildigi ama yapilan degisikliklerin "commit" ile kaydedilmedigini soyluyor. O halde commit ile degisiklikleri kaydedelim. Bu asamada diger versiyon kontrol sistemlerinden farkli olarak commit bu dosyayi server'a yollamayacaktir. Onun yerine kendi bilgisayariniz uzerindeki bir alana kopyalayacaktir.

git commit

bu komutu verdiginizde git size aciklama yazmaniz icin bir metin dosyasi acacaktir. Her commit sirasinda duzgun yazilmis aciklamalarla sonradan geri donmek kolaylasacaktir.

yazacaklarim bitince Ctrl + X ile bu ekrani kapatiyorum dosya ismini sordugunda enter ile kabul ediyorum

ve islem tamam. Artik ilk commit'im gerceklesti.

simdi text dosyami tekrar acip degisiklik yapip kaydediyorum. Boylece commit ettigim ile arasinda fark olusuyor.
git status ile degisiklikler hakkinda bilgi sahibi olabilirim

tekrar commit yapmak icin tekrar git add . ile eklemek veya git commit -a ile iki islemi birlestirmek zorundayim

git commit -m "degisiklik tanimi"

bu sekilde commit yaptiginizde tek satirlik bir aciklamayi komut satirinda ekleyebilme ve bir sonraki metin editorunun acilmasini engelleme sansina sahibiz. 

Sonra bir tane daha ayni adimdan yapip toplam 3 tane commit olmasini sagladim

Log

Simdi git log ile neler yaptigimi gorebilirim

git log

commit 913f1bff17b96d598ad446470e3128a949b8772e
Author: Macrop <Macrop@yahoo.com>
Date:   Thu Oct 17 13:14:23 2013 +0100

    3rd commit

commit 9c46dcbf6e44a8661e4219078003112084611cd8
Author: Macrop <Macrop@yahoo.com>
Date:   Thu Oct 17 12:05:05 2013 +0100

    My Second Commit

commit 3beabaffd7b3e716eda48111ab19c43bc3b80822
Author: Macrop <Macrop@yahoo.com>
Date:   Thu Oct 17 11:56:40 2013 +0100

    My First commit on test1.rb

bunu daha duzgun gormek icin parametre olarak asagidakini deneyebilirim

git log --pretty=oneline

913f1bff17b96d598ad446470e3128a949b8772e 3rd commit
9c46dcbf6e44a8661e4219078003112084611cd8 My Second Commit
3beabaffd7b3e716eda48111ab19c43bc3b80822 My First commit on test1.rb

git log'un aldigi parametrelere ornekler asagida. Daha fazlasini incelemek icin  man git-log 
denenebilir.

git log --pretty=oneline --max-count=2
git log --pretty=oneline --since='5 minutes ago'
git log --pretty=oneline --until='5 minutes ago'
git log --pretty=oneline --author=<your name>
git log --pretty=oneline --all

 oldukca duzgun gozuken bir log formati icin

git log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short

* 913f1bf 2013-10-17 | 3rd commit (HEAD, master) [Macrop]
* 9c46dcb 2013-10-17 | My Second Commit [Macrop]

* 3beabaf 2013-10-17 | My First commit on test1.rb [Macrop]

Configuration

simdi bazi kisaltmalar tanimlamak ve isimi kolaylastirmak icin vi ~/.gitconfig ile configurasyon dosyasini acip icine sunlari yazdim

[user]
name = Macrop
email = Macrop@yahoo.com
[merge]
tool = meld
[diff]
tool = meld
[alias]
  co = checkout
  ci = commit
  st = status
  br = branch
  hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
  type = cat-file -t
  dump = cat-file -p

Checkout

2. sirada yaptigim commit'e geri donmek istiyorum. git checkout <hash> ile ger donebilirim. hash icin git log ile aldigim listeye bakin.

git checkout 9c46dcb

HEAD is now at 9c46dcb... My Second Commit

dosyanin icine baktigimda tam olarak 2. commitim sirasindaki halini goruyorum.

cat test1.rb

Simdi tekrar son haline donelim

git checkout master
cat test1.rb

evet icerikte ekledigim 3. satir tekrar gozukmeye basladi

Tag

Bu commit'i v1 olarak isaretlemek (tag) istiyorum

git tag v1

onceki bir commiti tag ile isaretlemek icin ya hash ve checkout ile cagiriyorum ya da ozel bir kullanim ile v1'den bir onceki commit demek olan sunu kullaniyor ve oyle cagiriyorum

git checkout v1^

Bir kere tagladiktan sonra tag ile checkout yapabilirim

git checkout v1

git tag

sadece git tag yazarak tum taglarimin listesini alabilirim. Log aldigim zaman da taglari gormem mumkun

Son committen sonraki islemleri geri alma (git add yapilmadiysa - not staged)

committen sonra yapilan degisiklikleri yok saymak icin git checkout test1.rb ile yani dosya ismi ile checkout yapmak yeterli 

git checkout test1.rb

Son committen sonraki islemleri geri alma (git add yapildiysa - staged)

dosyada bir degisiklik yaptiniz sonra git add ile commit icin hazirladiniz ve farkettiniz ki geri alinmasi gereken bir durum var. git status ile baktiginizda aslinda size nasil geri alinacagini soyleyen bir mesaj veriyor. Yani kisaca soyle 

git reset HEAD test1.rb

iste geri dondunuz. Simdi stage area da kalan izi de yok etmek icin 

git checkout test1.rb

tamamen geri donmus olduk.

Commit'i undo ile ger cevirme (revert)

once bir commit ile bir degisiklik yapalim

git add test1.rb

git commit -m "istenmeyen degisiklik"

Simdi bu commiti geri cevirmeye calisalim

git revert HEAD
git hist
* 6483211 2013-10-17 | Revert "istenmeyen degisiklik" (HEAD, master) [Macrop]
* e4de5de 2013-10-17 | istenmeyen degisiklik [Macrop]
* 913f1bf 2013-10-17 | 3rd commit (v1) [Macrop]
* 9c46dcb 2013-10-17 | My Second Commit (v0) [Macrop]
* 3beabaf 2013-10-17 | My First commit on test1.rb [Macrop]

git hist icin yukaridaki configuration basligina bakin lutfen.
Gordugunuz gibi islem geri alindi ve geri alinma kaydi da ek olarak tarihceye eklendi.

Commit silme

Son islemi oops olarak tagliyorum

git tag oops

simdi reset  komutu ile son daha once v1 olarak tagladigimiz yerden sonraki commitleri siliyoruz

git reset --hard v1

HEAD is now at 913f1bf 3rd commit

git hist

* 913f1bf 2013-10-17 | 3rd commit (HEAD, v1, master) [Macrop]

* 9c46dcb 2013-10-17 | My Second Commit (v0) [Macrop]

* 3beabaf 2013-10-17 | My First commit on test1.rb [Macrop]

Aslinda silinmediler 

git hist --all
* 6483211 2013-10-17 | Revert "istenmeyen degisiklik" (oops) [Macrop]
* e4de5de 2013-10-17 | istenmeyen degisiklik [Macrop]
* 913f1bf 2013-10-17 | 3rd commit (HEAD, v1, master) [Macrop]
* 9c46dcb 2013-10-17 | My Second Commit (v0) [Macrop]
* 3beabaf 2013-10-17 | My First commit on test1.rb [Macrop]

--all parametresi ile tekrar gozukur hale geliyorlar

git tag -d oops
Deleted tag 'oops' (was 6483211)

git hist --all
* 913f1bf 2013-10-17 | 3rd commit (HEAD, v1, master) [Macrop]
* 9c46dcb 2013-10-17 | My Second Commit (v0) [Macrop]
* 3beabaf 2013-10-17 | My First commit on test1.rb [Macrop]

Tagi silince komple silinmis oldu. 

Commit duzeltme

bir commiti yaptiktan sonra icinde duzeltme yapmak da mumkun 

subl test1.rb
git add test1.rb
git commit -m "Amending"
[master 5889e7a] Amending
 1 file changed, 2 insertions(+)

subl test1.rb
git add test1.rb
git commit --amend -m "Amending ext"
[master cf5ccc3] Amending ext
 1 file changed, 3 insertions(+)

git hist
* cf5ccc3 2013-10-17 | Amending ext (HEAD, master) [Macrop]
* 913f1bf 2013-10-17 | 3rd commit (v1) [Macrop]
* 9c46dcb 2013-10-17 | My Second Commit (v0) [Macrop]
* 3beabaf 2013-10-17 | My First commit on test1.rb [Macrop]

once text dosyasina bir seyler yazdim ve commit yaptim
sonra birseyler daha yazdim ve tekrar commit ederken --amend parametresini kullandim.

Dosya tasima

git tarafindan takip edilen bir klasorde tasima islemini su sekilde gerceklestiriyoruz

mkdir lib
git mv test1.rb lib
ls
lib

git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#

# renamed:    test1.rb -> lib/test1.rb

normal mv komutu yerine git komutu kullanmama dikkat edelim. Bolye yaparak aslinda asagidaki gibi yazsam da yapilacak olan islemi bir kac adim kisaltmis oluyorum

mkdir lib
mv hello.rb lib
git add lib/hello.rb
git rm hello.rb

.git dizini

ls -C .git
branches  COMMIT_EDITMSG  config  description  HEAD  hooks  index  info  logs  objects ORIG_HEAD  refs

cat .git/config

Son commit

Son yapilan commit i bulmak icin

git hist --max-count=1


git cat-file -t <hash>

git cat-file -p <hash>

Kullanici Degistirme

global olarak git kullanici adi ve emailini girmek icin

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

lokal olarak bir dizinin baska bir kullanici ile iliskilenmesi icin

git config user.name "Your Name"
git config user.email "you@example.com"

Simdilik burada kaydediyorum ama branch kavramindan baslayarak devam edecegim

---

Kaynaklar 

http://www.github.com
http://gitimmersion.com