13
Oca
Uzun süredir svn kullanan bir ekip olarak git kullanmaya geçince bazı alışkanlıklarımızı değiştirmemiz gerekti. Bundan sonra aramıza katılacak arkadaşlar için de link verebilelim diyerek burada bir kaç noktaya dikkat çekmek istiyorum.

Aslında hangi sürüm takip sistemini kullanırsak kullanalım gönderim (commit) mesajları büyük önem taşıyor. Kullandığımız sistem izin veriyor olsa bile boş mesajla gönderim yapmamak lazım. Yaptığımız işi tanımlayan ama kodu da tekrar etmeyen mesajlar yazmak kolayca alışkanlık haline getirebileceğimiz bir şey. İyi gönderim mesajları gözden geçirme sürecini kolaylaştıracağı gibi sürüm notları hazırlarken de en iyi yardımcınız olacaktır. Yazdığınız kodu ileride sürdürmesi gerekecek biri olacaksa ondan (belki de siz olacaksınız bu kişi) alacağınız dualar yazdığınız gönderim mesajları doğrultusunda olacaktır ;)

Hakkında konuştuğumuz mesajlar temelde iki bölümden oluşuyor:

  • Yapılan işin özeti
Bunun gerçekten bir özet olması lazım. 50 veya daha az karakterden oluşan bir mesaj yazamıyorsanız büyük ihtimalle atomik bir gönderim yapmıyorsunuz demektir. Bu gönderim mesajının değil bir sürüm takip sistemi kullanmanın bir konusu olduğundan üzerinde çok durmak istemiyorum ama 'geri alındığında sadece bir yeniliğin/özelliğin/düzeltmenin dışında hiç bir şeyin değişmeyeceği' gönderimler yapmanın önemini de vurgulamadan geçmeyeyim.

Eğer yazdığınız gönderim mesajı bir hata takip sistemiyle bağlantılıysa yaptığınız değişikliğin hangi hatayı kapattığını, iyileştirdiğini de belirtmeniz gerekir.

Özet kısa olacak diye sadece 'bir hata düzeltildi', 'yapılandırma düzeltildi', 'yeni özellik eklendi' gibi anlamsız ve boş mesajla aynı anlama gelen metinler girilmemeli. Bunu insan okuyacak diye düşünüp ona göre 'parola kontrolü hatası düzeltildi', 'yapılandırmada kullanılmayan secenekler temizlendi', 'kaydetmeden cikma ozelligi eklendi' gibi okuyana birşey ifade eden mesajlar yazılmalı.

Mümkün olduğunca kızgın gönderim mesajları yazmamalı. 'Lanet olası hata, lanet olası bir şekilde çözüldü' gibi ifadeleri alt yazı çevirilerinde bırakmak en iyisidir.
  • Bunun neden yaptığınızın açıklaması
Bu ikisi arasında bir satır boşluk olması ve her satırın en fazla 72 karakter uzunluğunda olması uygun olacaktır. 

Yukarıda bir cümle ile özetlediğiniz değişikliği neden yaptığınızın açıklamasını buraya yazmalısınız. Buraya yazdığınız mesajların birlikte çalıştığınız ekibin geri kalanıyla bir iletişim yöntemi (hem de kalıcı) olduğunu aklınızdan çıkarmamalısınız. Hatta ekibin önemli bir kısmının (eğer imkanı varsa) yazdıklarınızı RSS ile bazılarının sadece eposta ile okuduğunu, yazdığınız koddan önce buraya yazdıklarınızı göreceklerini düşünerek yazmalısınız.

Elbette yapılan işin açıklaması olacak diye yazdığınız kodu okuyan birinin açıkça anlayacağı şeyleri (iki değişkenin değerleri birbirine aktarıldı gibi) yazmamak gerekir.

Biraz özen gösterildiğinde çok daha iyi gönderim mesajları yazmak zor olmayacaktır.
2
Ağu

Bugünlerde bir projemize API yazmak için kolları sıvadık. Öncelikle kaynak kodları paylaşılan Django projelerinin RESTful API’lerini nasıl oluşturduklarını incelemeye koyulduk. Bir kısmı wapi benzeri modüllerle kendilerine özel çözümler üretirken bazıları da küçük django paketleri ile sorunu kısa yoldan çözmüşler.

