İngilizce Metin: https://o-date.github.io/draft/book/github-version-control.html

🔧 Basit bir not defteri başlatmak

Bu tanıdık bir durum – bir makale üzerinde çalışıyorsunuz. Olmasını istediğiniz yere geldi ve bitirdiğinizden eminsiniz. ‘final.doc’ olarak kaydediyorsunuz. Sonra arkadaşınızdan bir göz atmasını istiyorsunuz. Arkadaşınız birkaç yazım hatası ve bir paragrafın tamamını atladığınızı fark ediyor. Sonra dosyayı açıyorsunuz, değişiklikleri yapıyorsunuz ve ‘final-w-changes.doc’ olarak kaydediyorsunuz. Günün ilerleyen saatlerinde bu değişiklikleri beğenmediğinizi fark ediyorsunuz ve orijinal ‘final.doc’ dosyasına geri dönüp bazı değişiklikler yapıyor ve önceki versiyonun üzerine yazıyorsunuz. Kısa süre sonra şöyle bir klasörünüz oluyor:

|-project
    |-'finalfinal.doc'
    |-'final-w-changes.doc'
    |-'final-w-changes2.doc'
    |-'isthisone-changes.doc'
    |-'this.doc'

İşler oldukça hızlı bir şekilde karışabilir. Ayrıca içinde birkaç e-tablonuzun, resimlerinizin, kod parçacıklarınızın da olduğunu düşünün… bunu istemiyoruz. İstediğimiz şey, dosyalarınızın gelişimini yönetmenin bir yoludur. Bunu Git adlı bir programla yapıyoruz. Git kullanıcı dostu bir yazılım değil ve alışmak için biraz çalışmak gerekiyor. Git aynı zamanda çok güçlüdür, ancak neyse ki, çoğumuzun onu kullandığı temel kullanımlar aşağı yukarı basittir. Sürüm kontrolü için Git’ten yararlanan birçok başka program vardır; bu programlar ana Git programının üzerine grafiksel bir kullanıcı arayüzü kaynak yapar. Ancak bu yardımcı programların kendine has özelliklerini öğrenmeden önce git’in temel kullanımlarına komut satırından aşina olmak daha iyidir. Bu bölümdeki alıştırmalar size Git’i komut satırından kullanmanın temellerini gösterecektir.

1.3.1 Git’in Temel İşlevleri

Git, özünde bir klasörün mevcut durumunun ‘anlık görüntülerini’ [ah]almanın ve bu anlık görüntüleri veya sürümleri sırayla kaydetmenin bir yoludur. Git hakkında mükemmel bir kısa sunum için Alice Bartlett’in sunumuna buradan bakabilirsiniz. Git’in dilinde, bilgisayarınızdaki bir klasör repository olarak bilinir. Toplamda bu sürüm dizisi, projenizin zaman içinde nasıl geliştiğini görmenizi sağlar. Her sürüm almak istediğinizde bir commitişlemi yaparsınız. Commit, tüm deponun anlık görüntüsünü almak için kullanılan bir Git komutudur. Böylece, yukarıda bahsettiğimiz klasörünüz, belgelerin çoğalmasıyla birlikte:

|-project
    |-'final.doc'

ANCAK işlem geçmişi şu şekilde görselleştirilebilir:

İşlemlerin geçmişinin görselleştirilmesi

 Bu dairelerin her biri, yazar olarak sizin bir commit yaptığınız bir zaman noktasını temsil eder; Git dosyanın durumunu önceki durumla karşılaştırır ve differences (farklılıkların) anlık görüntüsünü kaydeder. Bir commit yapmanın özellikle yararlı olan yanı, Git’in git hakkında iki bilgi daha gerektirmesidir: kimin yaptığı ve ne zaman yaptığı. Bir commit ile ilgili son yararlı kısım, commit’in neden yapıldığına dair ayrıntılı bir mesaj kaydedebilmenizdir. Varsayımsal durumumuzda, ilk commit mesajınız aşağıdaki gibi görünebilir:

Fixed conclusion

Julie pointed out that I had missed

the critical bit in the assignment

regarding stratigraphy.

This was added in the concluding section.

Bu bilgiler işlemlerin geçmişinde saklanır. Bu şekilde, projenin nasıl ve neden geliştiğini tam olarak görebilirsiniz. Bu işlemlerin her biri hash olarak adlandırılır. Bu, (Bartlett’in ifadesiyle) ‘zaman yolculuğu’ yapmak için kullanabileceğiniz özgün bir parmak izidir. Projenizin birkaç ay önce nasıl göründüğünü görmek istiyorsanız, o commit’i checkout ile kontrol edersiniz. Bu, projeyi ‘geri sarma’ etkisine sahiptir. Bir commit’i kontrol ettikten sonra, klasöre baktığınızda paniğe kapılmayın: klasörünüz (deponuz) tüm o haftalar önce nasılsa öyle görünür! Bu commit’den sonra yazılan tüm dosyalar sanki kaybolmuş gibi görünür. Endişelenmeyin: onlar hala var!

Bu noktadan sonra projenizi yeni bir yönde denemek veya ilerletmek isterseniz ne olur? Git bunu yapmanıza izin verir. Yapacağınız şey, o noktadan itibaren projenizde yeni bir branch oluşturmak olacaktır. Branch’ı (bir dalı) bir ağacın dalları ya da belki de daha iyisi, sonunda kaynağa geri dönen bir nehrin kolları gibi düşünebilirsiniz. Branch hakkında düşünmenin bir başka yolu da, bu belirli commitlere yapışan bir etiket olmasıdır. Projenizin en iyi sürümünü temsil etmesi açısından master branch (ana dalı) yalnız bırakmak genellikle ‘en iyi uygulama’ olarak kabul edilir. Yeni bir şey denemek ya da yapmak istediğinizde, bir başka branch (dal) oluşturur ve orada çalışırsınız. Eğer branch üzerindeki çalışma nihayetinde sonuçsuz kalırsa, onu atabilirsiniz. Ancak,gidişatı beğendiğinize karar verirseniz, bu branch’ı master branch ile merge edebilir yani birleştirebilirsiniz. Merge komutu, branch üzerindeki tüm işlemleri master branch’daki commit’lerle birleştiren bir işlemdir.

Git aynı zamanda çalışmalarınızı yedeklemek için de güçlü bir araçtır. Git ile kendi makinenizde oldukça mutlu bir şekilde çalışabilirsiniz, ancak bu dosyaları ve işlem geçmişini uzak bir yerde sakladığınızda, işbirliği olasılığını ve bilgisayarınıza bir şey olması durumunda malzemelerinizin geri çağrılabileceği güvenli bir yer açarsınız. Git dilinde (Git-speak) uzak konum, remote olarak adlandırılır. Web üzerinde Git depoları için uzaktan kumanda (kontrol) işlevi görebilecek birçok farklı yer vardır. İsterseniz kendi sunucunuzda bile bir tane kurabilirsiniz. En popüler olanlardan biri (ve ODATE için kullandığımız) Github’dır. Github üzerinden paylaşılan ve arkeologların ilgisini çeken pek çok faydalı depo var – örneğin OpenContext bu yolla pek çok materyal paylaşıyor. Materyali Github’dan çıkarıp kendi bilgisayarınıza almak için clone kullanabilirsiniz. Yazdığınız varsayımsal makale bir grup projesinin parçasıysa, ortaklarınız onu Github alanınızdan klonlayabilir (ing. clone) ve üzerinde çalışabilir!

