Git server ve gitosis.

Bir önceki yazılarımda versiyon kontrol sisteminin ne olduğundan ve git'in bu sistemdeki rolünden bahsedip bi kaç temel git komutunu siz değerli okuyucularıma aktarmıştım.Bu yazımda ise bir linux tabanlı server kurulumunun bir git server'a nasıl evrilebileceğinden ve gitosis server arayüzünden bahsedeceğim.git mimarisine göre bütün projeler bir repository içerisinde bulunmak zorunda.Repository ise içerisinde git config ve log dosyları bulunan bir dizine verilen isimdi.Bir repository başlatmak bir dizin açıp içerisinde git init --bare komutunu yazmak kadar basit.Bu komut yazıldığında dizin içerisinde gerekli dosylar oluşturulur ve bu dosyalar sayesinde repository'de pull push vb. işlemler gerçekleştirilebilir.bir git repository'sini kurmak görüldüğü üzere bu denli basit bir işken , kurulu repository'e erişim yönetimi yapmaksa bir o kadar zor bir iş.Tek kullanıcılı server'da commitleri yapanların kimliklerinin ayrımını yapmak imkansız,çok kullanıcılı bir server'da ise repository erişim ayarlarını ayarlamak zor.Ayrıca yetkilendirme gibi bir kavram yok örneğin istediğiniz kullanıcılara pull,push hakkı verip istemediklerinizden pull,push hakkını alamıyorsunuz.İşte bu ve buna eklenebilecek bir çok eksiklikten ötürü gitosis isimli  proje başlatılmış.Bu proje ssh ile sunucu arasında bir katman oluşturup kullanıcıların sunucuya doğrudan ssh ile bağlanmasını engelleyip kendi izin politikaları çerçevesinde bağlanmalarını sağlıyor.Kimlik tespiti için basit bir sistem kullanıyor.Gitosis kurulumu yapıldığında otamatik olarak bir gitosis-admin dizini oluşturuyor.Bu dizin içerisindeki keys dizinine ssh public ya da private key'lerinizi yerleştiriyor ve eşi olan diğer key ile sistemde kimlik doğrulaması yapabiliyorsunuz.Keylerin isimlerini kullanarak  gitosis.conf dosyasına yazacağınız politikalara göre kullanıcıların hangi repository'lerde hangi haklara sahip olacağını belirleyebiliyorsunuz.Yeni bir repo oluşturulacağı vakit gitosis-admin reposuna erişim hakkına sahip olan kullanıcı gitosis.conf dosyasını düzenleyerek önce politikaları ayarlıyor sonrasında ise repository'i başlatmak isteyen kullanıcı aynı isimde init yaptığı lokal repository'sini server'a push'luyor.Pushladığı anda sunucuda repository oluşturulmuş oluyor.Yani sistem sahibinin her seferinde gidip sunucuda yeni dizin açıp git init --bare komutunu vermesi gerekmiyor.Politika yönetimi standartlara uygun olup gruplara ve bireylere özel yetki atamaları yapılabiliyor.Bunların yanısıra gitweb ile de uyumlu çalışması, sunucuya ait bilgileri görselleştirmek için gitlab vb. ekstra bir arayüz kullanma ihtiyacını ortadan kaldırıyor.Bir sonraki yazımda kurulumdan ve kurulum sırasındaki bazı tuzaklardan bahsedicem.Gitmeden önce projeye ait github linkini buraya ilişitiriyorum.İyi çalışmalar.
https://github.com/tv42/gitosis

git init ve git init --bare arasındaki fark

Bu yazımda genel olarak aralarındaki farkın anlaşılmakta zorlanıldığı iki git komutunu açıklamaya çalışacağım.

git init : Bu komut bir dizini çalışma dizini haline getirip bu dizinde bir git repository'si oluşturur.Bu repository sayesinde yerelde yapmış olduğunuz commit'leri takip edebilir,bir repository server'a bu commitleri push'layabilirsiniz.Komutu verdiğiniz dizin içerisinde .git isimli bir dizin oluşur.Bu dizin içerisinde repository'e ait config ve log dosyaları bulunur.Server'a push yaparken bu dosyalar kullanılır.Diff vb. komutlar bu dosyalar kullanılarak çalıştırılır.

git init --bare : Bu komut aynı diğer komut gibi bir git repository'si oluşturur. İlk farkı repository'nin oluştuğu dizin bir çalışma dizini değildir yani üzerinde değişiklikler yapılmaz(yapılabilir ancak yapılmamalı).Yine diğer komut gibi config dosyalarını oluşturur ancak diğerindeki gibi .git isimli bir dizin oluşturmaz.B

u dosyalar direkt dizin içerisinde oluşturulur.Bu komutla oluşturulan repository'lere pull ve push işlemleri ile değişiklikler yapılır.Doğrudan dizin üzerinde değişiklikler yapılmaz.Bu özelliklerden anlaşılabileceği üzere komutun amacı, sunucuda merkezi git repository'si oluşturmaktır.

