Bugün öğrendim ki: Sürüm kontrol yazılımı Git'in yaratıcısı Linus Torvalds, bir zamanlar "git" (İngiliz İngilizcesinde nahoş veya aptal insanlar için kullanılan bir argo) ismi hakkında şöyle demişti: "Ben egoist bir piçim ve tüm projelerime kendi adımı veriyorum. Önce 'Linux', şimdi de 'git'."
Dağıtık sürüm kontrol yazılım sistemi
Diğer kullanımlar için bkz. Git (belirsizleştirme).
GitHub, GitLab veya Gitea ile karıştırılmamalıdır.
GitOrijinal yazar(lar)Linus Torvalds[1]Geliştirici(ler)Junio Hamano ve diğerleri[2]İlk sürüm7 Nisan 2005; 20 yıl önce ( )Kararlı sürüm
2.51.0[3] / 18 Ağustos 2025
DepoYazıldığı dilÖncelikle C, GUI ve programlama betikleri Shell betiği, Perl, Tcl ve Python ile yazılmıştır[4][5]İşletim sistemiPOSIX (Linux, macOS, Solaris, AIX), WindowsMevcut dilİngilizceTürSürüm kontrolLisansıGPL-2.0-only[i][7]Web sitesigit-scm .com
Git ([8]), kaynak kodunun veya verilerin sürümlerini yönetme yeteneğine sahip dağıtık bir sürüm kontrol yazılım sistemidir. Genellikle yazılımı iş birliği içinde geliştiren programcılar tarafından kaynak kodu kontrol etmek için kullanılır.
Git'in tasarım hedefleri arasında hız, veri bütünlüğü ve dağıtık, doğrusal olmayan iş akışlarına destek – farklı bilgisayarlarda çalışan binlerce paralel dal – yer almaktadır.[10][11][12]
Çoğu diğer dağıtık sürüm kontrol sistemi gibi ve çoğu istemci-sunucu sisteminin aksine, Git, ağ erişiminden veya merkezi bir sunucudan bağımsız olarak, geçmişi ve sürüm izleme yetenekleriyle birlikte tüm deponun yerel bir kopyasını, "repo" olarak da bilinir, tutar. Bir depo, her bilgisayarda sürüm kontrol yetenekleri sağlamak için ek, gizli dosyalarla standart bir dizinde saklanır.[13] Git, geçmişi paylaşan depolar arasında değişiklikleri senkronize etmek için özellikler sağlar; eşzamansız iş birliği için bu, uzak makinelerdeki depoları da kapsar. Tüm depolar (aynı geçmişe sahip) eşit olsa da, geliştiriciler genellikle entegre bir kopyayı tutmak için bir depo barındırmak üzere merkezi bir sunucu kullanırlar.
Git, GPL-2.0-only lisansı altında paylaşılan ücretsiz ve açık kaynaklı bir yazılımdır.
Git, başlangıçta Linus Torvalds tarafından Linux çekirdeğinin geliştirilmesinde sürüm kontrolü için oluşturulmuştur.[14] "Git" ticari markası, Software Freedom Conservancy tarafından tescil edilmiştir.
Bugün Git, fiili standart sürüm kontrol sistemidir. 2022 itibariyle geliştiricilerin neredeyse %95'inin birincil sürüm kontrol sistemi olarak bildirdiği en popüler dağıtık sürüm kontrol sistemidir.[15][16][17] Profesyonel geliştiriciler arasında en yaygın kullanılan kaynak kodu yönetim aracıdır. GitHub, SourceForge, Bitbucket ve GitLab dahil olmak üzere Git depo hizmetleri sunulmaktadır.[18][19][20][21][22]
Geçmiş
[düzenle]
Torvalds, 2002'den beri Linux çekirdeği geliştirme için kullanılan tescilli kaynak kontrol yönetimi (SCM) sistemi BitKeeper'ın ücretsiz lisansı Linux için iptal edildikten sonra Nisan 2005'te Git'in geliştirilmesine başladı.[23][24] BitKeeper'ın telif hakkı sahibi Larry McVoy, Andrew Tridgell'in BitKeeper protokollerini tersine mühendislik yaparak SourcePuller'ı oluşturduğunu iddia etti.[25] Aynı olay, başka bir sürüm kontrol sistemi olan Mercurial'ın oluşturulmasını da hızlandırdı.
Torvalds, BitKeeper gibi kullanabileceği dağıtık bir sistem istiyordu, ancak mevcut ücretsiz sistemlerden hiçbiri ihtiyaçlarını karşılamıyordu. Bir yama uygulamak ve tüm ilgili meta verileri güncellemek için bir kaynak kontrol yönetim sisteminin 30 saniye gerektirdiği bir örneğe değindi ve bunun, diğer bakıcılarla senkronizasyonun aynı anda 250 kadar işlem gerektirebileceği Linux çekirdeği geliştirme ihtiyaçlarına ölçeklenemeyeceğini belirtti. Tasarım kriteri için, yamalamanın üç saniyeden fazla sürmemesi gerektiğini belirtti ve üç hedef daha ekledi:[10]
Yapılmayacak şeylere örnek olarak Eşzamanlı Sürüm Sistemi'ni (CVS) alın; şüphe duyduğunuzda tam ters karar verin.[12]
Dağıtık, BitKeeper benzeri bir iş akışını destekleyin.[12]
Kazayla veya kötü niyetle bozulmaya karşı çok güçlü güvenlik önlemleri ekleyin.[11]
Bu kriterler, o sırada kullanılan tüm sürüm kontrol sistemlerini ortadan kaldırdı, bu nedenle 2.6.12-rc2 Linux çekirdeği geliştirme sürümünden hemen sonra Torvalds kendi sürümünü yazmaya koyuldu.[12]
Git'in geliştirilmesi 3 Nisan 2005'te başladı.[26] Torvalds, projeyi 6 Nisan'da duyurdu ve ertesi gün kendi kendine barındırmaya başladı.[26][27] Birden fazla dalın ilk birleştirilmesi 18 Nisan'da gerçekleşti.[28] Torvalds performans hedeflerine ulaştı; 29 Nisan'da yeni Git, Linux çekirdeği ağacına saniyede 6,7 yama kaydeden hızda yama uygulama ölçümlerine tabi tutuldu.[29] 16 Haziran'da Git, çekirdek 2.6.12 sürümünü yönetti.[30]
Torvalds, 26 Temmuz 2005'te projenin önemli bir katkıda bulunanı olan Junio Hamano'ya bakımı devretti.[31] Hamano, 21 Aralık 2005'te 1.0 sürümünden sorumluydu.[32]
Adlandırma
[düzenle]
Torvalds, git adıyla ilgili olarak (İngiliz İngilizcesinde hoş olmayan veya aptal bir kişi için kullanılan bir argo) alaycı bir şekilde şöyle dedi: "Ben egoist bir herifim ve tüm projelerime kendi adımın koyuyorum. Önce 'Linux', şimdi 'git'."[33][34] El kitabında Git, "aptal içerik izleyici" olarak tanımlanmaktadır.[35]
Kaynak kodunun okuyun dosyası daha da ayrıntılı bilgi vermektedir:[36]
"git", ruh halinize bağlı olarak herhangi bir şey anlamına gelebilir.
Telaffuz edilebilir ve yaygın bir UNIX komutu tarafından aslında kullanılmayan rastgele üç harfli kombinasyon. Bunun "get" kelimesinin yanlış telaffuzu olması ilgili olabilir veya olmayabilir.
Aptal. Küçümsenen ve aşağılık. Basit. Argo sözlüğünden dilediğinizi seçin.
"Genel bilgi izleyici": İyi bir ruh halindesinizdir ve gerçekten sizin için çalışır. Melekler şarkı söyler ve birdenbire odanın içini bir ışık doldurur.
"Kahretsin aptal bir kamyon dolusu bok": Bozulduğunda.
Git'in kaynak kodu, programa "cehennemden gelen bilgi yöneticisi" olarak atıfta bulunur.[37][38]
Özellikler
[düzenle]
Tasarım
[düzenle]
Git'in tasarımı, Torvalds'ın büyük bir dağıtık geliştirme projesinin bakımında Linux ile olan deneyiminin, aynı projeden elde edilen dosya sistemi performansı hakkındaki ayrıntılı bilgisi ve kısa sürede çalışan bir sistem üretme acil ihtiyacıyla bir sentezidir. Bu etkiler, aşağıdaki uygulama seçimlerine yol açmıştır:[14]
Doğrusal olmayan geliştirmeye güçlü destek
Git, hızlı dallanmayı ve birleştirmeyi destekler ve doğrusal olmayan bir geliştirme geçmişini görselleştirmek ve gezmek için özel araçlar içerir. Git'te, bir değişikliğin, çeşitli denetleyicilere geçerken yazıldığından daha sık birleştirileceği temel bir varsayımdır. Git'te dallar çok hafiftir: bir dal yalnızca bir gönderime yapılan bir başvurudur.
Dağıtık geliştirme
Darcs, BitKeeper, Mercurial, Bazaar ve Monotone gibi Git, her geliştiriciye tam geliştirme geçmişinin yerel bir kopyasını verir ve değişiklikler bir depodaki diğerine kopyalanır. Bu değişiklikler eklenen geliştirme dalları olarak içe aktarılır ve yerel olarak geliştirilen bir dal ile aynı şekilde birleştirilebilir.[39]
Mevcut sistemler ve protokollerle uyumluluk
Depolar, Güvenli Hiper Metin Transfer Protokolü (HTTPS), Hiper Metin Transfer Protokolü (HTTP), Dosya Transfer Protokolü (FTP) veya düz bir soket veya Güvenli Kabuk (ssh) üzerinden bir Git protokolü aracılığıyla yayınlanabilir. Git'in ayrıca mevcut CVS istemcilerinin ve IDE eklentilerinin Git depolarına erişmesine olanak tanıyan bir CVS sunucu taklidi vardır. Subversion depoları git-svn ile doğrudan kullanılabilir.[40]
Büyük projelerin verimli bir şekilde işlenmesi
Torvalds, Git'i çok hızlı ve ölçeklenebilir olarak tanımlamıştır[41] ve Mozilla tarafından yapılan performans testleri[42], büyük depoları farklılaştırmada Mercurial ve GNU Bazaar'dan on kat daha hızlı olduğunu göstermiştir; yerel olarak depolanan bir depodaki sürüm geçmişinin alınması, uzak sunucudan alınmasından yüz kat daha hızlı olabilir.[43]
Geçmişin kriptografik kimlik doğrulaması
Git geçmişi, belirli bir sürümün (Git terimlerinde bir gönderim) kimliğinin o gönderime kadar olan tam geliştirme geçmişine bağlı olduğu şekilde saklanır. Yayınlandıktan sonra, fark edilmeden eski sürümleri değiştirmek mümkün değildir. Yapı, düğümlerde ve yapraklarda ek verilerle bir Merkle ağacına benzer.[44] (Mercurial ve Monotone da bu özelliğe sahiptir.)
Araç takımına dayalı tasarım
Git, C ve bu programların etrafına sarmalayıcılar sağlayan birkaç shell betiğinde yazılmış bir dizi program olarak tasarlanmıştır.[45] Bu betiklerin çoğu o zamandan beri hız ve taşınabilirlik için C'de yeniden yazılmış olsa da, tasarım kalır ve bileşenleri birbirine bağlamak kolaydır.[46]
Takılabilen birleştirme stratejileri
Araç takımına dayalı tasarımının bir parçası olarak, Git tamamlanmamış bir birleştirmenin iyi tanımlanmış bir modeline sahiptir ve bunu tamamlamak için birden fazla algoritmaya sahiptir; bu, kullanıcının birleştirmeyi otomatik olarak tamamlayamadığını ve elle düzenlemenin gerekli olduğunu söylemekle sonuçlanır.[47]
Çöp toplanana kadar birikir
İşlemleri iptal etmek veya değişiklikleri geri almak, veritabanında kullanışsız sarkık nesneler bırakacaktır. Bunlar genellikle istenen nesnelerin sürekli büyüyen geçmişinin küçük bir bölümüdür. Git, depoya yeterince gevşek nesne oluşturulduğunda otomatik olarak çöp toplama gerçekleştirir. Çöp toplama, git gc kullanılarak açıkça çağrılabilir.[49]
Periyodik açık nesne paketleme
Git, yeni oluşturulan her nesneyi ayrı bir dosya olarak depolar. Bireysel olarak sıkıştırılsa da, bu çok fazla yer kaplar ve verimsizdir. Bu, çok sayıda nesneyi kendi aralarında delta sıkıştırmasıyla tek bir dosyada (veya ağ bayt akışında) paket dosyası olarak adlandırılan bir dosyada saklayan paketlerin kullanımıyla çözülür. Paketler, aynı ada sahip dosyaların muhtemelen benzer olduğu varsayımı kullanılarak, doğruluğa bağlı kalmadan sıkıştırılır. Her paket dosyası için, paket dosyasındaki her nesnenin kaymasını kaydeden ilgili bir dizin dosyası oluşturulur. Yeni oluşturulan nesneler (yeni eklenen geçmişle) hala tek nesne olarak saklanır ve alan verimliliğini korumak için periyodik yeniden paketleme gereklidir. Deponun paketlenmesi işlemi çok fazla işlem gücü gerektirebilir. Nesnelerin depo içinde hızlı oluşturulmuş ancak gevşek bir biçimde var olmasına izin vererek, Git, pahalı paketleme işleminin daha sonra, zamanın daha az önemli olduğu durumlarda, örneğin iş gününün sonunda ertelenmesine olanak tanır. Git otomatik olarak periyodik yeniden paketleme yapar, ancak git gc komutu ile manuel yeniden paketleme de mümkündür. Veri bütünlüğü için hem paket dosyasının hem de dizininin içinde bir SHA-1 toplamı bulunur ve paket dosyasının dosya adı da bir SHA-1 toplamı içerir. Bir deponun bütünlüğünü kontrol etmek için git fsck komutunu çalıştırın.[52]
Git'in bir başka özelliği de dosyaların dizin ağaçlarını anlık görüntü olarak kaydetmesidir. Kaynak kodunun sürümlerini izlemek için en eski sistemler olan Kaynak Kod Kontrol Sistemi (SCCS) ve Revizyon Kontrol Sistemi (RCS), tek tek dosyalar üzerinde çalışmış ve (çoğunlukla benzer) sürümlerin birbirine geçmiş deltalardan (SCCS) veya delta kodlamasından (RCS) elde edilecek alan tasarruflarına odaklanmıştır. Daha sonraki revizyon kontrol sistemleri, bir dosyanın bir projenin birden çok revizyonu boyunca bir kimliğe sahip olduğu bu düşünceyi korudu. Ancak Torvalds bu konsepti reddetti.[54] Sonuç olarak, Git kaynak kodu ağacının altındaki herhangi bir seviyede dosya revizyon ilişkilerini açıkça kaydetmez.
Dezavantajlar
[düzenle]
Bu örtük revizyon ilişkilerinin bazı önemli sonuçları vardır:
Tek bir dosyanın değişiklik geçmişini incelemek, tüm projeden biraz daha pahalıdır.[55] Belirli bir dosyayı etkileyen değişikliklerin geçmişini elde etmek için Git, küresel geçmişte gezinmeli ve ardından her değişikliğin o dosyayı değiştirip değiştirmediğini belirlemelidir. Bununla birlikte, bu geçmiş inceleme yöntemi, Git'in rastgele bir dosya kümesindeki değişiklikleri gösteren tek bir geçmişi eşit verimlilikle üretmesine olanak tanır. Örneğin, kaynak ağacının bir alt dizini artı ilişkili bir genel üstbilgi dosyası çok yaygın bir durumdur.
Ad değişiklikleri açıkça değil, örtük olarak ele alınır. CVS ile ilgili yaygın bir şikayet, dosyanın adını revizyon geçmişini tanımlamak için kullanması, böylece bir dosyanın taşınmasının veya adının değiştirilmesinin ya geçmişini kesintiye uğratmadan ya da geçmişin adını değiştirmeden ve böylece geçmişi yanlış yapmadan mümkün olmamasıdır. CVS sonrası çoğu revizyon kontrol sistemi, bunu, ad değiştirmeden kurtulan uzun süreli benzersiz bir ada (inode numarasıyla aynı) sahip bir dosya vererek çözer. Git böyle bir tanımlayıcı kaydetmez ve bu bir avantaj olarak iddia edilir.[56][57] Kaynak kodu dosyaları bazen bölünür veya birleştirilir veya basitçe adlandırılır[58] ve bunu basit bir ad değiştirme olarak kaydetmek, (değiştirilemez) geçmişte olanların yanlış bir tanımını dondurur. Git, anlık görüntülerin geçmişinde gezinirken ad değişikliklerini tespit ederek, anlık görüntüyü oluştururken kaydetmek yerine bu sorunu ele alır.[59] (Kısaca, revizyon N'de bir dosya verildiğinde, revizyon N − 1'deki aynı adlı dosya varsayılan atasıdır. Ancak, revizyon N − 1'de aynı adlı bir dosya olmadığında, Git yalnızca revizyon N − 1'de mevcut olan ve yeni dosyaya çok benzer bir dosya arar.) Bununla birlikte, her geçmiş incelendiğinde daha fazla CPU yoğun iş gerektirir ve sezgisellikleri ayarlamak için birkaç seçenek mevcuttur. Bu mekanizma her zaman işe yaramaz; bazen aynı gönderimde değişikliklerle adlandırılan bir dosya, eski dosyanın silinmesi ve yeni bir dosyanın oluşturulması olarak okunur. Geliştiriciler bu sınırlamanın üstesinden, ad değişikliğini ve değişiklikleri ayrı ayrı göndererek gelebilirler.
Birleştirme stratejileri
[düzenle]
Git, birkaç birleştirme stratejisi uygular; birleştirme sırasında varsayılan olmayan bir strateji seçilebilir:[60]
çözüm: geleneksel üç yönlü birleştirme algoritması.
özyinelemeli: Bu, bir dal çekerken veya birleştirirken varsayılandır ve üç yönlü birleştirme algoritmasının bir çeşididir.
Üç yönlü birleştirme için kullanılabilecek birden fazla ortak ata olduğunda, ortak ataların birleştirilmiş bir ağacı oluşturur ve bunu üç yönlü birleştirme için referans ağacı olarak kullanır. Bunun, Linux 2.6 çekirdeği geliştirme geçmişinden alınan önceki birleştirme gönderimleri üzerinde yapılan testlerle yanlış birleştirmelere neden olmadan daha az birleştirme çatışmasıyla sonuçlandığı bildirilmiştir. Ayrıca, ad değişiklikleri içeren birleştirmeleri tespit edip işleyebilir.
— Linus Torvalds[61]
ahtapot: Bu, ikiden fazla başlığı birleştirirken varsayılandır.
Veri yapıları
[düzenle]
Git'in ilkel yapılarının temelde bir kaynak kodu yönetim sistemi değildir. Torvalds şöyle açıklıyor:[62]
Birçok yönden, git'i sadece bir dosya sistemi olarak görebilirsiniz—içerik tabanlıdır ve sürümleme kavramına sahiptir, ancak gerçekten de soruna bir dosya sistemi kişisinin bakış açısından yaklaşarak tasarladım (hey, ben çekirdekler yapıyorum) ve geleneksel bir SCM sistemi oluşturmakla kesinlikle hiçbir ilgilenmiyorum.
Bu ilk tasarım yaklaşımından itibaren, Git, geleneksel bir SCM'den beklenen tüm özellik kümesini, çoğunlukla gerektiğinde oluşturulan, daha sonra zaman içinde geliştirilen ve genişletilen özellikler geliştirmiştir.[63]
Git'in iki veri yapısı vardır: çalışma dizini ve gönderilecek bir sonraki revizyon hakkında bilgi önbelleğe alan değişebilir bir dizin (aşama veya önbellek olarak da adlandırılır); ve değişmez nesneleri saklayan bir nesne veritabanı.
Dizin, nesne veritabanı ve çalışma ağacı arasında bir bağlantı noktası görevi görür.
Nesne deposu beş nesne türü içerir:[64][52]
Bir blob, bir dosyanın içeriğidir. Blob'ların uygun bir dosya adı, zaman damgası veya diğer meta verileri yoktur (bir blob'un adı içsel olarak içeriğinin bir karma değeridir). Git'te her blob, dosyanın verilerinin bulunduğu bir dosyanın bir sürümüdür.
Bir ağaç nesnesi, bir dizinin karşılığıdır. Her birinde bazı tür bitleri ve o dosyanın, sembolik bağlantının veya dizinin içeriği olan bir blob veya ağaç nesnesine başvuru bulunan bir dosya adları listesi içerir. Bu nesneler kaynak ağacının bir anlık görüntüsüdür. (Bütünüyle, bu bir Merkle ağacı oluşturur, yani yalnızca kök ağacın tek bir karma değeri, herhangi bir sayıda alt dizinin ve dosyanın tüm ağaç yapılarının kesin durumunu tam olarak belirlemek için gönderimlerde yeterlidir ve aslında kullanılır.)
Bir gönderim nesnesi, ağaç nesnelerini geçmişe bağlar. En üst düzey kaynak dizininin bir ağaç nesnesinin adını, bir zaman damgasını, bir günlük iletisini ve sıfır veya daha fazla üst gönderim nesnesinin adlarını içerir.
Bir etiket nesnesi, başka bir nesneye başvuru içeren ve başka bir nesneyle ilgili ek meta veriler tutabilen bir kapsayıcıdır. Genellikle, Git tarafından izlenen verilerin belirli bir sürümüne karşılık gelen bir gönderim nesnesinin dijital imzasını depolamak için kullanılır.
Bir paket dosyası nesnesi, çeşitli diğer nesneleri kompaktlık ve ağ protokolleri üzerinden kolay taşıma için zlib sıkıştırılmış bir demete toplar.
Her nesne, içeriğinin SHA-1 karma değeriyle tanımlanır. Git karma değerini hesaplar ve bunu nesnenin adı için kullanır. Nesne, karma değerinin ilk iki karakteriyle eşleşen bir dizine konur. Kalan karma değer, o nesnenin dosya adı olarak kullanılır.
Git, bir dosyanın her revizyonunu benzersiz bir blob olarak depolar. Blob'lar arasındaki ilişkiler, ağaç ve gönderim nesnelerini inceleyerek bulunabilir. Yeni eklenen nesneler, zlib sıkıştırma kullanılarak bütünüyle saklanır. Bu, hızlı bir şekilde çok fazla disk alanı tüketebilir, bu nedenle nesneler, alanı kaydetmek için delta sıkıştırmasını kullanarak paketlere birleştirilebilir ve blob'ları diğer blob'lara göre değişiklikleri olarak saklayabilir.
Ayrıca, Git, çeşitli gönderimlerin konumlarını belirtmek için ref'ler (referanslar için kısaltma) olarak adlandırılan etiketler depolar. Sırasıyla referans veritabanında saklanırlar:[70]
Başlıklar (dalları): Üzerlerine bir gönderim yapıldığında otomatik olarak yeni gönderime ilerleyen adlandırılmış referanslar.
HEAD: Çalışma ağacı ile karşılaştırılacak ve bir gönderim oluşturacak ayrılmış bir başlık.
Etiketler: Dal referanslarına benzer, ancak belirli bir gönderime sabitlenmiş. Geçmişte önemli noktaları etiketlemek için kullanılır.
Komutlar
[düzenle]
Git'in komut satırı arayüzü için sık kullanılan komutlar şunlardır:[71][72]
git init, bir git deposu oluşturmak için kullanılır.
git clone [URL], harici bir URL'den bir git deposunu klonlar veya çoğaltır.
git add [dosya], bir dosyayı git'in çalışma dizinine ekler (gönderilecek dosyalar).
git commit -m [gönderim iletis], dosyaları geçerli çalışma dizininden gönderir (bu nedenle artık deponun geçmişinin bir parçasıdırlar).
Bir Git deposunda düz metin dosyası olarak bir .gitignore dosyası oluşturulabilir. .gitignore dosyasında listelenen dosyalar Git tarafından izlenmez.[73]: 3–4 Bu özellik, anahtar veya parolalı dosyaları, çeşitli gereksiz dosyaları ve büyük dosyaları (GitHub'ın yüklemeyi reddedeceği) yok saymak için kullanılabilir.[74]
Git referansları
[düzenle]
Referans verilmeyen Git veritabanındaki her nesne, çöp toplama komutu kullanılarak veya otomatik olarak temizlenebilir. Bir nesne başka bir nesne veya açık bir referans tarafından referans verilebilir. Git'in farklı referans türleri vardır. Referansları oluşturmak, taşımak ve silmek için komutlar değişir. git show-ref tüm referansları listeler. Bazı türler şunlardır:
başlıklar: yerel olarak bir nesneye atıfta bulunur,
uzaktan: uzak bir depoda bulunan bir nesneye atıfta bulunur,
saklama alanı: henüz gönderilmemiş bir nesneye atıfta bulunur,
meta: örneğin, çıplak bir depoda yapılandırma, kullanıcı hakları; refs/meta/config ad alanı geriye dönük olarak getirilmiştir, Gerrit tarafından kullanılır[75],
etiketler: yukarıya bakın.
Uygulamalar
[düzenle]
Git (C'deki ana uygulama), çoğunlukla Linux'ta geliştirilmiştir, ancak BSD'ler (DragonFly BSD, FreeBSD, NetBSD ve OpenBSD), Solaris, macOS ve Windows dahil olmak üzere çoğu büyük işletim sistemini de destekler.[76][77]
Git'in ilk Windows bağlantı noktası, öncelikle Linux sürümünü barındıran bir Linux taklit çerçevesi idi. Windows altında Git'in yüklenmesi, GNU Derleyici Koleksiyonunun Mingw-w64 bağlantı noktasını, Perl 5'i, MSYS2'yi (kendi başına Cygwin'in bir çatalı olan, Windows için Unix benzeri bir taklit ortamı) ve çeşitli diğer Windows bağlantı noktalarını veya Linux yardımcı programlarının ve kitaplıklarının taklitlerini içeren benzer şekilde adlandırılmış bir Program Files dizini oluşturur. Şu anda, Git'in yerel Windows derlemeleri 32 ve 64 bit yükleyiciler olarak dağıtılmaktadır.[78] Git resmi web sitesi, şu anda hala MSYS2 ortamını kullanan Git for Windows'un bir derlemesini sürdürmektedir.[79]
Git'in JGit uygulaması, herhangi bir Java uygulamasına gömülecek şekilde tasarlanmış saf bir Java yazılım kitaplığıdır. JGit, Gerrit kod inceleme aracında ve Eclipse IDE'si için bir Git istemcisi olan EGit'te kullanılır.[80]
Go-git, saf Go ile yazılmış açık kaynaklı bir Git uygulamasıdır.[81] Şu anda, Git kod depoları için SQL arayüzü olarak projeleri desteklemek[82] ve Git için şifreleme sağlamak için kullanılmaktadır.[83]
Dulwich, CPython 3.6 ve sonrası ve Pypy desteğiyle saf Python'da yazılmış bir Git uygulamasıdır.[84]
Git'in libgit2 uygulaması, Windows, Linux, macOS ve BSD dahil olmak üzere birden çok platformda oluşturulabilen başka bağımlılıkları olmayan bir ANSI C yazılım kitaplığıdır.[85] Ruby, Python ve Haskell dahil olmak üzere birçok programlama dili için bağlamaları vardır.[86][87][88]
JS-Git, Git'in bir alt kümesinin bir JavaScript uygulamasıdır.[89]
Game of Trees, OpenBSD projesi için açık kaynaklı bir Git uygulamasıdır.[90]
Git sunucusu
[düzenle]
Git dağıtık bir sürüm kontrol sistemi olduğu için, kutudan çıkar çıkmaz sunucu olarak kullanılabilir. Basit bir TCP sunucusu başlatan yerleşik bir git daemon komutu ile birlikte gelir ve Git protokolü üzerinde çalışır.[92] Özel Git HTTP sunucuları, erişim denetimi ekleyerek, bir Git deposunun içeriğini web arayüzleri aracılığıyla görüntülemek ve birden çok depoyu yönetmek gibi (diğer özellikler arasında) yardımcı olur. Zaten var olan Git depoları klonlanabilir ve paylaşılabilir ve başkaları tarafından merkezi bir depo olarak kullanılmak üzere paylaşılabilir. Git yazılımının kurulu olması ve bir kullanıcının oturum açmasına izin verilmesi durumunda uzak kabuk aracılığıyla da erişilebilir.[93] Git sunucuları genellikle TCP bağlantı noktası 9418'de dinler.[94]
Açık kaynak
[düzenle]
Git Binary'yi kullanarak Git sunucusunun barındırılması.[95]
Gerrit, kod incelemelerini desteklemek ve ssh, entegre bir Apache MINA veya OpenSSH veya entegre bir Jetty web sunucusu aracılığıyla erişim sağlamak için yapılandırılabilir bir Git sunucusu. Gerrit, LDAP, Active Directory, OpenID, OAuth, Kerberos/GSSAPI, X509 https istemci sertifikaları için entegrasyon sağlar. Gerrit 3.0 ile tüm yapılandırmalar Git depoları olarak saklanacak ve çalıştırmak için veritabanına gerek yoktur. Gerrit'in çekme isteği özelliği çekirdeğinde uygulanmıştır, ancak bunun için bir GUI eksiktir.
Facebook'tan ayrılan bir şirket olan Phabricator. Facebook öncelikle Mercurial kullandığı için Git desteği o kadar belirgin değildir.[96]
AGPLv3 lisansıyla Git, Mercurial ve Subversion'ı destekleyen RhodeCode Community Edition (CE).
Python ile geliştirilmiş ve GPL lisanslı Git ve Mercurial'ı destekleyen Kallithea.
Git yazılımının üzerine ince taneli erişim denetimi sağlamak için betikler sağlayan gitolite[97] gibi harici projeler.
Gogs[98], Gogs'un bir çatalı olan Gitea ve sırayla Gitea'nın bir çatalı olan Forgejo dahil olmak üzere kendi kendine barındırma için birkaç başka FLOSS çözümü vardır. Gogs ve yukarıda belirtilen iki türevi, Go dili kullanılarak geliştirilmiştir. Üç çözüm de MIT lisansı altında sağlanmaktadır.
Hizmet olarak Git sunucusu
[düzenle]
Ayrıca bkz: Kaynak kod barındırma tesislerinin karşılaştırılması
Hizmet olarak Git depoları için birçok teklif vardır. En popüler olanlar GitHub, SourceForge, Bitbucket ve GitLab'tır.[99][19][20][21][22]
Grafik arayüzler
[düzenle]
Git GUI istemcileri, Git depolarıyla etkileşimi basitleştirmek için grafik kullanıcı arayüzü (GUI) sunar.
Bu GUI'ler, dalları, gönderimleri ve dosya değişikliklerini içeren projenin geçmişinin görsel temsillerini sağlar. Ayrıca değişiklikleri aşamaya alma, gönderim oluşturma ve dalları yönetme gibi işlemleri basitleştirirler. Görsel fark araçları, eşzamanlı geliştirmeden kaynaklanan birleştirme çatışmalarının çözülmesine yardımcı olur.
Git, kullanıcılara gönderim oluşturma ve değiştirme, dal oluşturma ve birleştirme ve uzak depolarla etkileşim kurma gibi işlemler yapma olanağı sağlayan bir Tcl/Tk GUI ile birlikte gelir.[100]
Resmi GUI'ye ek olarak, dağıtılan resmi GUI ile benzer özellikler sağlayan birçok üçüncü taraf arayüzü mevcuttur.[101]
GUI istemcileri, Git'in öğrenilmesini ve kullanılmasını kolaylaştırır, iş akışı verimliliğini artırır ve hataları azaltır.
Kabul
[düzenle]
Eclipse Foundation, yıllık topluluk araştırmasında, Mayıs 2014 itibariyle Git'in artık en yaygın kullanılan kaynak kodu yönetim aracı olduğunu ve profesyonel yazılım geliştiricilerin %42,9'unun birincil kaynak kontrol sistemi olarak Git kullandığını bildirdiğini bildirmiştir[102] (2013'te %36,3, 2012'de %32); veya GitHub kullanımını hariç tutan Git yanıtları için: 2014'te %33,3, 2013'te %30,3, 2012'de %27,6 ve 2011'de %12,8.[103] Açık kaynak dizini Open Hub, açık kaynak projelerinde benzer bir artış bildirmektedir.[104]
Stack Overflow, 2015 (16.694 yanıt)[106], 2017 (30.730 yanıt)[107], 2018 (74.298 yanıt)[108] ve 2022 (71.379 yanıt)[17] yıllarındaki yıllık geliştirici araştırmasına sürüm kontrolü eklemiştir.[105] Bu araştırmalara yanıt veren geliştiricilerin ezici çoğunluğu Git'i tercih etti ve 2022'de %93,9'a kadar yüksek bir oranda bildirdi.
Yanıt veren geliştiriciler tarafından kullanılan sürüm kontrol sistemleri:
Ad 2015 2017 2018 2022 Git %69,3 %69,2 %87,2 %93,9 Subversion %36,9 %9,1 %16,1 %5,2 TFVC %12,2 %7,3 %10,9 [ii] Mercurial %7,9 %1,9 %3,6 %1,1 CVS %4,2 [ii] [ii] [ii] Perforce %3,3 [ii] [ii] [ii] VSS [ii] %0,6 [ii] [ii] IBM DevOps Code ClearCase [ii] %0,4 [ii] [ii] Zip dosyası yedekleri [ii] %2,0 %7,9 [ii] Ham ağ paylaşımı [ii] %1,7 %7,9 [ii] Diğer %5,8 %3,0 [ii] [ii] Hiçbiri %9,3 %4,8 %4,8 %4,3
İngiltere BT iş web sitesi itjobswatch.co.uk, Eylül 2016 sonlarına kadar İngiltere'deki kalıcı yazılım geliştirme iş açıklıklarının %29,27'sinin Git'i[109] (Microsoft Team Foundation Server için %12,17'nin[110], Subversion için %10,60'ın[111], Mercurial için %1,30'un[112] ve Visual SourceSafe için %0,48'in[113] önünde) gösterdiğini bildirmektedir.
Uzantılar
[düzenle]
Git LFS gibi birçok Git uzantısı vardır; bu, GitHub topluluğunda Git'in bir uzantısı olarak başlamış ve şimdi diğer depolar tarafından yaygın olarak kullanılmaktadır. Uzantılar genellikle farklı kişiler tarafından bağımsız olarak geliştirilir ve bakımı yapılır, ancak gelecekteki bir noktada yaygın olarak kullanılan bir uzantı Git ile birleştirilebilir.
Diğer açık kaynaklı Git uzantıları şunlardır:
git-annex, Git tabanlı dağıtık bir dosya senkronizasyon sistemi
git-flow, Vincent Driessen'ın dallanma modeli için üst düzey depo işlemleri sağlamak üzere bir Git uzantıları kümesi
git-machete, bir depo düzenleyici ve yeniden tabanlama/birleştirme/çekme/itme işlemlerini otomatikleştirmek için bir araç
Microsoft, 2017'deki Perforce'dan geçişlerinin bir parçası olarak Windows kaynak kodu ağacının boyutunu yönetmek için Git için Sanal Dosya Sistemi (VFS for Git; eski adıyla Git Sanal Dosya Sistemi veya GVFS) uzantısını geliştirdi. VFS for Git, klonlanan depoların içeriği yalnızca bir dosyaya erişildiğinde indirilen yer tutucular kullanmasına olanak tanır.[114]
Kurallar
[düzenle]
Git çeşitli şekillerde kullanılabilir, ancak bazı kurallar yaygın olarak benimsenmiştir.
Yerel bir depo oluşturmak için komut olan git init, master adlı bir dal oluşturur.[115] Genellikle değişiklikleri birleştirmek için entegrasyon dalı olarak kullanılır.[116] Varsayılan yukarı akış uzaktan bağlantının origin olarak adlandırıldığı için, varsayılan uzaktan dal origin/master'dır. GitHub ve GitLab gibi bazı araçlar bunun yerine main adlı bir varsayılan dal oluşturur.[118][119] Ayrıca kullanıcılar dal ekleyip silebilir ve birleştirme için herhangi bir dalı seçebilir.
Gönderilen gönderimler genellikle üzerine yazılmaz, ancak daha önceki bir gönderimi tersine çeviren başka bir değişiklik gönderilerek geri alınır.[120] Bu, temel aldıkları gönderim uzaktan bağlantıda olmadığı için paylaşılan gönderimlerin geçersiz olmasını önler. Gönderimler hassas bilgiler içeriyorsa, geçmişi yeniden yazmak için daha