Git
Chapters ▾ 2nd Edition

4.1 Bir Sunucuda Git Kurma - İletişim Kuralları (Protocols)

Şu aşamada, Git’i kullanacağınız günlük görevlerin çoğunu yapabilecek durumda olmalısınız. Ancak, Git’te işbirliği yapmak için bir uzak Git reposuna ihtiyacınız olacaktır. Teknik olarak değişiklikleri bireylerin depolarına itip çekebilirsiniz, ancak dikkatli olmazsanız ne üzerinde çalıştıklarını kolayca karıştırabilirsiniz. Ayrıca, bilgisayarınız çevrimdışı olsa dahi çalışma arkadaşlarınızın repoya erişebilmesini istersiniz - daha güvenilir bir ortak repoya sahip olmak genellikle faydalıdır. Bu nedenle, biriyle işbirliği yapmanın en tercih edilen yolu, her ikinizin de erişimi olan ara bir repo kurmak ve bu repoya itip çekmektir.

Bir Git sunucusu çalıştırmak oldukça basittir. İlk olarak, sunucunuzun hangi protokolleri destekleyeceğini seçersiniz. Bu bölümün ilk kısmı, mevcut protokolleri ve her birinin artılarını ve eksilerini ele alacaktır. Sonraki bölümler, bu protokolleri kullanarak tipik bazı kurulumları ve sunucunuzu bu protokollerle nasıl çalıştıracağınızı açıklayacaktır. Son olarak, kendi sunucunuzu kurup bakımını yapmakla uğraşmak istemiyorsanız ve kodunuzu başka birinin sunucusunda barındırmakla ilgili bir sorununuz yoksa, birkaç barındırma (hosting) seçeneğinden bahsedeceğiz.

Kendi sunucunuzu çalıştırmakla ilgilenmiyorsanız, barındırılan bir hesap kurmak için bu ünitenin son bölümüne geçebilir ve ardından da bir sonraki üniteye geçebilirsiniz. O kısımda dağıtık bir kaynak kontrol ortamında çalışmanın çeşitli yönlerini tartışacağız.

Bir uzak repo genellikle bir yalın repo olarak adlandırılan ve çalışma dizini olmayan, basit bir Git reposudur. Bir repo sadece işbirliği noktası olarak kullanıldığından, sadece Git verileri vardır ve diske çıkarılmış bir poz oluşturma nedeni yoktur; . En basit ifadesiyle, yalın bir depo projenizin .git dizininden başka bir şey değildir.

İletişim Kuralları (Protocols)

Git, veri aktarımı için dört farklı protokol kullanabilir: Yerel, HTTP, SSH (Güvenli Kabuk) ve Git. İşte bunların ne oldukları ve hangi temel durumlarda kullanmak isteyebileceğiniz (veya istemeyebileceğiniz) konusunu tartışacağız.

Yerel (local) Protokol

En temel olanı uzak reponun, aynı ana bilgisayardaki başka bir dizinde yer aldığı Yerel protokoldür. Bu genellikle takımınızdaki herkesin NFS mount gibi paylaşılan bir dosya sistemine erişiminin olduğu veya daha az rastlanan herkesin aynı bilgisayara giriş yaptığı durumda kullanılır. Tüm kod repo örneklerinin aynı bilgisayarda bulunması, bir felaket durumundaki kayıpları daha da olası hale getireceği için, ikinci durum pek de ideal değildir.

Eğer paylaşılan bir dosya sistemine bağlanmışsanız, o zaman yerel dosya tabanlı bir repodan kopya alabilir, bu repoya katkı itebilir ve çekebilirsiniz. Böyle bir repoyu kopyalamak veya mevcut bir projeye uzak repo olarak eklemek için, repo yolunuzu URL olarak kullanın. Örneğin, bir yerel repoyu kopyalamak için şu şekilde bir komut çalıştırabilirsiniz:

$ git clone /srv/git/project.git

Veya şunun gibi:

$ git clone file:///srv/git/project.git

URL’nin başına açıkça file:// belirtirseniz, Git biraz farklı çalışır. Eğer sadece dizini belirtirseniz, Git ihtiyaç duyduğu dosyaları ya doğrudan kopyalamaya ya da hardlink kullanmaya çalışır. Eğer file:// şeklinde belirtirseniz, Git genellikle ağ üzerinde veri transferi için kullandığı işlemleri başlatır ki bu da genellikle çok daha verimsizdir. file:// öneki belirtmenin ana nedeni, genellikle başka bir VCS’den içe aktarım sonrasında, repodan gereksiz referansların veya nesnelerin çıkarıldığı temiz bir kopya istemenizdir (bakım görevleri için: Dahili Git Ögeleri). Genellikle daha hızlı olduğu için burada normal dizini kullanacağız.

