Git deposunu lokalde oluşturmak

Git sistemini kullanmak için önce uzak bir sunucudan Git deposunu lokalimize indirelim. Bu komut SVN’deki checkout’a denk geliyor diyebiliriz (mantık tam olarak benzemese de).

git clone [-b <branch_adi>] <depo_adresi> [<indirilecek_klasor_adi>]

Bu komutta herhangi bir Git deposunu tüm branch bilgisiyle ve ya sadece belirli bir branch’i belirttiğimiz bir klasöre indiriyoruz. Daha sonra bu klasöre geçiyoruz.

Lokaldeki değişiklikleri görmek

Depoyu ve dosyaları lokale indirdikten sonra bazı değişiklikler yaptık ve ne olduğu görmek istiyoruz, bu durumda aşağıdaki komuttan faydalanıyoruz.

git status

Bu kısacık komut bize çalışma klasörümüzde versiyon açısından neler olup bittiğini gösteriyor. Git ayrıca bir takım ufak yorum satırlarıyla bize yardımcı olmaya çalışıyor

$ git status
# On branch dev
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       README
nothing added to commit but untracked files present (use "git add" to track)

Gönderilecek değişiklikleri işaretlemek

Git’in de anlattığı üzere, README dosyası şu an sistem tarafından takip edilmiyor ve bunu takip edilecek olarak işaretlemek için aşağıdaki komutu çalıştırmak gerekiyor.

git add <dosya_yolu>

Burada dosya yolu tam olarak verilebilir ya da sadece “.” verilerek tüm değişikliklerin eklenmesi sağlanabilir. Önemli bir nokta, yukarıdaki komutu sadece yeni dosyaları sisteme eklemek için değil, varolan dosyalarda  yapılan  değişiklikleri göndermek için de kullanıyoruz. Yani README dosyası daha önce sisteme eklenmiş olsaydı ve bazı güncellemeler yapıp göndermek isteseydik, yine aynı komutu kullanacaktık.

Değişiklikleri göndermek (commit)

Gönderilecek olan tüm değişiklikleri işaretledikten sonra Git sistemine gönderme işlemini gerçekleştiriyoruz.

$ git commit -m "added README file"
[dev b9b5954] added README file
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README

Git her versiyon oluşturma aşamasında bizden yapılan değişikliklere ait bir mesaj girmemizi ister. Bunu -m parametresinden sonra belirtiyoruz. Buraya “qweqwe” yerine anlamlı bir şeyler girerseniz ileride kendinize teşekkür edersiniz Bu işlemden sonra bir versiyon oluşturmuş olduk.

Lokaldeki versiyonu uzak bir sunucudaki Git deposuna atmak

Her ne kadar Git sisteminde zorunlu olmasa da, projenizi başkaları ile geliştiriyorsanız ortak bir uzak depo kullanmak zorundasınız. Değişikliklerinizi lokal Git deposuna gönderdikten sonra paylaşılan uzak bir depoya (GitHub gibi) da gönderebilirsiniz. Bunun için şu komuttan faydalanabilirsiniz.

git push <uzak_depo_adi> <branch_adi>

Eğer değişiklik yapmazsanız uzak depo,  projeyi ilk aldığımız depoyu gösterecektir ve branch “master” olacaktır.  Eğer yetkiniz varsa en son versiyonunuzu depoya bu komutla gönderebilirsiniz.

Daha detaylı komutları ilerleyen yazılarda paylaşacağım

Daha önceki yazılarımızda versiyon kontrol sistemlerinin yazılım geliştirme için önemini belirtmiştik. Bu yazıda diğer versiyon kontrol sistemlerinden farklı ve  oldukça esnek bir yapıya sahip olan Git versiyon kontrol sistemini genel olarak anlatacağım.

Git versiyon kontrol sistemi, Linus Torvalds tarafından BitKeeper yerine geliştirilmeye başlamış bir versiyon kontrol sistemidir.  Linux’un geliştirilmesinde kullanılan BitKeeper’ın açık kaynak lisansı kaldırılınca Git sistemi geliştirilmeye başlamıştır. Git geliştirilirken ön planda tutulan tasarım kriterleri dağıtık olması, tutarlı olması, büyük projelerde verimli bir şekilde çalışması ve doğrusal olmayan çalışma şekillerini desteklemesi olarak sayılabilir. Git sisteminin bazı özelliklerinin şöyle listeleyebiliriz:

