sürüm kontrol sistemi ^*

• cok buyuk (milyonlarca satir binlerce developer gibi) projelerde versiyon yonetimini saglayan bir arac olmaktan cikip basli basina bir bilim ve teknik hadisesi haline gelen sey. oyle ki ayni projenin uzak koselerinde calisan insanlarin birbirlerinin degisikliklerini gormesi birkac ay alabiliyor (!). surpriz.
• (bkz: mercurial)
• (bkz: mercurial)
• (bkz: git (yazılım)) vikipedi: git (yazılım) en çok kullanılanı, (bkz: linux)'u yazanlar onun yanısıra geliştirmiş, dağıtık (ana kümenin bir çok kopyası bir çok kullanıcı elinde, değişiklikler güven temelli dağıtılacak şekilde tasarlanmış), dosyaların son kopyasına ulaşım ve başka bir yeni kopya ile "merge" işlemi hızlı olacak şekilde gerçekleştirilmiş, linux'un tüm server parklarında işletme sistemlerinin yerini yavaştan alması gibi, git de tüm yazılım geliştirme ortamlarında sürüm kontrol sistemlerinin yerini alacak gibi görünüyor.
• yazı ile ifade edilebilen fikir ürünü üreten herkes, romancılar, hikayeciler, şairler, senaryo yazarları, gazeteciler, köşe yazarları, hatta ekşi sözlük yazarları, günümüzde yazı ile ifade edilebilen grafik ürünler (örneğin svg veya pdf formatında dosyalar olarak saklanabilen grafikler) ortaya koyanlar, ama en çok bilgisayar programı yazanlar bilirler:
  - yazanın gözünde yazılan hep yetersizdir, ihtiyaç ağır basar o günkü halini sunmak zorunda kalırsınız, sonra düzeltmeler, ekler, güzelleştirmeler yaparsınız. o hali de içinizi tam ısıtmasa da bir evvelkinden daha iyi olduğu için en azından bundan sonra görenler bu son sunumu görsün istersiniz. gelmiş geçmiş tüm sürümlerin birer kopyasını hem de her yeni sürümün bir evvelkinden ne farkı oluğunu hatırlamak pratik olmayabilir. mesela dostoyevski eseri suç ve cezayı yazarken her gün bir evvelki günün sonucunun kopyasını o gün nelerin yeni olduğunu da not ederek kenara koyamazdı herhalde? buna ne vakti, ne kağıdına parası, ne de kitaplığındaki boş raf yeri yeterdi. bu, elde sonuncudan başka sürüm (version) olmaması sorunudur.
  - bazen son sürüm, hem öyle bir kötü duruma sebep olur, hem de anında düzeltilemez ki, tek çare, en azından doğru düzeltilmiş bir sonraki sürüm geliştirilene kadar, ürünün bir evvelki sürümüne geri dönmek olur ( ricat/irtica, rollback)
  - böyle bir kötü durum oluştuğunda, sebep olan hata veya yanlışın (error), ve oluşmuş pürüzün (defect) ne olduğu ve nasıl değiştirilmesi gerektiği (change) , işin göreceli olarak kolay kısmıdır. zor olan kısmı şu gibi konulardır:
  - - bu kötü duruma (failure) sebep olan pürüzün ilk ne zaman, hangi eski sürümde görüldüğü,
  - - o sürümden bu sürüme ayni pürüzü içeren hallerini teslim alan müşterilerin nasıl bilgilendirileceği, düzeltmeyi nasıl edinecekleri
  - - ürünün o kısmını bizden önce başka birileri yapmış biz sadece onu kendi ürünümüzde bir parça olarak kullanıyor idiysek:
  - - - hata bilgisinin ve olası düzeltmenin asıl eser sahibine nasıl ulaştırılacağı (problem, issue),
  - - - onun önerdiğimiz düzeltmeyi kabul edip etmeyeceği, veya daha güzel bir düzeltmeyi kendisi yapması halinde (değişiklik önerisi,change proposal):
  - - - - o eserin hatalı sürümünü alıp kullanmış biz veya üçüncü kişiler tarafından eserin sahibince düzeltilmiş yeni sürümünün nasıl haberinin alınıp teslim alınabileceği (sunum, release),
  - - - - bu yeni sürümün son haliyle de onların işlerine yarayıp yaramayacağının kontrolünün sorunsuz nasıl yapabileceği (deneme, testing).
  
  günümüz sayısal ortamlarında kopya almak, kopyayı uzak ve daha güvenli bir depoya taşımak saniyeler tutsa da ilk gün yazılanların her geçen gün o günkü sürümün de bir parçası olduğu için yeniden bir kopyasını alıp ayrı ayrı saklamak elektronik hafıza israfıdır, ayrıca da binlerce birbirinin aynisi olmak zorunda olan kopyanın ayni şekilde hatasız, tahrifsiz tutulmasının temini ve kontrolünün zorluğu gibi sorunlar var.
  
  bu yüzden bilgisayar programcıları önce kendi ihtiyaçlarına bir çare olarak kullandıkları ve adını "sürüm kontrol sistemi" koyup geliştirdikleri yüzlerce yardımcı program vardır. bunların şu an en gelişmiş görünen ve en çok kullanılanı 2005 yılında linus thorwalds adlı finlandiyalı genç linux'u yazar iken evvelkileri beğenmeyip ilk sürümünü oturup bir haftada kendisi yazdığı git sürüm kontrol sistemidir. linus thorwalds asıl ilgi konusu olan linux'a yoğunlaşabilmek için git yazılımının eksiklerinin tamamlanması, bulunan hatalarının düzeltilmesi, gelen istekler doğrultusunda daha da geliştirilmesi işini junio hamano'ya bırakmış. onun liderliğinde bu iş linux'un yanısıra ilerlemiş, hem git kendisi, hem kullanıcı kitlesi, hem de git sisteminin neler yapabilmesi gerektiği konusundaki beklentiler çığ gibi büyümüş, gitin kullanımını kolaylaştıran, daha geniş kitlelerin ulaşımına açan başka uygulamalar geliştirilmiştir.
  
  git genellikle terminal konsolundan kendine özel komutalarla kullanılsa da arka planında git komutaları kullanan daha kullanılışlı birçok grafik arayüzü de bulunmaktadır. en bilinenleri şunlardır: masa üstü uygulaması olarak sourcetree, integrated development environment veya kısaca ide içinde menü seçeneği olarak visual studio, intellij idea gibi uygulamalar, intranet web sitesi olarak bitbucket, ve internet web sitesi olarak github ve gitlab.
  
  git, zamanla bir çok kavram, bu kavramlara denk gelen bir çok karmaşık veri düzeni, bunların birbirlerine olan ilişkilerinin ne olduğu, nasıl kaydedildiği, ve bu işlemleri bilgisayara yaptırmak için ne kumandalar ve kumanda ayarları bunlara ihtiyaç duymuş ve edinmiştir. işte belli başlıları:
  1- git, dağıtık bir sürüm kontrol sistemidir. yani birden fazla kişi ayni eseri birbirinden bağımsız yaptıkları katkılarla tamama erdirebilirler. bu işi yaparken, her birinde eserin son halinin ve tüm geçmişinin tam kopyası kendi bilgisayarında olur ve kendisi o kopyayı değiştirerek üzerinde calışır.
  2- git gölgesinde herhangi bir klasör, init veya clone kumandaları ile bir git repository, yani bir git dosya deposu haline getirilebilir. her git dosya deposunda .git isimli bir alt klasör vardır ve kullanıcının o depo-klasördeki ve onun alt klasörlerindeki dosyalarının güncel sürümlerinin ve gelişim sürecindeki tüm eski sürümlerinin yerel kopyaları o .git klasöründe saklanır.
  3- depodaki kararlı gövde dosya kümesine master denir, bu kümeden adını kullanıcının kendi belirleyeceği geçici dal kümeler branch kumandası ile oluşturulabilir. kullanıcı, geliştirmek istediği kümeyi geri getirip (checkout), dosyalar üzerinde değişiklikler yapıp, bunları depolayarak çalışır. üzerinde çalışılan kümeye head denir.
  4- dağıtıklık gereği bu yerel depolar ve kümeleri arasında yerel depolamalar yüzünden farklar oluşur ve ayni depodaki dal kümeler arası eşitleme alış verişleri gerçekleştirilebilir (merge, rebase). bu farklar bağımsız depolar arasında güven temelli teslimat (pull request) olarak talep edilip veya sunulup kabul veya red edilebilirler, ya da uzaktaki bir merkezi ana depodaki (origin) kümelerle güncelleme / senkronizasyon gerçekleştirilebilir (fetch, remote add, pull, push), ya da oradan gelen yama uygulanabilir (am kumandası).
  5- git uygulaması kümelerindeki dosyalar arasında değişenleri ( modified denenler), otomatik algılayabilir. git'in takip ettiği dosyalar vardır (tracked), hala sürüm kontrolü altında olmayan başka dosyalar vardır (untracked). dosyalar ekleme komutu add ile takibe alınabilir, mv ile klasörler arasında taşınabilir, rm ile silinebilirler. bazı dosyaları git'in umursamaması gerekir, bunların adları .gitignore dosyasına yazılır. değiştirilen dosyalar add ile depolanmaya hazır gruba eklenir (staged), commit ile o andaki halleri açıklama mesajı ekli bir şekilde depolanır, depolanmaya hazır olmayan değişiklikler save ve stash ile kenara konulup, daha sonra, belki başka kümede kullanılabilir (pop, drop, apply, clear), clean ile silinebilir. klasörlerdeki metinler grep ile arattırılabilir.
  6- sürümler commit işlemi sırasında üretilmiş uzun hash sayısının ilk 6-7 rakamı ile tanınabilir. dosyalardaki değişiklikler listelenebilir (status, log, reflog), görüntülenebilir (diff), vaz geçip bir evvelki haline dönülebilir (undo), baştan alınabilir (reset), bir evvelki sürümüne dönülebilir (revert), yazarı belirtilebilir (blame), her hangi bir dosyanın depodaki herhangi bir sürümü tekrar getirilebilir (checkout), bir kümenin belli hallerine isim verilebilir (tag).
  
  08.12.2021 sürümüne edit: bu uzun ve çetrefil kumandalar kümesi korkutabilir, etmesin. tipik yazma süreci az sayıda kumandayı tekrar tekrar ama duruma uygun bilgilerle kullanarak sürdürülür. yazılanın son hali ortadadır, yoksa depodan getirtirsin (checkout), yazacaklarını yazarsın, hangi yeni yazdıklarını depolayacaksan onları belirtirsin (add), son ek veya değişikliklerin içeriğini özetleyen bir mesajla kaydedersin (commit). normal olan bu kadardır. internet'te tonla git'e giriş yazıları/videoları vardır, onlar genellikle bu üçünü ve özel dışı durumlarda gereken kumandaların en sık rastlananlarını anlatırlar. genellikle bu kadarı uzun süre yeter, diğerleri gerektikçe aranır, öğrenilir, hatırlanması gereken kumandalar dağarcığına eklenir.