Biz de hızlıca API’i ortaya çıkarabilmek için ikinci seçeneği uygun gördük ve django-piston kullanmaya karar verdik. Social coding iyi şey güzel şey fakat işin içine birbirinden farklı sürüm kontrol sistemleri girince işler çok karışabiliyor. Projemizi Subversion ile geliştirirken, follow ve invite uygulamalarını Git ile geliştiriyoruz. Şimdi bir de django-piston’ın mercurial’ı çıktı derken kendisini GitHub’a taşıyalım dedik.

Biraz araştırma ile prosedürün şöyle işlediğini öğrendik ve sizlerle paylaşmak istedim.

  1. git clone git://repo.or.cz/fast-export.git
  2. mkdir yeni_git_deposu
  3. cd yeni_git_deposu
  4. git init
  5. fast-export_dizini/hg-fast-export.sh -r mercurial_dizini
  6. git repack -a -d -f
  7. git remote add origin git@github.com:kullaniciadi/depoadi.git
  8. git push origin master

8 adımı da tamamladıktan sonra kendinize güzel bir espresso alıp kodlamaya devam edebilirsiniz ;)

git remote add origin git@github.com:ahmet/test.git
18
Tem

Adım adım neler yaptık anlatacağım demiştim, blog yazma konusunda istikrarsız olduğumu bildiğinizden inanmamışsınızdır tahminen. Yarı dönem değerlendirme formuna birkaç paragraf yazarken bile araya türlü türlü aktiviteler sokarak “yazma” işinden kaytaran ben, artık “macroblogger” olduğuma göre oturum adam gibi bir değerlendirme yazısı yazmak zorunda oluyorum değil mi? Evet, buyrun:

GSoC koordinatörü (yine) Renan hızlı, temiz ve sessiz bir iş çıkararak 3. kez yaz stajına kabul edilmemizi sağladı. Biz onu kod yazıyor ya da birileriyle yazışıyor sanıyorduk, meğer teklif metni yazıyormuş gizli gizli. Yaz döneminin büyük bir kısmında ofis dışında olmayı planlayan (ilk aylarda iş, sonraki aylarda tatil için) bir geliştirici olarak bu sene de GSoC danışmanlığı yapmayacağını düşünen ve yanılan bendeniz, 2. kez danışman olarak buldum kendimi. Danışman olduğum Jain Basil‘in ilgisi ve proje gözden geçirmenin en az kod yazmak kadar eğlenceli gelmeye başlaması, 2 aya yakın zamanı keyifli geçirmemi sağladı.

Proje, ev dizinindeki (şimdilik sadece KDE) ayar dosyalarındaki değişiklikleri takip etme, değişiklikleri yedekleyebilme, paylaşabilme ve geri alabilme için gerekli altyapının hazırlanmasını ve arayüzlerin yazılmasını kapsıyor. Detaylar için Jain Basil’in günlüğüne göz atabilirsiniz. “Bir ayar değiştirdim ama neredeydi unuttum, nereden geri alıyorduk bunu?” diyenler için kurtarıcı olacağından eminim.

Jain başvuruda bulunmadan, kodlamaya başlamadan önce yapılması gereken herşeyi yapmış, bunu başvuru mektubunda göstermiş ve başvuruları değerlendiren geliştiricilerin “E sadece kod yazmak kalmış, seçelim bu arkadaşı” demesini sağlamıştı. Aktif geliştirme süreci boyunca Jain iyi bir geliştirici olduğunu gösterdi, takvime uydu ve ilk dönemde geçer notu aldı.

SVN kayıtlarını ve Jain’in İngilizce günlüğünü takip etmeyenler için yaptıkları hakkında bir özet şöyle:

  • ~/.kde dizinini kullarak bir yerel GIT deposu oluşturan bir servis yazdı.
  • Dizindeki her değişikliği KDirWatch ile takip etme ve değişiklikleri GIT deposuna gönderme desteği ekledi.
  • Değişiklikleri görme ve geri almak için gerekli kitaplık metodlarını yazdı.
  • 2. dönem geliştireceği arayüz için örnek bir tasarımı depoya gönderdi.