• Dağıtık (Distributed)  Sistem: Git işletim sisteminde, her kullanıcının lokal çalışma alanı bir sunucu görevi görür. Her kullanıcı kendi lokalinde versiyonlama ve geri yükleme yapabilir, SVN’de olduğu gibi başka sunuculara ihtiyacı yoktur. Dilediğinde lokalindeki değişiklikleri merkezi bir sunucuya atarak herkesle paylaşabilir. Birçok işlem lokalde gerçekleştiği için yapılan değişiklikleri listelemek, yenilerini commit etmek, geri almak, yeni bir branch açmak ve ya branch’ları birleştirmek işlemleri hızlıca gerçekleşir. Yani örneğin internet olmayan bir yerde tüm geliştirmelere devam edip, daha sonra uzak bir sunucuya değişiklikleri atabilirsiniz.
• Performans: Birçok işlem lokalde yapıldığından, diğer versyion kontrol sistemlerine göre Git daha hızlı sonuç vermektedir. Ayrıca branch işlemlerinde de diğer sistemler gibi branch dosyalarını ek bir klasörde tutmayarak bir çeşit pointer mantığı kullanmaktadır. Böylece çok sayıda branch içeren büyük projelerde de iyi sonuç vermektedir.
• Tutarlılık (Integrity) : Versiyon kontrol sistemlerinde versiyonlar arası geçişlerde bilginin bozulmaması ve tutarlılık çok önemlidir. Git, sisteme eklenen her bir dosyanın SHA-1 algoritmasıyla hash bilgisini oluşturarak bu bilgiyi kaydetmektedir. Bu nedenle versiyonlar arası geçişte bilgi kaybı olması söz konusu değildir.
• Mevcut Protokollerle Entegrasyon : Git  sunucuları HTTP üzerinden hizmet verebilirken, SSH ve ya Git protokolü üzerinden de dosyalarınızı sunabilirsiniz.

Git Sisteminin İşleyişi

Git sistemini ve komutlarını doğru kullanmak için işleyişini net olarak anlamak gerekiyor. Aşağıda anlatılanlar ve şemayı anlamak oldukça kritik, bunları anladıktan sonra Git kullanmak çok kolay diyebilirim

Git sisteminde dosyalarımızın bulunabileceği 3 durum bulunuyor:  modified(düzenlenmiş),  staged(gönderilecek), ve committed(gönderildi). Git’e eklemediğimiz fakat proje klasöründe yer alan dosyalar ise untracked (takip edilmiyor) durumunda oluyor.

Dosyaları Git sistemine eklersek ve ya zaten eklenmiş olan dosyalarda değişiklik yaparsak bu dosyalar modified durumuna geçiyor. Modified durumundaki dosyaları bir sonraki commit işleminde gönderilmek üzere işaretlersek durumu staged olarak değişiyor . Daha sonra commit işlemi gerçekleştirdiğimizde sadece staged durumdaki dosyalar commit işlemine dahil ediliyor ve commit ile gönderiliyor, böylece committed  durumuna sahip oluyorlar.

Yukarıdaki şemada da genel kullanım sırasına göre klasörler arası geçişi görebilirsiniz. Önce bir Git klasöründen (git directory) ilgili dosyaları lokal çalışma alanımıza (working directory) alıyoruz (checkout). Daha sonra projede değişiklikler yapıp bu değişiklikleri gönderilecek olarak işaretliyoruz, ilgili dosyalar gönderilecekler alanına atılıyor (staging area). En sonunda da bu değişiklikleri gönderiyoruz (commit) ve ilgili Git klasörüne bunlar gönderiliyor. Burada Git klasörü SVN’deki gibi uzak bir sunucuda yer almıyor, her kullanıcının lokal çalışma alanı bir sunucu görevi gördüğü için, bu işlemler lokalde yapılıyor.

