source code etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
source code etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

5 Mart 2014 Çarşamba

MVC dunyasinda ilerlemek

Gecen seferki yazimda bahsettigim video serisini bastan sonra seyrettim, notlar aldim, programci arkadaslarla konuyu tartistim ve nihayet ilk projeyi gelistirme asamasina geldigimi hissediyorum. Kendimi bilgi seviyesi olarak baslangica gore cok daha ileride goruyorum. (Uzmanliktan cok uzak ama ana hatlari kavramis)

Bir hayli not aldim. Bu video serisi inanilmaz faydali. isinize yarayacak hemen hemen her yere dokunuyor. Ruby kursunda bile canli olmasina ragmen konular bu kadar iyi anlatilmamisti . Sonucta video derslerin TDD (Test Driven Development) konusuna girmesi de cok yerinde bir yaklasim oldu.

Simdi su konularin ne oldugu nasil ve nerede kullanilacagini anladim

  • Razor
  • MVC
    • Model
    • View
      • bundling
      • layout
      • partial view
    • Controller
      • Ajax
      • Data connection
  • Entity Framework
  • Tests
  • Cache
  • OpenID
  • Authorization / Authentication 

Bu ogrendiklerimi simdi sicagi sicagina bir projede kullanarak pekistirmem gerekiyor. Elimde .NET Form View ile yapmaya calistigim ama yarim kalmis bir proje var. Bu projeyi bastan MVC ile yazmayla baslayabilirim. Sonucta zaman sikintisi olmayan bir konu oldugundan daha rahat davranabilirim. Biraz da sans ile sanirim is yerinde de bir tane baslanmis ama gelistirilmeyi bekleyen MVC projesi devraldim.

Birden soguk suya atlamak bazen en iyi ogrenme sekli. Sadece bu sular cok soguk oldugu icin onceden biraz isinma hareketi yapmakta fayda var. O yuzden mutlaka konsepti tam anlamiyla cozmek sart.

Simdi biraz kapanip is yapma zamani.
Kullanacagim versiyonlar

JQuery 1.8.2
MVC 5.1
.NET 4.5

27 Şubat 2014 Perşembe

MVC dunyasina gec bir giris

Uzun zamandir uzerinde calistigim, bakim yaptigim tum projelerin web-forms tabanli olmasindan dolayi erteleyip durdugum MVC dunyasina artik girme zamani gelmisti. Kendime bu sene icin cizdigim rotanin bir parcasi olarak izleyecegim yolun adimlari buradan geciyor.

Bu sene icin kendimi zamani yakalamaya adadim diyebiliriz. Sene sonuna kadar extreme programming konusunu tam anlami ile uygulamaya gecirmis olmak istiyorum.  Ama bu konuya klasik konvansiyonel yontemlerden direk olarak dalinca duvara tosladim. Onun icin kendime gecisli bir plan hazirladim. VB.NET ile ASP.NET uzerinde web-forms kullanan birisinin her ne kadar klasik ASP gecmisi olsa da baliklama Ruby'e girmesi (en azindan benim yasimda) husran olabiliyor.

Dolayisiyla bildigim ortamdan yola cikarak gecisler yapa yapa hedefe ulasacagim bir rota belirledim. Bu rota;

  1. GIT
  2. C#
  3. MVC
  4. Entitiy Framework
  5. TDD
  6. BDD
  7. S.O.L.I.D.
  8. Ubuntu
  9. Ruby
  10. Ruby on Rails
  11. Cucumber
  12. MongoDB
Hepsini sirayla yapmak biraz zor. cunku ic ice gecmis yapilar da var. Dolayisiyla ilk 6 maddeye ayni anda girmek durumunda kaldim. Bu gecis en azindan kavramlarin oturmasi icin yararli oluyor.

Bir suru kitap indirdim, okudum, makalelere daldim ve en sonunda super bir video kurs ile tanistim. ilk 6 madde icindeki 4 konuyu kapsayan bu kursu eminim arayinca siz de bulabilirsiniz ama kolaylik olsun diye bir kez de ben yazmak istedim.

