Bir yazılımcının günlük olarak sürekli kullandığı en önemli araçlardan bir tanesi versiyon kontrol sistemleridir. Versiyon kontrol sistemi; bir projenin dizin ve dosyalarını, bu dosyaların değiştirilme kayıtlarını ve farklı versiyonlarını takip eden sistemlerdir. En çok kullanılan versiyon kontrol sistemlerini Git, Subversion, Mercurial olarak sıralayabiliriz. Bu yazımızda bunlar arasında en popüler versiyon kontrol sistemi olan git’i kullanarak bir temel oluşturacağız. İleriki yazılarımızda ileri versiyon kontrol uygulamalarına ve git’in arkaplanda nasıl çalıştığına değinen yazılar paylaşacağız.
Git Kurulumu
Mac ve Linux sistemlerde git zaten kurulu ve terminal’den kullanılabilir bir şekilde bulunuyor olacaktır. Daha güncel bir versiyon için paket yöneticinizden (package manager – Mac için homebrew, Ubuntu için apt vs.) kullanmanızı öneriyoruz. Windows sistemler içinse git sayfasından kurulum dosyasını indirebilirsiniz.
Önemli not: Kurulum yaptıktan sonra sisteminiz PATH ortam değişkenine git’in çalıştırılabilir dosyasının olduğu dizini ekleyerek, terminalden git uygulamasına erişim olduğundan emin olun.
Git için GitHub Desktop, SourceTree gibi pek çok grafik arayüzü mevcuttur. Bu uygulamalar da aynı git komutlarını çalıştırmakta, yalnızca daha görsel bir etkileşim sağlamaktadır. Git’i daha iyi anlamak, tüm özelliklerini daha esnek ve daha etkili kullanmak adına terminalden kullanmanızı tavsiye ediyoruz.
Git Temelleri
Git’i basit olarak dosyaların ve bu dosyaların geçmiş tüm versiyonlarının saklandığı bir veritabanı olarak görebiliriz. Git için en temel nokta dosyalarda yalnızca yapılan değişikliklerin değil, dosyaların tamamının bir bütün halinde (snapshot) kaydediliyor olmasıdır. Bu veritabanına git terminolojisinde “repository” ismi verilmektedir. Proje dosyalarımızı git ile takip etmeye başlamak için öncelikle dosyalarımızın bulunduğu kök dizine gidilerek bir repository oluşturulmalıdır. Repository oluşturmak için terminalinizde ilgili dizine giderek git init komutunu çalıştırın.
cd /proje/dizinim
git initBu komutu çalıştırdığınızda proje dizininde .git adında bir dizin oluşturulduğunu fark edeceksiniz. Bu dizinde dosyalarınız ve dizinlerinizin tüm versiyonları ve repository’nize ait çeşitli bilgilerin bulunduğu dizin ve ve dosyalar göreceksiniz. Bunların ne anlama geldiğinden ve ne şekilde tutulduğundan ileriki yazılarımızda bahsedeceğiz.
Proje dizinimizde .git dizini dışında kalan dosya ve dizinlere working directory veya working tree denmektedir. Şimdi hello.txt isimli bir dosya oluşturup içerisine birşeyler yazalım. Çalışma ağacımızın durumuna bakmak içinse git status komutunu çalıştıralım.
Bu komut bize hello.txt isminde, henüz git tarafından takip edilmeyen bir dosya bulunduğunu söyleyecektir. Bunun nedeni çalışma ağacımızda bu dosyanın bulunup git veritabanında bu dosyaya ait kayıt olmamasıdır. Git’in bu dosyayı takip etmesi için bize önerdiği gibi git add komutunu kullanalım ve çalışma ağacımızın durumuna tekrardan bakalım.
Artık dosyamızın git tarafından takip edileceğini, git veritabanına yeni dosya olarak ekleneceğini görmüş olduk. Fakat henüz şu an veritabanımıza bu değişiklik yapılmadı. Fakat bu değişiklik veritabanına yazılmak için bekleme durumunda. Bu işleme staging denmektedir. Bir başka daha dosya ekleyerek onu da git add komutu ile daha sonra veritabanına yazılmak üzere ekleyelim.
Bu şekilde değişiklerimizi toplu bir şekilde gerçekleştirebiliyor olacağız. Sıra geldi bu değişikliklerin veritabanına gerçekten yazılması aşamasına. Bunun için git commit komutu kullanılır. Burada -m parametresi ile bir commit mesajı yazılır. Eğer bu parametre ile verilmezse mesajı yazabileceğiniz bir alan açılacaktır.
Böylece iki dosyanın veritabanına eklenmiş olduğunu gördük. şimdi ise bu dosyalardan birinde değişiklik yapalım. Sonrasında ise bu değişikliği commit edelim.
Yaptığımız değişikliği modified olarak görebiliyoruz. Commit ettiğimizde ise 1 dosyanın değiştirildiğini görebiliyoruz. Yaptığımız değişikliklerin listesini görüntülemek için git log komutu kullanılabilir.
Burada commit kimliklerini (commit hash), mesajlarımızı ve yapan kişiyi görebiliyoruz. Her commit (ilk commit hariç) kendinden önceki commit’e bağlıdır. Bu şekilde commit geçmişine ulaşılır.
Git Dalları (Git Branches)
Git dalları (git branches), aslında bizim için kritik ve sürekli takip ettiğimiz commit‘lere verdiğimiz anlamlı etiketlerden başka bir şey değildir. Yaygın bir şekilde uygulamaların test, canlı, geliştirme (test, production, development) dalları şeklinde organize olduğunu görebiliriz. Bir önceki ekran görüntümüzde HEAD -> master ifadesine dikkat edelim. Burada master, repository oluşturulduğunda git tarafından otomatik olarak oluşturulmuş bir daldır. HEAD ise mevcut çalışma ağacındaki aktif commit‘i ve/veya dalı temsil eder. Gelin demo adında yeni bir dal oluşturalım.
git branch komutu ile dallar listelenebilir, yeni dal oluşturulabilir, mevcut dal isimleri değiştirilebilir veya dallar silinebilir. Şu anki çalışma alanını başka bir dal veya commit ile değiştirmek için git checkout komutu kullanılır. Burada dal adı kullanılabileceği gibi istenilen commit‘in numarası girilerek o commit‘e dönülebilir.
Sonrasında git log komutu çalıştırıldığında demo ve master dallarının olduğunu ve HEAD‘in ise demo dalını gösterdiğini görebiliyoruz. Bu dalda iken değişiklik yapalım ve neler olduğunu inceleyelim.
Demo dalının bir commit ileride olduğunu görebiliyoruz. Şimdi master dalından devam edip uygulamamızı geliştirmeye devam ettiğimizi düşünelim. Sonrasında git log komutunu kullanarak projemizin durumuna bakalım. Burada git log komutunun çıktısını daha anlaşılır yapmak ve bütün dalları kapsaması için –graph –all –oneline parametrelerini kullandık.
Burada demo dalının ana daldan ayrıldığını görebiliyoruz. “Second commit” mesajlı commit bir iki dalın ortak bir ataya sahip ilk commit. Demo için yaptığımız değişiklikleri ana dalda birleştirmek için (merge) git merge komutu kullanılır. Bu noktada ortak olan en güncel commit‘ten itibaren yapılan değişiklikler birleştirilir. Aynı dosyaya eğer farklı dallarda müdahale edilmişse çakışmalar (merge conflict) olabilir. Bu durumda el ile müdahale edilerek dosya olması gereken haline getirilir. Bunun inceliklerine ilerleyen yazılarımızda değineceğiz. Şimdi ana dalımızı demo dalımız ile birleştirelim.
Böylece demo‘da yaptığımız değişiklikler (demo.txt dosyası) ana dalımıza da taşınmış oldu. Merge komutu sonucu yeni bir merge commit‘i oluşur. Bunun için de bir commit mesajı yazmamız gerekiyor.
Böylece git ve versiyon kontrol konularında temel operasyonlara bakmış olduk. İleri seviye işlemler, çakışmaların çözümü, git’in arkaplanda nasıl çalıştığı ve hatta nasıl kendi git benzeri versiyon kontrol uygulamamızı veya git arayüzümüzü geliştirebileceğimize ileriki yazılarımızda değişeceğiz. Şimdilik görüşmek üzere.