Mevcut bir Git projesine yerel bir repo eklemek için şöyle bir komut çalıştırabilirsiniz:

$ git remote add local_proj /srv/git/project.git

Ardından, bu uzak repoya, ağ üzerinden işlem yapıyormuş gibi, yeni uzak adınız olan local_proj üzerinden itme ve çekme işlemleri yapabilirsiniz.

Artıları

Dosya tabanlı repoların avantajları, basit olmaları ve mevcut dosya ve ağ erişimi izinlerini kullanmalarıdır. Eğer takımınızın tamamının erişebildiği paylaşılan bir dosya sistemine sahipseniz, bir repo kurmak çok kolaydır. Bir yalın repo kopyasını herkesin erişim sağlayabildiği bir paylaşıma yapıştırır ve okuma/yazma izinlerini diğer paylaşılan dizinler gibi ayarlarsınız. Bu amaçla bir yalın repo kopyasını nasıl dışa aktaracağınızı Bir Sunucuda Git Kurma bölümünde ele alacağız.

Bu ayrıca başka birinin çalışma reposundan hızlı bir şekilde çalışma almak için de güzel bir seçenektir. Eğer siz ve bir iş arkadaşınız aynı projede çalışıyorsanız ve sizin bir şeyi kontrol etmenizi istiyorlarsa, git pull /home/john/project gibi bir komut çalıştırmak; onların projeyi bir uzak sunucuya itip, ardından sizin de bunu ordan çekmenizden genellikle daha kolaydır.

Eksileri

Bu yöntemin dezavantajları, paylaşılan erişimin kurulumunun ve çoklu konumlardan ulaşılabilirliğinin genellikle temel ağ erişimine göre daha zor olmasıdır. Evden çalışırken birşeyleri itmek istiyorsanız, uzak diski bağlamanız gerekebilir ve bu da ağ erişimine göre daha zorlayıcı ve yavaş olabilir.

Eğer bir çeşit paylaşılan bağlantı noktası kullanıyorsanız bu illa ki en hızlı seçenek olmak zorunda değildir. Yerel bir repo sadece, eğer verilere hızlı erişiminiz varsa hızlıdır. Git, her sistemdeki yerel disklerden çalışmasına izin verdiği için, NFS üzerindeki bir repo genellikle aynı sunucuda yer alan SSH üzerindeki bir repodan daha yavaş olabilir.

Son olarak, bu protokol repoyu kaza eseri oluşan hasara karşı korumaz. Her kullanıcının "uzak" dizinine tam kabuk (shell) erişimi vardır ve onların içerideki Git dosyalarını değiştirmesini, kaldırmasını veya repoyu bozmasını engelleyen hiçbir şey yoktur.

HTTP Protokolleri

Git iki farklı modda HTTP üzerinden iletişim kurabilir. Git 1.6.6 öncesi sürümlerde genellikle salt okunur olan çok basit bir yol vardı. 1.6.6 sürümünde, Git’in SSH üzerinden yaptığına benzer bir şekilde, veri transferini zekice müzakere edebildiği yeni bir protokol tanıtıldı. Son birkaç yılda, bu yeni HTTP protokolü kullanıcısı için daha basit ve iletişim şekli yönüyle daha akıllı olduğu için oldukça popüler hale gelmiştir. Yeni sürüm genellikle Akıllı (smart) HTTP protokolü olarak adlandırılırken, eski yöntem Aptal (dumb) HTTP olarak adlandırılır. İlk olarak daha yeni olan Akıllı HTTP protokolünü ele alacağız.

Akıllı HTTP

Akıllı HTTP; SSH veya Git protokollerine oldukça benzer bir şekilde çalışır, ancak standart HTTPS bağlantı noktaları üzerinden çalışır ve çeşitli HTTP kimlik doğrulama mekanizmalarını kullanabilir. Bu da kullanıcı açısından genellikle SSH gibi şeylere göre daha kolay olduğu anlamına gelir, çünkü SSH anahtarları kurmaktansa kullanıcı adı/parola kimlik doğrulaması gibi şeyleri kullanılabilir .

Bu muhtemelen şu anda Git’i kullanmanın en popüler yolu olmuştur. Çünkü git:// protokolü gibi anonim hizmet verecek şekilde kurulabilir ve SSH protokolü gibi kimlik doğrulama ve şifreleme ile de gönderilebilir. Bu işlemler için farklı URL’ler kurmak zorunda kalmak yerine, artık her ikisi için tek bir URL kullanabilirsiniz. Eğer repo kimlik doğrulama gerektiriyorsa (ki normalde gerektirmelidir), sunucu bir kullanıcı adı ve parola sormak üzere bir istekte bulunabilir. Okuma erişimi için de aynı durum geçerlidir.