ya da buradan direk ulasabilirsiniz 

Kaynak kodlarina da buradan ulasabiliyorsunuz 

Altyazi secenegi ile ingilizce veya Turkce altyazi acabiliyorsunuz ama uyarayim Turkce google translate Turkcesi. Yani birsey anlasilmiyor. ama ingilizce altyazi ile konusmada anlayamadiginiz bolumleri yaklalamak daha kolay olabiliyor. 




6 Şubat 2014 Perşembe

Projelerde yeni yaklasimlar - Fil yemek

Merhaba

Bu hafta calistigim sirketce yazilim gelistirmede yeni bir yaklasima gectik. Pilot calismasi yapildiginda herkesin mutlu oldugu bu modeli sirketce benimseme karari aldik.

Önce

Yazilimda simdiye kadar Agile metodolojisi kullaniyorduk, en modern, kullanisli ve ise uygun yapilari uygulamayi seven bir sirkette calismak gercekten cok hos bir tecrube.

Simdiye kadarki sistemde, proje sahibi ihtiyaclarini ve taleplerini bir panel'e onem derecesi vererek yapistiriyordu (bunun fiziksel post-it veya index card yapilari da mevcut, bilgisayar ortaminda olanlari da)

Sonra "İş Analist"i (Business Analyst) toplanti organize edip isin detaylarini ogreniyor ve bu isi iligli yazilim biriminin tahtasina ihtiyaclar, beklentiler, kabul kriterleri, etkilenecek yerler gibi detaylarini da kapsayacak sekilde yazip asiyordu.

Yine analisr proje sahibi ile konusarak oncelik sirasina gore bu "ticket"'i siraliyordu

Ilgili yazilim birimi elindeki is yogunluguna bakarak Ticket'i ele aliyor ve uzerinde calisip bitirince test kolonuna asiyordu. Test onay verdikten sonra proje sahibi isi gorup is acisindan test ediyor ve kabul verince is hayata geciriliyor ve sonuclaniyordu.

Cok da duzgun isleyen bu sistemin bir handikapi bazen oncelikler bazen isin geregi olarak bekleyen "ticket"lar guncelligini yitirebiliyor veya buyuk parcalar halinde yazilim yapimasi gereginden dolayi uzun zaman alabiliyordu. Yazilimcinin gorusu pek alinmadigi icin yazilim sirasinda ortaya cikan uyumsuzluklar bircok toplantiya ve analizlerde revizyona ihtiyac duyabiliyordu.

Yine de bu yapinin tum bu aksayan yanlara ragmen oldukca akici bir sistem oldugunu da kabul etmemiz gerekiyor. Bu sistem icin Agile Zen kullaniyorken sonra oylama ile Trello'ya gectigimizi de dipnot olarak vereyim.

Bu sistem ocellikle BDD ve TDD yapilari ile son derece uyumlu oldugu icin genelde cok de benimseniyordu.

Sonra