SVN kayıtlarına, kodlara, geliştirici günlüğüne ya da yukarıdaki özete bakarak “ne var bunda, ben de yaparım bunu” diyenlerdenseniz, sizi bir sonraki sene yapılacak olan yaz stajına bekleriz. Proje geliştirmek zor değil. Enerjiniz, hevesiniz, zamanınız ve bu işi yapmak için tutkunuz varsa bu ekipte size de yer var. Selamlar.

27
Haz

Güzel bir başlık olmadı. Git’te kod değişikliklerini depoya göndermek için “git push” komutunu kullanırız. Bu yazıda, her “git push” komutundan sonra belli bir e-posta adresine otomatik olarak bu “push” ile ilgili bilgi gitmesini nasıl sağlayacağınızı yazacağım.

SVN kullananlar için ise konuyu şöyle açıklayabilirim; svn’de her commit’ten sonra belli bir e-posta adresine commit hakkında bilgi gönderilebiliyor. [...]

2
May

Eğer Git hiç kullanmadıysanız, mutlaka önce araştırmanız, denemeniz, fikir sahibi olmanız gerekiyor. Aksi halde aşağıdaki yazdıklarımın size bir şey kazandıracağı konusunda endişeliyim =).

Git, Linus’un, Linux kernelinin geliştirilmesinde kullanmak amacıyla yazdığı bir hızlı sürüm kontrol sistemidir veya sürüm yöneticisidir. Piyasada birçok sürüm yöneticisi bulunmaktadır. Örneğin Pardus geliştiricileri paket yapımında Subversion kullanırlar, Archlinux’ta SVN CVS karışık kullanılmaktadır[1]. Her sürüm kontrol sisteminin birbirlerine göre üstünlükleri ve dezavantajları sözkonusudur. Eğer “Neden Git kullanmalıyım?” diye kendinize soruyorsanız, buna benim vereceğim pek tatmin edici bir cevabım yok; ama şöyle bir bağlantı var, gayet hoş:
http://whygitisbetterthanx.com/

Yalnız bu bağlantıda son madde olarak “Easy to Learn” yazmışlar, o konuda biraz tereddüt ettim, hele ki bayadır SVN kullanıyorsanız, kafanızın haylice karışması mümkün. Çevrimdışı depoda çalışma olayını ilk başta fena halde garipsemiştim. Ama Git’i hızlıca öğrenmek için mutlaka bir GitHub[2] hesabı açın, kurcalayın, alıştırmalar yapın. Şimdi gelelim Gitosis’e..

Gitosis, Git sunucusu kurmanın en güzel yoludur. Bir depo oluşturuyorsunuz, bu depoda görev alacak kullanıcıları (ssh genel anahtarlarını) ekliyorsunuz ve böylece git clone ile depoyu indirip çalışma arkadaşlarınızla ortaklaşa bir yazılım geliştirme fırsatı elde etmiş oluyorsunuz. Ama..

Ama gitosis, sadece izinleri verilmiş kullanıcılar tarafından deponun klonlanmasını sağlayabiliyor. Başka türlü sizden sunucudaki gitosis kullanıcısının şifresini soruyor. Belki gitosis ile oluşturulan depoda sunucu tarafında git daemon export ok komutunu çalıştırmak bunun için işe yarayabilir, henüz deneme fırsatım olmadı. Şimdi gelelim gitosis’in nasıl kurulacağına..

Öncelikle gitosis bağımlılıkları olarak dağıtımınızın paket yöneticisinden git, python ve setuptools’u kurmalısınız. Ayrıca sunucuyla bağlantıyı sağlayabilmek ve gitosis erişim hakkına sahip olabilmek için de SSH kurmanız ve openssh servisini çalıştırmanız gerekir. Bunları kurduktan sonra, gitosis deposundan gitosis’i git’le indiriniz (Nasıl cümle ama?):

$ git clone git://eagain.net/gitosis.git

gitosis dizinine girin. O dizinde root olarak şu komutu verin:

# python setup.py install

