GitHub Pages, projelerinize vs. websitesi oluşturabildiğiniz GitHub reponuzda host edilen, dolayısıyla terminalden git ile kontrol edebileceğiniz bir yapıdır.

Peki Jekyll’nin GitHub ile olayı nedir? Oluşturduğunuz bir GitHub Page içerisine, Jekyll push ettiğiniz takdirde, bir adet blogunuz olmakta. İşin özeti tamamen bu aslında.

Hızlıca bu işlemleri yapmak istiyorsanız, şu linke tıklamanız yeterli. Adım adım ne yapacağınız yazıyor, ancak ben kısaca bahsedeyim.

İlk olarak github içerisinde {{username}}.github.com isminde bir repo oluşturuyorsunuz. Ardından bilgisayarınızda Jekyll’i clonelayıp, remote set-url ile oluşturduğunuz repoya gönderiyorsunuz. Ve {{username}}.github.io adresiniz yaklaşık bir 10 dakika içerisinde açılmış oluyor.

Linkini verdiğim sitede layoutları bootstrap ile yapılmış bir Jekyll var. Eğer isterseniz tabi ki kendiniz de temasını şeklini felan düzenleyebilirsiniz. Ayrıca eğer isterseniz mevcut bir Jekyll’den clonelayıp kendiniz bir tane oluşturabilirsiniz. Burada bir liste var örneğin : https://github.com/jekyll/jekyll/wiki/Sites

Postların tamamı, _posts klasörünün altında bulunuyor. Eğer terminalden rake post title=”deneme” derseniz, _posts klasörünün altında, current-date-deneme.md isminde bir dosya oluşuyor. Bu dosyayı herhangi bir editör ile düzenlediğinizde bir adet post yazmış oluyorsunuz. Ancak bu şekilde yapmak zorunda değilsiniz, _posts altında herhangi bir dosya oluşturup onu {{username}}.github.io/{{dosya_adi}} şeklinde veya bir klasör oluşturup ardından onun altında dosya oluşturup {{username}}.github.io/{{klasör}}/{{dosya_adi}} şeklinde çalıştırabilirsiniz.

Jekyll’i localde çalıştırabilmek için bilgisayarınızda ayrıca ruby kurulu olması gerekiyor. Onu da buradaki yazımda anlatmıştım, belki yardımcı olabilir.

Ayrıca localde çalışırken başıma gelen bir olay; _config.yml dosyası jekyll serve dediğinizde load oluyor. Üzerinde değişiklik yaptığınızda tekrar jekyll serve  demeniz gerekiyor.

Localde çalışırken başıma gelen bir başka hata ise şu şekildeydi : runner.rb:365:in `require_program’: program version required (Commander::Runner::CommandError)

Çözümü ise : sudo gem install json

Jekyll’nin asıl amacı, yazılımcıların kod yazar gibi blog içeriği oluşturmalarıymış. Ufak bir araştırma yaptığımda kullanan sayısının bir hayli çok olduğunu da gördüm.

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!

Unfuddle.com nedir?

İşte yukarıda bahsettiğim gibi kodunuzu paylaşmak istemiyorsanız, www.unfuddle.com u tercih edebilirsiniz. Unfuddle kayıt sayfasında ücretli planların hemen altında ücretiz ve gizli planını seçebiliyor, 2 kullanıcı, 1 proje için ebedi ücretiz kullanabiliyorsunuz. Üstelik ücretsiz planda bile ssl hizmeti aktif. Panenize giriş yaptıktan sonra, orada ticket’lar açıp, proje yönetim gereçlerini kullanabiliyorsunuz. SVN hizmetinizi

İhtiyacı olanlara tavsiye ederim.

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.