Aslında, GitHub gibi hizmetler için, repoyu çevrimiçi görüntülemek için kullandığınız URL (örneğin, https://github.com/schacon/simplegit) kopyalamak ve erişiminiz varsa itmek için kullanabileceğiniz aynı URL’dir.

Aptal HTTP

Eğer sunucu Git HTTP akıllı hizmeti ile yanıt vermezse, Git istemcisi daha basit Aptal HTTP protokolüne geri dönmeye çalışacaktır. Aptal protokol yalın Git reposundan tıpkı ağ sunucusundan normal dosyalar gibi sunulmasını bekler. Aptal HTTP’nin güzelliği kurulumunun basitliğidir. Temelde yapmanız gereken, yalın bir Git reposunu HTTP belge kökünüzün altına koymak ve belirli bir post-update kancası (hook) kurmaktır. İşte hepsi bu (Bkz: Git Kancaları (Hooks)). Bu noktada, ağ sunucusuna yerleştirdiğiniz repoya erişebilen herkes, aynı zamanda repoyu da kopyalayabilir. Repoyu HTTP üzerinden okuma erişimine izin vermek için şunu yapabilirsiniz:

$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update

Hepsi bu. Git’in varsayılan olarak gelen post-update kancası, HTTP çekme ve kopyalamanın düzgün çalışmasını sağlamak için uygun komutu (git update-server-info) çalıştırır. Bu komut, bu repoya itme yaptığınızda (belki SSH üzerinden), ardından diğer insanlar şu şekilde kopyalayabilir:

$ git clone https://example.com/gitproject.git

Bu özel durumda, Apache kurulumları için yaygın olan /var/www/htdocs yolu kullanılmıştır, ancak herhangi bir durağan (static) ağ sunucusunu kullanabilirsiniz (sadece yalın repoyu dizinine koyun). Git verileri temel durağan dosyalar olarak sunulur (tam olarak nasıl sunulduğu hakkında ayrıntılı bilgi için Dahili Git Ögeleri bölümüne bakın).

Genellikle ya okuma/yazma yeteneğine sahip Akıllı HTTP sunucusunu çalıştırmayı seçersiniz ya da dosyaları aptal şekilde sadece salt okunabilir olarak erişilebilir yaparsınız. İki hizmeti karışık şekilde çalıştırmak nadirdir.

Artılar

Akıllı HTTP protokolünün avantajlarına odaklanacağız.

Tüm erişim türleri için tek bir URL’e sahip olmanın ve sunucunun sadece kimlik doğrulamasına ihtiyaç duyulduğunda istekte bulunmasının basitliği, son kullanıcılar için işleri çok kolay hale getirir. Kullanıcı adı ve parola ile kimlik doğrulayabilme, SSH’ye kıyasla büyük bir avantajdır. Böylece kullanıcılar sunucuyla etkileşimde bulunabilmek için, önce yerelde SSH anahtarı oluşturup genel anahtarlarını sunucuya yüklemek zorunda kalmazlar. Daha az deneyime sahip kullanıcılar veya SSH’nin daha az yaygın olduğu sistemlerde, bu kullanılabilirlik açısından büyük bir avantajdır. Bu aynı zamanda, SSH’ye benzer şekilde, çok hızlı ve verimli bir protokoldür.

Ayrıca repolarınızı sadece HTTPS üzerinden salt okunabilir şekilde sunabilirsiniz. Bu da içerik aktarımını şifreleyebileceğiniz veya istemcilerin belirli imzalı SSL sertifikalarını kullanmasını sağlayabileceğiniz anlamına gelir.

Bir başka güzel özellik de, HTTPS o kadar yaygın kullanılan bir protokoldür ki kurumsal güvenlik duvarları genellikle bu portlardan trafiğe izin verilecek şekilde kurulmuştur.

Eksiler

Bazı sunucularda Git’i HTTPS üzerinden kurmak, SSH’ye kıyasla biraz daha karmaşık olabilir. Bunun dışında, diğer protokollerin Git içeriğini sunma konusunda Akıllı HTTP’ye karşı çok az avantajı vardır.

Eğer kimlik doğrulamalı itme için HTTP kullanıyorsanız, kimlik bilgilerinizi sağlamak SSH üzerinden anahtar kullanmaktan bazen daha karmaşık olabilir. Yine de bunu mümkün mertebe sorunsuz hale getirmek için kullanabileceğiniz, macOS için Keychain erişimi veya Windows için Credential Manager dahil, birkaç kimlik bilgisi önbelleği aracı bulunmaktadır. Sistem üzerinde güvenli HTTP şifre önbelleğinin nasıl kurulacağını öğrenmek için Kimlik Bilgisi Depolama bölümüne göz atın.

SSH Protokolü

SSH, Git için kendinden ev sahipliği (self-hosting) yapılırken, yaygın şekilde kullanılan bir iletişim prokotolüdür. Bu, çoğu zaman zaten sunuculara SSH erişiminin kurulu olması veya kurulu değilse, kurmanın kolaylığı nedeniyle geçerlidir. SSH ayrıca kimliği doğrulanmış bir ağ protokolüdür ve yaygın olduğu için de genellikle kurulumu ve kullanımı kolaydır.

SSH üzerinden bir Git reposunu kopyalamak için şu şekilde bir ssh:// URL’si belirtebilirsiniz:

$ git clone ssh://[user@]server/project.git

Veya SSH protokolü için "scp" benzeri daha kısa bir sözdizimini kullanabilirsiniz:

$ git clone [user@]server:project.git

Yukarıdaki her iki durumda da isteğe bağlı kullanıcı adını belirtmezseniz, Git şu anda oturum açtığınız kullanıcıyı varsayılan olarak kabul eder.

Artılar

SSH kullanmanın birçok avantajı vardır. İlk olarak, SSH kurulumu nispeten kolaydır (SSH daemonları yaygındır, birçok ağ yöneticisi bunda deneyime sahiptir, birçok işletim sistemi dağıtımında kuruludur veya bunları yönetmek için gerekli araçlara sahiptir). Ayrıca, SSH üzerinden erişim güvenlidir (tüm veri aktarımı şifrelenir ve kimlik doğrulanır). Son olarak SSH, aynı HTTPS, Git ve yerel protokoller gibi, veriyi mümkün olduğunca sıkıştırarak aktardığı için verimlidir.

Eksiler

SSH’nin olumsuz yönü, Git reposuna anonim erişimi desteklememesidir. Eğer SSH kullanıyorsanız, insanlar (salt okunur dosyalar için dahi) makinenize SSH erişimine sahip olmak zorundadır. Bu da SSH’nin insanların repoyu sadece incelemek amacıyla kopyalamak isteyebileceği açık kaynak projeler için uygun olmadığı anlamına gelir. Eğer bunu sadece kurumsal ağınız içinde kullanıyorsanız, SSH muhtemelen uğraşmanız gereken tek protokol olabilir. Eğer projelerinize anonim salt-okunur erişimine izin vermek ve aynı zamanda SSH kullanmak istiyorsanız; projelerinizi itmek için kendinize bir SSH kurmanız gerekecek ,ancak başkalarının sizden çekebilmesi için başka bir şey kullanmanız gerekecektir.

Git Protokolü

Son olarak, elimizde bir de Git protokolü var. Bu, Git ile birlikte gelen özel bir daemon’dır. Kendine adanmış bir portu (9418) dinleyerek SSH protokolüne benzer bir hizmet sunar, ancak kesinlikle hiçbir kimlik doğrulama yoktur. Bir reponun Git protokolü üzerinden sunulabilmesi için bir git-daemon-export-ok dosyası oluşturmanız gerekmektedir (daemon, bu dosya olmadan bir repoyu sunamaz), ancak bunun dışında herhangi bir güvenlik önlemi yoktur. Git reposu ya herkes tarafından kopyalanabilirdir ya da kimse tarafından. Bunun anlamı, bu protokol üzerinden genel olarak itmenin olmadığıdır. İtme erişimini etkinleştirebilirsiniz, ancak kimlik doğrulama eksikliği nedeniyle projenizin URL’sini bulan herkes bu projeye itme yapabilir. Bunun oldukça nadir olduğunu söylemeye gerek yok tabi.

Artılar

Git protokolü genellikle mevcut olan en hızlı ağ aktarım protokolüdür. Eğer geniş bir trafiği olan genel bir proje için veya okuma erişimine kullanıcı kimliği doğrulaması gerektirmeyen çok büyük bir proje için hizmet veriyorsanız, muhtemelen projenizi sunmak için bir Git daemonu kurmak istersiniz. Bu, şifreleme ve kimlik doğrulama maliyeti olmadan, SSH protokolü ile aynı veri aktarım mekanizmasını kullanmanıza olanak tanır.

Eksiler

Git protokolünün dezavantajı kimlik doğrulama eksikliğidir. Projenize erişim için Git protokolünün tek seçenek olması genellikle istenmez. Genellikle, sadece yazma (itme) izni olan birkaç geliştiriciyi SSH veya HTTPS erişimi ile eşleştirir ve diğer herkesin sadece salt okunur erişimi için git:// kullanmasını sağlarsınız. Ayrıca, muhtemelen kurulumu en zor protokol de budur. Kendi daemon’unu çalıştırmalıdır ki bu da xinetd veya systemd yapılandırması veya benzerini gerektirir. Bu da her zaman kolay bir iş değildir. Ayrıca, kurumsal güvenlik duvarlarının her zaman izin vermediği, standart bir port olmayan, 9418 numaralı porta firewall erişimi gerektirir. Büyük kurumsal güvenlik duvarları arkasında, bu gizli port genellikle engellenir.

scroll-to-top