Github.com veya bitbucket.org üzerinde farklı farklı email adresleriyle oluşturduğunuz  projeleriniz olabilir ve tek bilgisayarda hepsine RSA key tanımlayarak çalışmak istiyor olabilirsininiz. Burada yapmamız gereken işlem hangi projenin hangi RSA key ile haberleşeceğini belirlemektir. Eğer bunu belirlemezsek sonradan eklediğimiz projelerde ilk eklenen projenin RSA keyi ile güvenli bağlantı kurmaya çalışır ve hata alırsınız.

Eğer 2. bir proje için RSA key tanımlamak istiyorsanız zaten daha önceden RSA key tanımlamayı öğrenmişsinizdir diye düşündüm. Yine de bilmeyenler bu linkteki adımları izleyerek kolayca RSA key oluşturabilirler.

İlk olarak RSA key dosyalarımızın bulunduğu dizine gidelim :

cd ~/.ssh

Şimdi bahsettiğim hangi projenin hangi RSA dosyasını kullanacağı bilgilerini tanımayacağımız ayar dosyamızı oluşturalım :

touch config

Şimdi bu dosyamızın içine şu ayarları ekleyelim :

# ilk projemizin ayarları.
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_rsa

# ikinci projemiz
Host github-second-account
HostName github.com
User git
IdentityFile ~/.ssh/ikinci_projemizin_rsa_key_dosya_adi

Burada hangi dosyamızın hangi projeye ait olduğunu belirttik. IdentityFile alanında ilgili RSA dosyasının tam pathini veriyoruz. Host alanında bir maske oluşturuyoruz. Örneğin 2. projemizde github.com adresinde. Bu sebeple aynı yerlere bağlanıyorlar. O yüzden bağlanırken hangi RSA dosyasını alacağını bulmak için bir maske oluşturuyoruz ve farklı bir ad veriyoruz.

Maske şu şekilde kullanılıyor. 2. projeyi çekerken :

git clone git@github-second-account:user/project.git

Şeklinde kullanıyoruz ve proje çekildikten sonra RSA key aktif olmuş bir şekilde kullanmaya başlıyoruz. Afiyet olsun

Şurada okuduğumuz yazı da belirtiyor ki, FTP den dosya yüklerken , .svn klasörlerini ve içeriklerini de yanlışlıkla yükleme ihtimalimize karşı, (veya .git klasörünü) projemizin kaynak kodlarının tamamının çalınma riski oluşuyor. Hatta risk değil bu, direkt buyrun alın diyorsunuz. Bu klasörlerin içinde versiyon kontrol sistemi dahilinde olan kaynak kodların tamamı ve her versiyonu bulunuyor.

SVN ‘de FTP den atacaksanız export işlemi yapıp, projeyi SVN dosyalarından arındırmanız gerekiyor.

Google’da şu aramayı yaparsanız eğer, zaten dediğimi anlayacaksınız :

“.svn” intitle:”Index of” 

Bu yüzden, projelerinizde versiyon kontrol sistemlerini kullanıyorsanız (kullanın tabi ki..) , bu duruma özellikle dikkat ediniz. Sonradan başınız yanmasın.

-Git daha verimli çalışma için daha önce oluşturulmuş ve değişiklik yapılmamış olan belgeleri yeniden kaydetmez. Bunun yerine daha önce kaydedilmiş olan belgeye link oluşturur. Bu özellik Git versiyon kontrol sistemini diğerlerinden ayıran en önemli farktır.

-Git’in hızlı çalışması birçok işlemi localde gerçekleştirmesi sayesinde mümkün olmaktadır.Bütün değişiklik tarihi bilgisayarınızda tutulduğu için işlemler çok hızlı yapılabilmektedir.Örneğin projenin geçmişi ile ilgili bilgilere erişmek istediğinizde git uzak sunucuya giderek herhangi bilgi çekme gereksinimi duymaz ve gerekli bilgileri zaten makinenizde barındırdığından anında size sunar. Git’in local bazlı çalışması sayesinde offline olduğunuz durumlarda diğer versiyon kontrol sistemlerinin aksine yapamayacağınız çok az şey oluyor.