Kurulum bu kadar. Ama gitosis için kullanıcı adı ve grup eklemeniz gerekiyor. Bu kısım Pardus kullanıcılarının canını biraz sıkabilir; çünkü her baselayout güncellemesinde bu adımı tekrar tekrar yapacaklar[3]. Sebebi, kullanıcı ve grup bilgilerini tutan dosya baselayout’tan çıkıyor ve siz güncelleme yaptıkça o dosyanın üzerine, yeni baselayout paketinden çıkan dosya yazılacak. Kullanıcı ve grup oluşturma işlemi için root olarak şöyle yapıyorsunuz (Eğer dağıtımınızda /srv dizini bulunmuyorsa /var/spool/gitosis olarak deneyin.):

# mkdir /srv/gitosis
# groupadd -r gitosis &> /dev/null
# useradd -r -m -k /dev/null -g gitosis -d /srv/gitosis -s /bin/sh gitosis &> /dev/null
# chown gitosis:gitosis /srv/gitosis

Kullanıcı ve grubu oluşturduk, gerekli izinleri ve sahiplikleri ayarladık. Bundan sonraki adımımız gitosis’le depo kurulumuyla ilgili olacak. Burada bazı şeyleri açıklığa kavuşturmam gerek. Gitosis’in kurulu olduğu sunucu, bu sunucudaki zorunlu gitosis kullanıcı hesabı, gitosis kullanıcı hesabı dışında herhangi bir gitosis depo yöneticisi olan herhangi bir kullanıcı hesabı ve gitosis depolarına erişimi olan kullanıcılar; işte bunların hepsini birbirlerinden bağımsız olarak ele almanız gerekli. Yani tutup da ben gitosis kullanıcısı açmışım, hem gitosis kullanıcısıyla depo yöneticisi, hem kullanıcı, hem de depoları sunucudan yönetirim diye bir mantık sakın yürütmeyin. Hem güvenli olmayacaktır, hem de muhtemelen bundan sonra yazacaklarımda başarısız olacaksınız. Bu sebeple, gitosis kullanıcısını kullanmayın, hatta parolası bile olmasın, o kullanıcının.

Depo oluşturmaya başlamadan önce, bir depo yöneticisi belirleyin. Benim tavsiyem, sıklıkla kullandığınız bilgisayardaki kullanıcı hesabınız depo yöneticisi olsun. Sunucuda ayrı bir kullanıcı hesabı açmanıza gerek yok; ama zaten sunucuda da size özel bir kullanıcı hesabı varsa, onu da yönetici yapabilirsiniz. Nasıl olsa birden fazla makine veya kullanıcı hesabına da depo yöneticiliği yetkisini sonradan verebiliyorsunuz. Depo yöneticisi olarak seçtiğiniz kullanıcının ssh genel anahtarını sunucuya, “kullanıcı adı @ yerel adres . pub” adıyla gönderin. Örneğin benim bilgisayarımın adı archer, kullanıcı adım gkmngrgn, dolayısıyla ssh genel anahtar adını da gkmngrgn@archer.pub olarak kaydediyorum. Ssh genel anahtar dosyasını herhangi bir metin düzenleyicisiyle açıp satırın sonuna bakarak da nasıl kaydetmeniz gerektiğini öğrenebilirsiniz.

Eğer ssh genel anahtarı oluşturmadıysanız, depo yöneticisi olacak kullanıcı hesabıyla:

$ ssh-keygen -t dsa

komutuyla oluşturabilirsiniz. Soruları geçiş (enter) tuşuna basarak esgeçebilirsiniz. Bu komuttan sonra ~/.ssh/ içinde, id_dsa.pub adıyla bir genel anahtar oluşacaktır. Bu anahtarın ismini biraz önce anlattığım biçimde değiştirin ve sunucuya gönderin. Sonra da aşağıdaki komutla gitosis depolarını oluşturun:

$ sudo -H -u gitosis gitosis-init < /depo/yoneticisi/olacak/kullanicinin/genel/ssh/anahtari.pub
$ sudo chmod 755 /home/git/repositories/gitosis-admin.git/hooks/post-update