Konuyu bir örnekle netleştirmek gerekirse ;

ilk komut gitkraken ya da source tree vb. gibi bir programda lokal git reposu oluşturduğunuzda çalışır.
ikinci komut ise github ya da gitlab vb. gibi bir uzak repository sağlayıcısında bir repository oluşturduğunuzda bu sağlayıcıların server'larında çalışır.

Aşağıdaki görsel ile konunun daha da net anlaşılacağını umuyorum ;

git 101 ve Temel git komutları(GitHub 2)

Bir önceki yazımda açıklamaya çalıştığım VKS mimarilerini uygulayan birden çok yazılım projesi bulunmakta.Bunlardan en çok kullanılanı,Linus Torvalds'ın Linux çekirdeğinin geliştirilmesini daha sistematik hale getirmek amacıyla başlattığı git projesidir.git Dağıtık Versiyon Kontrol Sistemi mimarisini kullanır.Dağıtık VKS mimarisinin temel özelliği,projeye ait verilerin geliştirici bilgisayarında da tutulabiliyor olmasıydı.git kullanabilmek için bir sunucuya ihtiyaç duyulmaz.Yani https://git-scm.com/ linkinden bilgisayara indirilidiğinde lokal kullanıma hazırdır.Linkteki program komut satırından çalışmakta olup görsel arayüzle çalışan alternatif programlarda bulunmaktadır.(GitKraken,SourceTree vb.).

Repository : 
Projenin tutulduğu dizin.Lokalde de Uzaktada olabilir.
Commit : 
Bir projede yapılan değişikliklerin tutulduğu veri tabanı kaydıdır.
Örnek bir commit ;

Yukarıdan aşağıya ;
1-hash-code(Bu commit'i diğerlerinden ayıran kimlik kodu)
2-commit'i yapan kişiye dair kimlik ve tarih bilgisi
3-commit adı
4-önceki commit'le oluşmuş farklar



Lokalde proje oluşturma ve commit yapma örneği;

rfm@hplinux ~ $ git init testproje #proje oluşturuldu
Initialized empty Git repository in /home/rfm/testproje/.git/
rfm@hplinux ~ $ cd testproje/ #projenin bulunduğu dizine gelindi
rfm@hplinux ~/testproje $ micro test.py #projeye yeni bir dosya eklendi
rfm@hplinux ~/testproje $ git add . #değişiklikler önbelleğe alındı
rfm@hplinux ~/testproje $ git commit -m"İlk commit" #değişiklikler commit edildi
[master (root-commit) 63889ad] İlk commit
 1 file changed, 2 insertions(+)
 create mode 100644 test.py

Uzak repository'e bağlanma ve commit yapma örneği;

rfm@hplinux ~ $ git clone https://github.com/rfum/blog #github üzerinde var olan bir repoyu lokale taşıdı
rfm@hplinux ~ $ cd blog/ #projenin bulunduğu dizine gelindi
rfm@hplinux ~/blog $ micro test.py #projeye yeni bir dosya eklendi
rfm@hplinux ~/blog $ git add . #değişiklikler önbelleğe alındı
rfm@hplinux ~/blog $ git commit -m"İlk commit" #değişiklikler commit edildi 
rfm@hplinux ~/blog $ git push #değişiklikler uzak repo'ya gönderildi

Versiyon Kontrol Sistemi Kavramı(GitHub 1)

Bir yazılım projesinde yapılan değişiklikleri sistematik hale getirmeye yarayan sistemlere Versiyon Kontrol Sistemi(VersionControlSystem) denir.3 farklı Versiyon Kontrol Sistemi mimarisi bulunur.

1-Yerel Versiyon Kontrol Sistemi : Proje üzerinde yapılan değişiklikleri içeren veritabanının ve kaynak kodların,değişimi yapan kişinin bilgisayarında tutulduğu sistemlerdir.Varsayılan haliyle ağ üzerinden erişime kapalıdır.Bilgisayarda çıkacak donanımsal bir problemde eğer proje ve veritabanı yedeklenmemişse proje tamamen kaybedilebilir.

2-Merkezi Versiyon Kontrol Sistemi : Proje üzerinde yapılan değişiklikleri içeren veritabanının ve kaynak kodların,merkezi bir bilgisayarda yani bir sunucuda tutulduğu sistemdir.Sunucuda çıkacak donanımsal bir problemde eğer proje ve veritabanı yedeklenmemişse proje tamamen kaybedilebilir.

3-Dağıtık Versiyon Kontrol Sistemi : Proje üzerinde yapılan değişiklikleri içeren veritabanının ve kaynak kodların,merkezi bir bilgisayarda ve geliştirenlerin bilgisayarında saklandığı sistemlerdir.Sunucuda problem çıkması durumunda projeye,geliştirici bilgisayarlarındaki verilerden bilgisayarda problem çıkması durumundaysa sunucudaki verilerden devam edilebilir.

Biraz daha ayrıntılı anlatım için :