Simdi ise neredeyse tum bunlari cope attigimiz yeni bir sistem ile karsi karsiyayiz. Dun dagitilan dokumana gore prensipleri asagida yazacagim . Orjinal dokumana buraya tiklayarak ulasabilirsiniz (Ingilizce)


  • Analiz onceden yapilmayacak, ise baslandiginda aninda yapilacak
  • Buyuk is parcalari tanimlandiginda, kucuk bitirilip test edilebilir parcalara bolunecekler
  • Analist, yazilimci, proje sahibi ve testci proje boyunca birarada calisacak
  • Analist maestro gibi calisacak, tikanikliklarin  hizla cozulmesine katki saglayacak
  • Proje sahibi gunluk 5-10 dakikalik hizli durum degerlendirmesi toplantilarina katilacak
  • "Ticket" lar kisa ve hemen halledilebilir boyutlarda olacak
  • "Ticket" lar kabul kriteri kivaminda olacak (onceden yazilan 15 - 20 maddelik kabul kriterlerinin her biri bir "ticket" olacak
  • isler "minimum teslim edilebilir is" olarak degerlendirilecek ve biten her kucuk parca dagitilacak (deploy) (Benim bu konuda ciddi endiselerim var mesela )
  • Hangi "ticket"larin "minimum  teslim edilebilir is" oldugu tespit edilecek ve oncelik sirasina sokulacak
  • Kucuk dagitimlar ile Ana projenin fonsiyonelligi artirilacak
  • Guclu bir iletisim esas olacak
  • Haftalik olarak "ne yapildi ne yapilacak" toplantilari duzenlenecek
  • Oncelik  proje sahibince belirlenecek (teknik oncelik yoksa)
Beklenen Faydalar
  • Proje sahibi isin daha fazla icine girerek isin yuruyusu hakkinda canli bilgi sahibi olabilir
  • Sorunlara ve sorulara cok daha hizli cevaplar uretilecek
  • Degisen ihtiyaclara daha esnek cozum uretilecek
  • Programcilarin yaraticiliginin onu acilacak (is hakkinda fikir uretip tartismasinin onu acilacak)
  • Daha cabuk dagitimlar (deploy) saglanacak
  • Daha kucuk "ticket"lar olacagi icin daha kisa test zamanlari olaacak = daha az hata cikacak
Evet mevzu bu sekilde ozetlendi. 

Bu yaklasima uygun olarak proje tahtalarinin bu sisteme uyumlu hale getirilmesi de dusunuluyor elbet. Eskiden tek bir tahta vardi ve Next Up kolonundan once bir kuyruk ile yapilacak isler siralanirdi. Simdi bir yazilim tahtasi ve buna ticket getiren diger tahtalar su sekilde duzenlendi

Hangi tahtalardan is geldigina bakacak olursak 
1 - Features : yapmak istenilen ama henuz kucuk parcalara bolunmemis isler
2 - Tech : sistem upgrade'leri, database bakimlari vs 
3 - Bugs : hatalar 
4 - Current : bolunmus ve yyapilmaya hazir isler 

Bu sistemde benim birkac yorumum ve cekincem var. Bu konu aslinda biraz da yazilim gelistirme dili ile de ilgili. Yani yukaridaki prensipleri hazirlayan ve pilot uygulamasini yapan ekipler Ruby ile calisiyorlar. Yani kodlar acik halde deploy ediliyor ve interpreter araciligi ile yorumlanip calisiyor. Bu da onlara kucuk parcalarin dagitiminda esneklik sagliyor. Halbuki benim kullandigim yapi .NET ve compile edilerek deploy edildigi icin bu esneklige sahip degilim. (Klasik ASP'nin gozunu seveyim) 

Benim calistigim proje .NET 1.0 da baslayip senelerce bu sekilde devam etmis yani yapi olarak eski ve hantal. TDD ve BDD ile uyumlu degil. yani kucuk, test ve teslim edilebilir  parcalar icin uygun ortami saglamiyor. Projenin .NET uzerinde yeniden yazilmasi zaten konu disi yani yeniden yazilacaksa Ruby'de yazilacak ve bu cok ust duzey bir karar gerektirdiginden bu konuda adim atilamiyor. 

Genel olarak yapklasim bana Turkiye'deki "Ati kosarken nallayalim", "kervan yolda duzulur" yaklasimlarini hatirlatti. Dolayisiyla bence Turkiye bu yaklasima daha yatkin bir ulke. Ne dersiniz ? 
 





17 Ocak 2014 Cuma

Specflow ile .NET uzerinde BDD

Bir muddettir kendi kabugumda kalip surekli uretim yapmak yuzunden herseyden cok geri kalmisim. Simdi acigi kapatma zamani. Cok konu var yakalamam gereken birden tamamen farkli bir ortama bakinca birseyleri anlamak cok da kolay olmuyor. O yuzden gecisi su sekilde planladim.

Once bildigim ortamda ortak olan konulari ogrenmeye calisacagim. Dolayisiyla beynimi once ortama alistirmak icin .NET uzerinde MVC yapisina uyum saglayip, testleri burada yazacagim. Sonra yapiya uyum sagladigimda geriye sadece isletim sistemi ile dil kalmis olacak.

Bu yuzden halihazirda kendim icin yazdigim ama henuz bitirmedigim programi yeni yapilar ile yazmaya karar verdim. Normalde VB.NET kullanmama ragmen C# a da asinayim dogal olarak. Ancak simdiye kadar sadece bakim yaptim yani hic yeni proje gelistirmedim.
git bash

Catiyi su sekilde kuruyorum.
DilC#
OrtamMVC4
Yazilim ortamiVisual Studio 2010
Data baglantisiEntitiy Framework
BDDSpecflow
Unit TestMsTest.2010
Versiyon Kontrolgit ve bitbucket.com

Simdi adim adim ne yaptigima gelince

  • Bende zaten kurulu oldugu icin Visual Studio 2010 kullanacagim
  • www.bitbucket.com da bir hesap actim. (isterseniz github.com dan da acabilirsiniz)
  • git-bash veya git for windows'u indirip kurdum
  • http://www.asp.net/mvc/mvc4 adresinden MVC 4 u indirip kurdum 
    • (Bu arada MVC 5.1 cikti tabi http://www.asp.net/mvc/overview/releases/mvc51-release-notes)
    • Install-Package Microsoft.AspNet.Mvc -Version 5.1.0
  • http://visualstudiogallery.msdn.microsoft.com/9915524d-7fb0-43c3-bb3c-a8a14fbd40ee adresinden specflow'u indirip kurdum.
  • Diskte proje icin bir klasor actim
  • bitbucket'e login olup "create repository" ile bir repo actim
  • Git bash'a girip, Proje klasorune gectim. (cd ile eski usul :)) 
  • sirayla su komutlari calistirdim
  • git init
  • git remote add origin https://username@bitbucket.org/user/repo.git 
  • yukaridaki kirmizi alani kendi  bilgilerinizle degistirin. 
  • Visual Studio acip yeni bir proje actim. Visual C# / Web / ASP.NET MVC 4 Application 'u sectim ve klasor olarak yukaridaki actigim klasoru sectim. 
  • Sonraki ekranda Select a Template bolumunde "Internet Application", View Engine'e "Razor", Create a unit test project bolumune bir isim verdim ve OK'e bastim
  • Razor'u secmemdeki temel etmen internette aradigimda TDD icin uygun olmasiydi
  • Visual studio icinden Tools/Library Package Manager / Package Manager Console  acip icinde "install-Package SpecFlow -ProjectName RM.Specs" yazip enter'a basarak yukledim. RM benim projemin adi bu arada 
  • sirayla sonra sunlari calistirdim
  • Install-Package SpecFlow.NUnit
    Install-Package SpecRun.SpecFlow
  • Test projesinin icinde Features diye bir klasor actim.
  • klasore sag tiklayarak add new item -> SpecFlow Feature File secerek Restaurant diye bir feature ekledim
  • Test projesinin icinde Steps diye bir klasor actim
  • Restaurant.feature dosyasi icinde herhangi birseyi henuz degistirmeden sag tiklayip acilan menude  "Generate Step Definition" i sectim. ve dosyayi Steps klasorune kaydettim
  • test projesindeki App.Config dosyasinda su degisikligi yaptim 
  • <specFlow>
        <!-- <unitTestProvider name="MsTest" /> -->
      <unitTestProvider name="MsTest.2010" /> 
    </specFlow>
  • Restaurant.feature dosyasi acikken visuaal studio'da  sag tiklayip Run Specflow Scenarios u secerek testlerin calismasini sagladim. 
  •  Test'ler Pending durumunda oldugu icin calismadilar ama Specflow Step'leri calisti. Yani bu asamaya kadar hersey dogru. 
Calisma ortamimiz hazir olduguna gore bu haliyle git'e atabilirim.
git bash ile proje klasorunun icindeyken 

git add .
git commit 
(mesajinimizi yaziyoruz) 
git push origin master 

Gelismeleri paylasacagim. 


18 Ekim 2013 Cuma

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 ...

17 Ekim 2013 Perşembe

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