-Git herhangi bir bilginin kendi kontrolü dışında değiştirildiğini anında tespit eden bir mekanizmaya sahiptir. Git’in kullandığı bu mekanizma “SHA-1 hash” olarak adlandırılmaktadır. Her bir belge ve projenin dosya yapısına karşılık gelen 40 karakterden oluşan bir string oluşturulmaktadır. Bu sayede git kendi bilgisi dışında yapılan değişiklikleri anında algılar.

-Git sayesinde işlemlerimizi daha cesurca gerçekleştirmemiz mümkün çünkü herşeyin kaydı tutuluyor ve istediğimiz zaman değişiklikleri geri alabiliriz. Kısaca elimizi korkak alıştırmaya gerek yoktur.

–Önemli: Git kullanırken belgelerimiz 3 aşamadan birinde olur. Bunlar “committed”, “modified” veya “staged” aşamalarıdır.

Commited: Belgenin başarılı bir şekilde değiştirildiğini ve local veritabanına kaydedildiğini belirtir.

Modified: Belgeyi değiştirdiğiniz ancak henüz commit etmediğiniz aşamadır.,

Staged:   İki farklı belge üzerinde çalıştığımızı varsayalım. Bir belgede yapmayı planladığımız bütün değişiklikleri o gün içerisinde tamamlıyoruz diğer belgede başladığımız işi ise tam olarak tamamlayamadan commit yapmak istiyoruz. Bu durumda henüz tamamlanmamış olan belgemizi commit etmek yerine onu staged olarak işaretliyoruz ve commit yaptığımızda sadece işimizi tamamladığımız belgenin commit edilmesini sağlamış oluyoruz. Orijinal açıklama için buraya bakınız

-Git’de belgeleriniz 3 farklı dizin vardır bunlar orijinal isimleriyle şunlardır: Git directory, working directory ve staging area

Git Kurulumu (Linux – Ubuntu)

Git’in bağlı olduğu bazı kütüphanelerin kurulumunu gerçekleştirmek gerekiyor öncelikle. Bunlar curl, zlib, openssl, expat ve libiconv kütüphaneleridir. Bunun için şöyle bir komut yazıyoruz:

$ sudo apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \libz-dev libssl-dev

Daha sonra aşağıdaki komutu yazarak git kurulumunu gerçekleştirmeniz gerekmektedir.

$ sudo apt-get install git-core

Git Konfigürasyon Ayarları

Aşağıdaki komutları kullanarak isminiz ve email adresiniz gibi bilgileri tanıtabilirsiniz.

$ git config –global user.name “Ferid Mövsümov”

$ git config –global user.email [email protected]

Burada –global kullanarak ayarlarınızın sistem bazında tanıtılmasını sağlamış olursunuz. Yani makinenizdeki bütün git işlemleri için bu ayarlar geçerli olacaktır.

Yorumlarınızı yazarken kullanılacak varsayılan editörü belirlemek için aşağıdaki komutu kullanabilirsiniz. Eğer bu ayarı belirtmezseniz sisteminizdeki varsayılan editör kullanılacaktır.

$ git config –global core.editor emacs

Versiyonlar arasındaki değişiklikleri incelemenizi sağlayan varsayılan diff aracını belirlemek için aşağıdaki komut kullanılabilir

$ git config –global merge.tool vimdiff

Sistemde tanımlı olan git ayarlarını görmek için aşağıdaki komutu kullanmanız gereklidir.

git config –list

Git Yardım Komutları

$ git help <verb>

$ git <verb> –help

$ man git-<verb>

KAYNAK: http://git-scm.com/book

Eğer versiyon kontrol sistemleri ile ilgili pek bilgi sahibi değilseniz, buradan başlayabilirsiniz. Daha sonra bunların en çok kullanılanlarından GIT ve SVN arasındaki karşılaştırma için buraya göz atabilirsiniz. Ücretsiz private SVN (2 kişiye kadar) için buraya, aynı şekilde ücretsiz private GIT (5 kişiye kadar) için buraya göz atmanız faydalı olabilir.

Versiyon kontrol sistemlerini konsoldan kullanmak için buralardaki yazılarımıza da göz atabilirsiniz –>  [SVN] – [GIT]

Şimdi gelelim esas konumuza. Kurulumunu gerçekleştireceğimiz program, RabbitVCS, linux ortamımızda versiyon kontrol sistemlerini basitçe kullanmamızı sağlayan bir program. Kurulumdan sonra, aynı TortoiseSVN gibi kullanacağız. Arayüz neredeyse aynı