Sen ve Anna proje üzerinde birlikte çalışıyorsunuz. Github alanınızda yeni bir proje deposu oluşturdunuz ve bunu bilgisayarına klonladın. Anna onu kendisininkine klonladı. Çok verimli bir hafta sonu geçirdiğini ve projede gerçek bir ilerleme kaydettiğini varsayalım. Değişikliklerini commit ederek işlersin ve ardından bunları bilgisayarından deponun Github sürümüne push ederek gönderirsin. Bu depo artık Anna’nın sürümünün bir adım önünde. Anna bu değişiklikleri Github’dan deponun kendi sürümüne pulls ile çeker ve bu sürüm artık tam olarak sizin sürümünüz gibi görünür. Aynı dosyanın tam olarak aynı bölümünde değişiklik yaparsanız ne olur? Buna conflict denir ve çakışma olur. Git, dosyanın çakışmanın meydana geldiği kısmını açıkça işaretleyen bir metin içeren ve çakışan bilgilerin de işaretlendiği bir sürümünü oluşturacaktır. Çakışmayı çözmek resolve ile dosyayı açmak (genellikle bir metin düzenleyici ile) ve eklenen Git metnini silmek, hangi bilginin doğru bilgi olduğuna karar vermektir.

1.3.2 Anahtar Terimler

Repository (Depo): Git ortamında projenizin tüm dosyalarını ve alt klasörlerini tutan tek bir klasör. Ancak “repository” dijital veri arşivi olarak da kullanılmaktadır. 

Commit: Bu, ‘depomun mevcut durumunun anlık görüntüsünü al’ anlamına gelir

Publish (Yayınla): Bilgisayarımdaki klasörümü al ve onu ve içeriğini github.com/myusername/repositoryname adresinde bir depo olarak web’e kopyala

Sync: Web deposunu yerel klasörümdeki en son commit ile güncelle

Branch (Dal): Depomun bir kopyasını ‘çalışma adı’ ile oluştur

Merge (Birleştir): Bir dalda yaptığım değişiklikleri başka bir dala birleştir

Fork (Çatallamak): Başka birinin deposunun bir kopyasını oluşturmak

Clone (Klonlamak): Çevrimiçi bir depoyu kendi bilgisayarınıza kopyalamak

Pull request: Bir deponun orijinal yapımcısından değişikliklerinizi ana, orjinal  arşivlerine ‘çekmesini’ istemek

Conflict (Çakışma): İki commit işleminin bir dosyanın aynı bölümünde farklı değişiklikleri tanımlaması

1.3.3 Çıkarımlar

Git, commit komutuyla klasörünüzün (deponuzun) durumunun ‘anlık görüntüsünü’ aldığınızda dosyalarınızdaki tüm farklılıkların kaydını tutar

Git değişiklikleri geri almanıza izin verir

Git, istediğiniz gibi silebileceğiniz veya dahil edebileceğiniz değişiklikler yaparak denemeler yapmanıza olanak tanır

Git, işbirliğini güvenli bir şekilde yönetmenizi sağlar

Git, materyallerinizi dağıtmanıza olanak tanır

1.3.4 İleri Okuma

Yukarıda Git’i tam potansiyeliyle kullanmayı kolaylaştırmak için tasarlanmış ‘yardımcı’ programların varlığından bahsettik. Github’ın masaüstü GUI’sine mükemmel bir giriş için Github hakkındaki Programming Historian lesson on Github dersine bakabilirsiniz. Bir sonraki ders, Github’ın kendisinin tüm web sitelerini barındırmak için nasıl kullanılabileceğini açıklıyor! Buradan inceleyebilirsiniz. Bu bölümün açık not defterleri ile ilgili kısmında, araştırma projeleriniz için basit bir açık not defteri oluşturmak için Git ve Github’ı da kullanacağız.

Ayrıca, NEH tarafından finanse edilen Dijital Arkeoloji Yöntem ve Uygulama Enstitüsü’nün (Institute on Digital Archaeology Method and Practice) 2015) ilk gününde Prof. Ethan Watrall’ın proje yönetiminin temellerini tartıştığı ve yayının son bölümüne doğru Git’i tanıttığı arşivlenmiş canlı yayına da bu bağlantıdan göz atmak isteyebilirsiniz.

1.3.5 Alıştırmalar