Evet, gitosis kullanıcısının ev dizininde gitosis ve repositories adında iki alt dizin oluştu ve post-update için gerekli izinleri verdik. Şimdi depo yöneticisi olan kullanıcı hesabınızla gitosis-admin deposunu klonlayın:

$ git clone gitosis@:gitosis-admin.git

Bu işlemin ardından, komutu verdiğiniz dizinde gitosis-admin isminde bir dizin göreceksiniz. Onun içinde de bir adet gitosis.conf, bir adet de keydir dizini göreceksiniz. Yetkiler ve depolarla ilgili yapılandırmanın yapıldığı gitosis.conf dosyasının bir örneğini gösterelim:

[gitosis]

[group developers]
members = gkmngrgn@gacer ggorgen@ggorgen-pardus
writable = example

[group admins]
members = ggorgen@ggorgen-pardus gkmngrgn@gacer

[group gitosis-admin]
writable = gitosis-admin
members = @admins

Tek tek açıklayalım; gitosis-admin grubunda yer alan ayarlar, depo yöneticilerinin belirlenmesi ve depo ismiyle ilgili ayarlar. @admins, bir nevi admins değişkeni olarak düşünülebilir ve admins grubunda belirtilen üyeleri döndürüyor. developers grubunda yer alanlar ise, example isimli bir dizinin oluşturulması ve bu example dizinine kimlerin erişebildikleri ile ilgili ayarlar oluyor. Bir depo oluşturmak için gerekli örnek developers dizinidir. Şimdi, bu grupta depoya adını verdiğimiz example ismiyle yerel bir git deposu oluşturalım:

$ mkdir example
$ cd example
$ git init
$ echo "First file." > README # Bunu yazmasanız da olur, örnek bir dosya sadece.
$ git add README
$ git commit -m "First commit on example repository."
$ git push origin master

Son komutla yerel depomuzu gitosis sunucusuna göndermiş olduk. Bundan sonra eşleştirmeler dosyalarınızı bu example dizininde tutabilir, değişiklikleri sunucuya gönderebilir ve benzer şekilde farklı git depoları da oluşturabilirsiniz.

Peki, buraya kadar tamam. Ne güzel git daemon export ok demeden sunucuya erişebiliyoruz, değişiklikleri yapabiliyoruz vesaire. E ama hem siz başka bir makineden ve hatta aynı makinede başka bir kullanıcıdan depoyu klonlayamıyorsunuz, hem de dolayısıyla ekip arkadaşlarınızla ortaklaşa bir uygulama geliştiremiyorsunuz, bunda bir terslik var değil mi?

Tabi ki bir terslik var. example'dan önce indirmiş olduğunuz gitosis-admin dizinine girin. İçindeki keydir dizinine, depoya erişim izni vermek istediğiniz kullanıcıların, bilgisayarların ssh genel anahtarlarını atın. Ama başta ssh oluştururken isimlere gösterdiğiniz titizliği bu anahtarlara da gösterin. Hede@hodo ise Hede@hodo.pub gibi. Daha sonra gitosis.conf dosyasında, example deposu veya herhangi bir deponun üyelerine (members) Hede@hodo (veya her neyse || kimse) olarak ekleyin. Böylece bir depoda ekip çalışması yapma işlemi için başka ek bir emek sarfetmek gerekmeyecek.

Yalnız ssh erişimi olmayan kullanıcıların da sadece depoyu indirebilmelerine izin vermek için, git daemon export ok komutunu araştırmanız, öğrenmeniz gerekecek. Son olarak, şu bağlantıları da incelemenizi tavsiye ediyorum:

http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
http://forum.webfaction.com/viewtopic.php?id=2321
http://wiki.archlinux.org/index.php/Gitosis_Kurulumu

P.S. Gitosis denemelerimin hepsini Pardus 2009'da yaptım, Pardus'ta gayet güzel çalışıyor, gitosis ev dizini olarak /var/spool/gitosis ayarlayın..

[1]: Bu cümle hakkında yorumlarda Alper'in ek bilgisi var, yorumları okuyunuz.
[2]: http://github.com/
[3]: Bu cümle hakkında Türker'in eleştirisi var, yorumları okuyunuz.