RabbitVCS sadece SVN için değil, GIT için de kullanılabiliyormuş, ikisi bir arada! Ancak ben şu an sadece SVN ile kullanıyorum, GIT ile kullandıktan sonra, karşılaştığım şeyleri ayrı bir yazıda anlatacağım.

RabbitVCS‘nin internet sitesine buradan erişebilirsiniz; http://rabbitvcs.org/

İlk olarak RabbitVCS ppa ekliyoruz;

sudo add-apt-repository ppa:rabbitvcs/ppa

Ardından da install ediyoruz;

sudo apt-get install rabbitvcs-core rabbitvcs-nautilus3 rabbitvcs-cli

Ayrıca eğer istiyorsak gedit extension da ekleyebiliriz;

sudo apt-get install rabbitvcs-gedit

Bu işlemlerden sonra bilgisayarımızı yeniden başlattığımızda, versiyon kontrol sistemini rahatça kullanabiliriz. Yapmanız gereken sadece sağ tık!

Bitbucket.org 5 kullanıcıya kadar size limitsiz ve ücretsiz repo hizmeti sunuyor. Diğer paketlerini incelemek isterseniz buraya göz atabilirsiniz.

Kişisel olarak hesap açabileceğiniz gibi, takım olarak da hesap açabiliyorsunuz. Onu da şuradan yapabilirsiniz.

İyi çalışmalar!

SSH ile erişilebilen bir sunucuda, herhangi bir kullanıcı veya sistem yöneticisi iseniz git deposunu saklaması için açıalcak hesapta, ssh ile uzaktan erişilmesi için gerekli düzenlemeleri yapalım.

adduser git # git deposu için yeni kullanıcı git oluşturduk.
# .ssh dizini oluşturalım ve yetki verelim
/home/gitmkdir -f .ssh 
chmod 700 .sshcd .sshtouch authorized_keys 
# erişebilecek kişilerin public anahtarlarını ekleyeceğimiz dosyaya da yetki verelim.
chmod 600 authorized_keys
#Yeni bir depo kurmak için git kullanıcısı ile sisteme girdikten sonra aşağıdaki komutları kullanabilirsiniz.

mkdir ~/repo.git
cd ~/repo.git
git --bare init

Olay bu kadar basit aslında.

Subversion (Svn) ve Git Versiyon Kontrol Sistemleri Karşılaştırması

Takımınız için en iyi yazılım deposunu (repository) seçerken, bir takım önemli faktörler vardır. SVN (Subversion) geçtiğimiz yıllarda üretimde fiili olarak bir standart haline geldi ve kullanıldı. Ancak, daha sonradan hayatımıza Git diye bir şey girdi.

Git, Linus Torvalds tarafından Linux çekirdek geliştirilmesi amacıyla geliştirilmiş versiyon kontrol sisteminin dağıtılmış versiyonudur. Yıllar içerisinde, yazılım geliştirme amacıyla kullanılmış ve özellikle Open Source projelerin oluşturulmasında rol alarak da çok büyümüştür. Git, çoğu takım için daha iyi bir çözüm olmasına rağmen, SVN ile kıyaslandığında azıcık daha öğrenmesi zor olarak nitelendirilebilir.

Svn & Git farklarının objektif olarak özeti

• Git Svn den epeyce hızlıdır.
• SVN ile bir alt ağacı(subtree) indirip çalışabilirsiniz, ancak Git’te tüm projeyi klonlamanız gerekir. Bu klonlama ile kendinize geçmişi dahil bir kopya üretmiş olursunuz.
• Git depoları, SVN ye kıyasla epeyce daha küçüktür. Örneğin Mozilla projesi için 30 kat daha küçüktür)
• Git, baştan itibaren dağıtma amaçlı tasarlandığından, her geliştiriceye olabildiğince yerel kontrol imkanı sağlar. (örneğin bir şeyi yapıp kendinize commit edebilirsiniz. )
• Git branch’ları (yan dalları) , SVN’e göre basit ve daha az kaynak harcarlar.
• Git branch’lar kendi geçmişini tutarlar.
• Git branchlar üzerinde daha çok denetim ve karıştırma (merge) imkanı sağlar.
• Git depo dosyaları basittir. Tamir etme vb işlemlerinde ihtimaliz daha yüksektir.
• SVN depolarını merkezi olarak yedeklemek daha basittir.
• Git depo klonları, full bir klondur. Yani onun üzerinden yeni bir repo yapabilirsiniz.
• SVN nin kullanıcı arayüzü, Git’inkinden daha gelişmiştir.
• SVN nin versiyonlarında (revisions) dolaşmak 1,2,3,… şeklinde isim verdiğinden çok daha basittir. Git, ne idüğü belirsiz SHA-1 hash’ler kullanıyor.