ODATE Binder‘ın bir kopyasını alın. Readme (Benioku) bölümünü dikkatlice inceleyin, böylece çalıştırılabilir sürümün kendi sürümünüzü oluşturabilirsiniz. Bunu yaptıktan sonra, Binder’ı başlatın. Başlatılması beş ya da altı dakika sürebilir; sabırlı olun.

Başladıktan sonra, new yani yeni açılır menüye tıklayın ve kayıt yerini seçin.

1. Jupyter notebook bir github deposundan sunulduğu için, git programı zaten arka planda çalışır ve değişiklikleri takip eder. Kendi makinenizde çalışıyorsanız (ve git yüklüyse), Git’e klasörü izlemeye başlamasını, klasörün içindeki komut istemine git inityazarak, söyleyip herhangi bir klasörü bir depoya dönüştürebilirsiniz.

Periyodik olarak, Git’e ‘git commit’ komutunu kullanarak klasördeki dosyaların durumunun anlık görüntüsünü almasını söyleriz. Deponuzdaki bu değişiklik dizisi gizli bir dizin olan .git’te saklanır. Çoğu zaman, bu klasörü aramak için hiçbir nedeniniz olmayacaktır. (Ancak deponuzu tanımlayan yapılandırma dosyasının bu klasörde olduğunu bilin. Gelecekte git programının varsayılan davranışlarından bazılarını değiştirmek isteyeceğiniz bir zaman gelebilir. Bunu, bir metin düzenleyici ile okuyabileceğiniz yapılandırma dosyasını açarak yaparsınız. Zamanı geldiğinde işletim sisteminiz için Google’a ‘gizli dosya ve klasörleri göster’ yazın).

2. Yeni bir dosya oluşturalım; bunu new yani yeni olan açılır menüden istediğimiz dosya türünü seçerek yapabiliriz. “Text file” yani ‘Metin dosyası’nı seçin. Jupyter metin editörünü açacak ve sizin için  untitled.txt adında yeni bir dosya oluşturacaktır. Exercise1.md yani Alıştırma1.md olarak değiştirmek için isme tıklayın. İçine bazı bilgiler eklemek için düzenleyiciye yazın – belki ne yapmaya çalıştığınızla ilgili bir not – ardından save yani kaydet’e basın. Oturumu kapatma tuşuna (logout) basmayın.

a) Jupyter ana ekranından new tuşuna basın ve  kayıt yerini seçin. Komut isteminde $ git status yazın

b) Git birkaç bilgi ile yanıt verecektir. Size hangi branch ‘da olduğunuzu söyleyecektir. Mevcut izlenmemiş dosyaları veya aşamalandırılmamış (unstaged) yeni değişiklikleri listeleyecektir. Şimdi bu değişiklikleri $ git add -A. yazarak commit geçmişimize eklenecek şekilde aşamalandıracağız (stage) (-A yazan kısım, commit yaptığınızda yeni, değiştirilmiş veya silinmiş dosyaları commit’inize ekler. Sadece yeni ve değiştirilmiş dosyaları veya sadece değiştirilmiş ve silinmiş dosyaları ekleyebileceğiniz başka seçenekler veya etiketler de vardır).

c) Git durumumuzu tekrar kontrol edelim: $ git status yazın

d) Şuna benzer bir şey görmelisiniz:

On branch master
Initial commit
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   exercise1.md```

e) Bir anlık görüntü alalım: $ git commit -m "My first commit"yazın. Pek bir şey olmamış gibi görünüyor; yeni bir  $ görüntüleniyor. Bu tür bir ortamda hiçbir haber iyi haber değildir. Sadece bir şeyler ters gittiğinde terminalin bilgi yazdırdığını göreceksiniz. Bazı kullanıcılar için (özellikle bu alıştırmalara Binder ortamımız yerine DHBox üzerinden erişiyorsanız) bu noktada bir hata olabilir. Git yalnızca değişiklikleri değil, bunları kimin yaptığını da takip eder. Git sizden adınızı ve e-postanızı isteyebilir. Kullanışlı bir şekilde Git hata mesajı size tam olarak ne yapmanız gerektiğini söyler:  $ git config --global user.email "you\@example.com"yazın ve ardından $ git config --global user.name "Your Name" yazın. Şimdi ilk işleminizi (commit) yapmayı deneyin.

Tebrikler, artık değişikliklerinizi takip edebilir ve materyallerinizi sürüm kontrolü altında tutabilirsiniz!

3. Devam edin ve deponuzda biraz daha değişiklik yapın. Bazı yeni dosyalar ekleyin. Her yeni dosya oluşturulduktan sonra değişikliklerinizi commit edin. Şimdi commitlerinizin geçmişini görüntüleyeceğiz. $ git logyazın. Bu değişiklik listesi hakkında ne fark ettiniz? Zaman damgalarına bakın. Girdilerin ters kronolojik sırada listelendiğini göreceksiniz. Her girdinin kendi ‘hash’i veya özgün kimliği vardır, İşlemi yapan kişi ve zamanın yanı sıra işlem mesajı da listelenir, örn.

commit 253506bc23070753c123accbe7c495af0e8b5a43 Author: Shawn Graham <This email address is being protected from spambots. You need JavaScript enabled to view it.> Date: Tue Feb 14 18:42:31 2017 +0000 Fixed the headings that were broken in the about section of readme.md

a) Zamanda geriye gidip yeni bir branch oluşturacağız. q yazarak git log’dan çıkabilirsiniz. Komut şu şekilde görünecektir: $ git checkout -b branchname <commit> burada branch, yani dalın çağrılmasını istediğiniz ismidir ve <commit> bu özgün ID’dir. Son ikinci işleminizden yeni bir branch oluşturun (< veya > (< or >) kullanmayın).

b) git checkout -b experiment 253506bc23070753c123accbe7c495af0e8b5a43 yazdık. (Komutumuzu kopyalamayın, çünkü bizim versiyonumuz sizin için var olmayan bir commit’e referans içeriyor! git log ile inceleyebileceğiniz kendi commit geçmişinizden bir commit referansı seçin). Yanıt: Yeni bir branch’a geçildi (Switched to a new branch ‘experiment) git durumunu kontrol edin ve ardından deponuzun içeriğini listeleyin.Ne görüyorsunuz? Daha önce oluşturduğunuz bazı dosyaların kaybolmuş gibi göründüğünü fark etmelisiniz – tebrikler, zamanda yolculuk yaptınız!  Bu dosyalar kayıp değil; ancak farklı bir branch’dalar (master branch) ve artık onlara zarar veremezsiniz. Birkaç yeni dosya ekleyin ve her birinden sonra commit yapın. Git durumunuzu kontrol edin ve her şeyi aldığınızdan emin olmak için kendi git log’unuzu kontrol edin. Aşamasız değişiklik olmadığından emin olun – her şey commit’lendi.

4. Şimdi experiment branch’ınızın başarılı olduğunu varsayalım; orada yaptığınız her şeyden memnun kaldınız ve tüm bu değişiklikleri master branch’ınıza geri entegre etmek istiyorsunuz. Bir şeyleri merge ile birleştireceğiz. Merge etmek yani birleştirmek için master branch’a  geri dönmemiz gerekiyor:  $ git checkout master.Tüm önemli denemeler (experiment) veya gittiğiniz yönler için ayrı branch’lar tutmak iyi bir uygulamadır. Oluşturduğunuz branch yani dalların isimlerini unutursanız bu  git branch -va komutu sizin için onları listeleyecektir.

a) Şimdi ($ git merge experiment) git merge denemesi ile birleşiyoruz. Unutmayın, merge yani birleştirme, her iki branch’daki önceki tüm commit’leri bir araya toplayan özel bir commit türüdür – Git, metin düzenleyicinizi açacak ve sizden bir mesaj eklemenizi isteyecektir.(İsterseniz zaten orada sabit (default) bir mesaj olacaktır). Kaydet ve çık ve oldu. Değişiklikleriniz birleştirildi.

5. Git kullanmanın en güçlü yönlerinden biri, işbirliklerini yönetmek için kullanma olasılığıdır. Bunu yapmak için, deponuzun bir kopyasını remoteolarak başkalarının kullanımına sunmamız gerekir.  Web üzerinde bunun yapılabileceği çeşitli yerler vardır; şu anda en popüler olanlardan biri Github‘ dır. Github, bir kullanıcının sınırsız sayıda genel  (public) depoya sahip olmasına izin verir. Genel depolar herkes tarafından görüntülenebilir ve kopyalanabilir. Özel (Private) depolar ücretli bir hesap gerektirir ve erişim kontrol edilir. Bir projede yalnızca ortak çalışanlar arasında paylaşılabilecek hassas materyaller üzerinde çalışıyorsanız, yükseltilmiş bir hesaba yatırım yapmalısınız (hangi dosyaların commit’e dahil edileceğini de kontrol edebileceğinizi unutmayın; bu yardım dosyasına bakın. Temelde, işlenmesini istemediğiniz dosya adlarını listelemeniz yeterlidir; işte bir örnek). Malzemelerinizin hassas olmadığını varsayalım.

a) Şimdi depodaki çalışmanızı Github.com’da yaşayan sürüme aktarıyoruz:

git push -u origin master

NB Bunun yerine bir branch’ı web üzerindeki deponuza göndermek isteseydiniz, bunu nasıl yapacağınızı tahmin edebiliyor musunuz? Branch adı experiment olsaydı, komut şöyle görünürdü: 

$ git push origin experiment

b) Deponuz Github’da web üzerinde olduğundan, depoda doğrudan orada veya yerel bilgisayarınızdan değişiklikler yapmanız mümkündür. Güncellemelerin o anda çalıştığınız yere entegre edilmesini sağlamak için şunları yazabilirsiniz. 

$ git pull origin master

ve sonra çalışmaya başlayın.

1.3.6 Uyarılar

Bu sadece Git ve Github’ın yapabileceklerinin sadece küçük bir kısmıyla ilgilenebilir. Git’in çalışmalarınızın anlık görüntülerini tutan ve sürüm kontrolünü sağlayan bir program olduğunu unutmayın. Github, başkalarının değişikliklere katkıda bulunabilmesi için bu anlık görüntü ve dosya dizisini paylaşmanıza olanak tanıyan bir yerdir. Git hakkında daha fazla bilgi ve DHBox/Linux/Mac için tasarlanmış bazı alıştırmalara buradan ulaşabilirsiniz. Github’daki düzenle düğmesi aracılığıyla dosyalarda doğrudan değişiklik yapmak mümkün olsa da, bunu yaparsanız dikkatli olmalısınız, çünkü işler hızla senkronize olmayabilir ve aynı dosyanın farklı sürümleri arasında çakışmalara neden olabilir. Değişikliklerinizi kendi makinenizde yapma alışkanlığı edinin ve işe başlamadan önce her şeyin işlendiğinden ve güncel olduğundan emin olun (git status, git pull origin master, git fetch upstream arkadaşlarınızdır). Bu noktada, Git için bazı grafik arayüzleri (Github Desktop gibi) araştırmak isteyebilirsiniz. Komut satırında işlerin nasıl yürüdüğünü öğrendikçe, grafik arayüzlerin kendine has özellikleri daha anlamlı hale gelecektir. Git ve Github Desktop’ın giriş ve çıkışları hakkında daha fazla pratik yapmak için Jessica Lord’un Git-it uygulamasını denemenizi öneririz.

Merge Conflicts yani birleştirme çakışmalarını çözme konusunda yardım için Github yardım belgelerine bakın. İş akışının nasıl ilerlemesi gerektiğine dair hızlı bir hatırlatma için Chase Pettit tarafından hazırlanan bu hatırlatma notlarına bakın.