Github Pages ve Jekyll ile blog oluşturmak

İlk olarak Jekyll nedir, ondan bahsedelim. Jekyll, statik içeriklerle site oluşturabildiğiniz bir araçtır. Ruby dili ile yazılmıştır. İçerik oluşturduğunuzda, header, sidebar, footer kısımları ( tabi kullandığınız temaya ve layout yapısına bağlı başka yerler de olabilir )  sabit kalır ve içerik kısmı url’e göre değişir.

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.

Git ile birden fazla RSA key tanımlamak

Merhaba,

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 🙂

 

 

 

SVN loglarini cikti almak

SVN de dosyalarımızı commit ederken yazdığımız mesajları topluca bir kerede dışarı alabilmemiz mümkün. Bunun için komut satırında svn komutunu çalışır hale getirip (windows için system path’e eklemelisiniz) daha sonra şu komutu yazmalısınız :
svn log

Örnek Kullanım : 

svn log http://{svnhost}/{repo_name}/ -r 8536:HEAD > D:/logfile.txt

{svnhost} yerine svn reponuzun sunucu IP si veya domainini yazmalısınız. repo_name sizin proje adiniz olmalı. (projeye sağ tıklayıp, subversion kısmından zaten bu ikisini görebilrisiniz)
Yukarıdaki komut ile, 8536 dan son versiyona kadarki tüm logları D:/logfile.txt içine almasını söylemiş olduk.  Bunları kendi ihtiyaçlarınıza göre değiştirebilirsiniz.

Umarım işinize yarar.

Not : Eğer şifreniz SVN de kayıtlı değilse, size bu komuttan sonra kullanıcı adı ve şifre soracaktır.

FTP den yanlislikla .svn veya .git klasorunu da yuklemek

Versiyon kontrol sistemi kullanmanın avantajlarından şu yazımızda bahsetmiştik. Ancak bunu bilinçsiz kullanmanın epey zararı olabiliyor.

Ş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 Versiyon Kontrol Sistemi – Başlangıç

gitBu yazımda en popüler versiyon kontrol sistemlerinden biri olan GIT ile ilgili aldığım notları paylaşacağım.

-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 faridmovsumov@gmail.com

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