Kaynaklar : GitSvnComparison, subversion_git_comparison

git checkout {dosya_adi}

Bu komut HEAD (en son sürüm) den dosyayı alıp mevcut dosyanın üzerine yazar.

İnternette git reset komutunu kullanmanızı söylenebilir. reset –hard derseniz mesela, tek bir dosya yerine tüm değişiklikleriniz gidebilir. Aman dikkat.

Hataları önlemek ve işleri kolaylaştırmak için Symfony2 ile birlikte ek kütüphanelerinizin versiyonlarının yönetildiği bir dosya ve bunun için tek basit bir komutla çalıştırabileğiniz bir program geliştirilmiş. Bu program git versiyon kontrol sistemini kullanıyor, dolayısıyla git sisteminin bilgisayarınızda yüklü olması gerekiyor. Eğer git yüklü değilse Windows’ta yüklemek için şuradaki talimatları izleyebilirsiniz.

deps Dosyası ve bin/vendors komutu

Öncelikle Symfony2 framework şu adresten ek kütüphaneler olmadan (without vendors) indiriyoruz, arşiv dosyasını açıyoruz. Arşivin açıldığı  klasörde deps ve deps.lock isminde 2 adet dosya göreceksiniz. Deps dosyasındaki her bir blok ek kütüphaneleri göstermekte ve ek kütüphaneler kurmak için kullanacağımız program bu dosyayı okuyor. Deps.lock dosyası ise yüklediğiniz kütüphanenin git tarafından oluşturulan ve o commit’e ait commit-hash bilgisini (burada bahsetmiştim) tutuyor.

Peki yeni bir kütüphane yüklemek için ne yapacağız? Oldukça basit, deps dosyasına yeni bir kayıt gireceğiz. Deps dosyasına göz atarsanız kayıtlar genel olarak şöyledir:

[FOSUserBundle]
 git=git://github.com/FriendsOfSymfony/FOSUserBundle.git
 target=bundles/FOS/UserBundle
 version=1.2.0

Bu blokta [] içindeki bilgi ek kütüphanemizin ismini gösterir. Eğer target parametresiyle herhangi bir klasör belirmediyseniz varsayılan olarak burada verilen isimde bir klasör yaratılır ve dosyalar bu klasöre indirilir.

git=<git_repo_url> kısmına yazılan adres kısım ek kütüphanenini alınacağı adresi gösterir. Bu adrese git ve http/https ile başlayan kütüphane adreslerini girebilirsiniz. Gerekli olan parametreler aslında bu kadar, fakat diğer parametrelere de göz atalım.

target=<vendor_target> kısmında kütüphane dosyalarının indirileceği klasörü giriyoruz. Buraya girilen klasör <proje_klasörü>/vendor altında yaratılıyor.

Son olarak version= <versiyon> kısmında ise bir kütüphane için belli bir versiyon ve ya branch belirtebiliyoruz.

Deps dosyasında kayıtlı olan ek kütüphaneleri indirmek için proje klasörüne geçtikten yapmamız gereken sadece aşağıdaki komutu çalıştırmak:

php bin/vendors install

Bu komuttan sonra eğer vendor klasörünüzde hiçbir klasör görmezseniz ve ya klasörleriniz hepsi boşsa, git sistemini işletim sisteminize düzgün kuramamış olabilirsiniz. Eğer bazı kütüphaneler yüklenemiyorsa tekrar denediğinizde bunlar da yüklenecektir. İlk kez çalıştırdığınızda bu işlem zaman alabilir, sabırlı olun

Sistem Nasıl İşliyor?

Peki sistem nasıl işliyor, yukarıdaki komutu çalıştırdığımda neler oluyor diyenler için aşağıdaki şemayı hazırladım. Ek kütüphanelerimiz hayırlı olsun

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