Eğer durum geçişlerini tam olarak anladıysanız bundan sonraki yazılarda anlatacağım komutları anlamakta zorluk çekmeyeceksiniz demektir Git’e hoşgeldiniz diyelim o zaman

Kaynaklar

http://progit.org/book/

http://en.wikipedia.org/wiki/Git_(software)

Öncelikle Heroku nedir? Heroku Bir bulut (cloud) uygulama platformudur. Java, php, python vb gibi dilleri hızlıca geliştirip Scale edebilirsiniz. Böylece server Kurmayla, çalışma ortamı yaratmayla uğraşıp durmanıza gerek kalmayacak ve doğrudan canlı ortam görmüş olacaksınız. Bilgisayarınızda geliştirin, heroku da deneyin!

Facebookta da bir uygulama oluşturduğunuzda (https://developers.facebook.com/apps adresinden) artık oradan cloud services kısmından herokuyu seçebiliyorsunuz. Ve Şipşak anında facebook applikasyonunuz elinizde.
Bundan sonra yapmanız gereken herokunun heroku toolbelt’ini indirip, git ile birlikte kullanmayı öğrenmek olacaktır.

Git dediğimiz şey de versiyon kontrol sistemidir. Konsoldan kullanılabilecğei gibi, Mercurial, Tortoise gibi programlar üzerinden de arayüzlü bir şekilde kullanabilirsiniz.

Heroku’ya üye değilseniz facebook applikasyonunuzda herokuyu seçtiğinizde otomatik olarak hesabınızı da oluşturuyor. Siz sadece mailinize gelen instructions’ı okuyun yeter!

Başka bir yazıda kullanımını da anlatabilmek isterim.

Bu sistem kısaca şöyle çalışıyor. Bir dosya merkeziniz var. Burada dosyalar, değiştikçe, versiyon kontrol sistemi o dosyanın bir önceki halini saklıyor. Bu da gerektiğinde 1000 kere değişiklik yapılmış bir dosyada 300. halini görebilme imkanı dahi sağlıyor. Bunları yaparken ise gerekli yorumları yazdığınız takdirde, önceden ihtiyacınız olp da yaptığınız her şeyi görebiliyorsunuz. Dosya merkezini internete açık bir bilgisayara kurarsanız da, oraya erişebilen tüm kullanıcılar projeye dahil olabilmiş olur. Yaptıkları değişiklikleri buraya gönderirler (commit) ve yazılımın ana haline dahil etmiş olurlar.

Bazen 2 veya daha fazla kişi aynı dosya üzerinde değişiklikler yapıyor olabilirler. Bu gibi durumlarda ise “sen ne yaptın, ben şurayı düzelttim, al sana MSN den yolladım, oraya yapıştır, ama şurayı da düzeltmen gerekiyor, off puff…” gibi duyumları öncelerden sıkça duyuyoruz. Bu gibi durumlarda versiyon kontrol sistemlerinde gerek dosya kilitleme, (o dosyada kimsenin çalışmasına izin vermeme), gerekse de kim önce değişikliği gönderdiyse, sonradan gödnerenin yaptıklarının kaybolmadan – en azından tamamen silinmeden işlerini devam ettirme ve tamamlama şansı olabiliyor.

TortoiseSVN benim sıkça kullandığım programdır. http://tortoisesvn.tigris.org/ adresinden ulaşabilirsiniz.

Bir de bu hizmeti ve bunla birlikte dahili olarak yazılım geliştirmek için hizmet veren çeşitli internet tabanlı , siteler de mevcut. http://www.repositoryhosting.com da bunlardan biri. Bu konuya da başka bir yazımda değinmeyi düşünüyorum.

Büyük veya küçük çaplı tüm projelerde versiyon kontrol sistemleri mutlaka kullanılmalıdır diye düşünüyorum.

Bir proje başlattığınızda ilk versiyonu ne zaman çıkaracaksanız da, bunun için kendinize bir sayaç oluşturup, buna bağlı kalmanızı tavsiye ederim. http://www.coonter.net