Git #2: GİT İŞ AKIŞI, TEMEL KAVRAMLAR ve İLK PROJE

Bir önceki Git #1: GİT’E GİRİŞ yazımızda Git hakkında detaylı bilgiler vermiş, Git’i bilgisayarımıza kurmuş ve temel ayarlarımızı yapmıştık. Bu yazımızda ise Git’in teknik anlamda nasıl çalıştığına, iş akışının ne olduğuna, Git’in temel kavramlarına değinecek; ardından da Git ile entegre şekilde çalışacak ilk projemizi başlatacak, Git dünyasına resmen giriş yapmış olacağız. Heyecanlandığınızı biliyorum. O zaman hadi, başlayalım:

GİT İŞ AKIŞI

Git, projelerimizin versiyon kontrolünü yaparken bir kaç aşama kullanır. Bu aşamaları adım adım açıklamak yerine gelin, basit bir senaryo üzerinden konuyu kavramaya çalışalım:

1. Projenizi Git ile çalışacak hâle getirirsiniz. Bunun için;
   1. Ya çalışma klasörünüzü Git ile çalışmaya hazır hâle getirirsiniz,
   2. Ya da daha önceden uzak sunucuda Git ile harmanlanmış projeyi bilgisayarınıza indirirsiniz.
2. Ardından dosyalarınızda çalışmaya, gerekli değişiklikleri yapmaya başlarsınız ve değişiklikleriniz belirli bir olgunluğa ulaştığında onları Staging Area denen, Git tarafından dosyaların takibe alınmasını sağlayan alana dahil edersiniz.
3. Daha sonra onları uygun bir açıklamayla Commit altına alarak ilk sürümünüzü oluşturursunuz ve yukarıdaki 2. adıma dönersiniz.

Tabii işler her zaman bu kadar basit olmaz. Başka bir değişle güzelim projeleriniz bu kadar basit aşamalardan geçmez. Eğer işler bu kadar basit olsaydı Git’e gerek kalmazdı. Dosya.txt, Dosya1.txt gibi isimlendirmelerle kendimiz de yapardık tüm bunları, değil mi?

Bazen projelerimiz için farklı özelliklerde geliştirmeler yapmamız gerekir. Bunları, projemizin orjinalini tehlikeye atmadan geliştirmek isteriz. Bu durumda Git iş akışımız biraz değişir. Bunları zamanı geldiğinde işleyeceğiz fakat şunu bilin: Git, her tür projenin sürüm kontrolünü yönetecek iş akışına sahiptir ve bu, onu en çok kullanılan versiyon kontrol sistemi yapar.

Şimdi gelin, Git terminolojisine bir bakalım ve Git terimlerini kafamızda canlandırmaya çalışalım.

TEMEL KAVRAMLAR

Bir projeyi ilk kez git ile çalışmaya hazır hâle getirdiğimizde, proje ne olursa olsun artık onun adı Repository, yani Depodur. Git, projemizdeki dosyaların o anki durumlarını, varsa geçmiş sürümlerini .git ismindeki bir klasörde depolar. Eğer Repo’yu, Repository’ye genelde Repo denir. Projemizi uzak sunucudan indirdiysek de Git aslında .git klasörünü indirir, projenin son halini de klasör ağacı olarak bizler için hazırlar.

Projemizin yeni sürüme ihtiyaç duyduğunu hissettiğimiz anda, ona özel bir açıklamayla sürüm kazandırmaya Commit denir. Commit, projemizin o anki hâlinden bir sürüm yaratır ve bunu yazdığımız açıklamayla etiketler.

İşler çoğu kez bu kadar basit olmaz. Projemize yeni özellikler eklerken, çalışmamızın son hâli bozulmasın diye onu farklı bir dalda geliştirmemiz gerekir. Projemizdeki her bir dala Branch, dalların birleştirilmesi işlemine de Merge denir. Git teknolojisinde, projemizi ilk kez oluşturduğumuzda bir adet ana dal oluşturulur. Bu dala kimi yerlerde Main, kimi yerlerde Master adı verilmiştir. Burada önemli olan, Git’in en az bir dal üzerinde çalışması gerektiğidir.

Git, projelerimizi üç katmanda ele alır:

1. Working Tree (Çalışma Ağacı): Projemizde çalıştığımız, üzerinde değişiklikler yaptığımız dosya sistemidir. Buna ana klasörümüz diyebiliriz.
2. Staging Area (Hazırlık Alanı): Bu, üzerinde değişiklik yaptığımız dosyaları Git’e göndermeye hazırladığımız alandır. Bu alan dosyaların veri tabanına yazılmadan önceki son aşamasıdır ve bu aşamada Git, dosyalarda herhangi bir çakışma (Dif) olup olmadığına bakar. Bu alan ayrıca hangi dosyaların sürüm yedeğine alınıp alınmayacağını da belirlediğimiz alandır. Buraya eklediğimiz dosyalar bir sonraki Tahüt (Commit) işleminde yedeklenecek dosyaları oluşturur.
3. İndex (Dizin): Bu, projemizde sürümler hâlinde tutulan dosyalarımızın bulunduğu alandır. Bu alanda yer alan dosyalar dosya halinden ziyade, Snapshot (anlık görüntü) durumundadır ve bu sayede bizler istediğimiz sürüme kolaylıkla geri dönebiliriz.

Temel kavramlar konusunda söylenebilecek sözleri söylediğimize göre artık Git’i kullanmaya başlayabiliriz. Dilerseniz yukarıda yaptığımız tatavayı artık uygulamaya başlayalım. Artık teoriden kurtulup işleri pratiğe dökelim.

Bu aşamadan itibaren sizlerle basit bir Web sitesi tasarlayacağız. Tasarladığımız bu site birden çok sayfalı olacak ve bu tasarımımızı Git ile yönetip, gerekli değişiklikleri uygulayacağız. Hiçbir şekilde CSS ya da Javascript kullanmadan, sadece iskelet şeklinde HTML kullanarak basit sayfalar oluşturacağız. Bütün bu yazı dizisinin sonunda, tıpkı borfirbora.com sitesinde yaptığım gibi Github’ı kullanarak sitemizi herkese açık hâle getirip yayımlayacağız.

İLK PROJE

İstediğiniz herhangi bir dizinde boş bir klasör oluşturarak başlayalım işlerimize. Fakat klasör adında herhangi bir Türkçe karakter kullanmayalım. Sizler de dilerseniz klasör ve dosya isimlendirmelerinizi benimkilerle aynı olacak şekilde belirleyin ki beraber ilerleyebilelim.

Ben klasörümü D: dizininde oluşturdum ve adına git-projesi dedim. Git ile projesi kelimelerinin arasına normal kısa çizgi (-) koyduğuma dikkat edin. Tabii bu benim tercihim. İsterseniz alt çizgi (_) de koyabilirsiniz fakat ben genelde böyle çalışıyorum.

Klasörümüzün içerisine girdikten sonra bir adet index.html dosyası oluşturalım. Şimdilik içi boş kalsın. Ardından klasörümüzün içerisindeyken F4 tuşuna basarak adres kısmına gidelim. CTRL+A ile tüm metni seçip delete tuşu ile içeriği silelim ve hemen oraya cmd yazalım. Enter tuşuna bastığımda gelen CMD ekranım şöyle:

Microsoft Windows [Version 10.0.19042.1415]
(c) Microsoft Corporation. Tüm hakları saklıdır.

D:\git-projesi>

Şu anda proje klasörümüzde bir CMD penceresi açtık ve artık projemizde geçerli olacak kodları yazmaya başlayabiliriz.

git init

yapmamız gereken ilk şey, projemizi Git ile çalışmaya hazırlamak. bunun için git init komutu ile projemizi Git tarafından işlenebilir hâle getirmemiz gerekiyor. Kodu çalıştırdığımda ekranımda şu oluştu:

git init
Initialized empty Git repository in D:/git-projesi/.git/

Bizlere verilen uyarıda boş bir Git veri tabanı oluşturulduğu anlatılıyor. Artık, projemizle ilgili kodları yazmaya başlayabiliriz.

git add

İkinci adımda ise, Git tarafından işlenecek dosya ya da klasörleri belirtmemiz gerekiyor. Neden böyle bir uygulama yaptığımıza gelirsek de, bazı dosya ya da klasörlerimizin sürüm altına alınmasını istemiyor olabiliriz. Bu durumda Git tarafından takibe alınmamasını istediğimiz dosyalar var demektir.

Talebimizi Git’e iki farklı yolla bildirebiliriz:

1. Projemizin ana klasöründe .gitignore isminde bir dosya oluşturabilir ve bunun içine satır satır işlenmesini istemediğimiz klasör ya da dosyaları yazabiliriz.
2. Aşağıda detayını öğreneceğimiz git add komutunu her bir dosya için tek tek çalıştırabilir ve eklemek istemediğimiz dosyaları bu işin dışında tutabiliriz.

Tabii ki çok büyük bir çoğunluk birinci yöntemi kullanıyor. Fakat önce, dosyalarımızı dizine, Git tarafından izlenen Staging Area alanına, eklemek için git add komutunu öğrenmemiz gerek.

git add komutunun en çok kullanılan komut olduğunu bilmelisiniz. Bu komut, Git veri tabanına eklenmek üzere dosyalarımızı izlemeye almamıza yarar. Komutumuzun temelde iki kullanım senaryosu bulunur:

1. git add <dosya_adı.uzanti> şeklinde kullanırsak, belirttiğimiz dosyalar Staging Area’ya eklenmiş olur.
2. git add . şeklinde kullanırsak da projedeki tüm dosya ya da dizinler Staging Area’ya eklenmiş olur. Eğer projenizin ana dizininde .gitignore dosyası varsa, git add . komutu orada yazan dosya ya da klasörleri dışarıda bırakır, yani onları Staging Area’ya eklemez.

Gelin, projemizdeki index.html dosyasını Staging Area’ya ekleyecek komutumuzu girelim. Dilersek burada git add index.html komutunu kullanalım ve sonucu görelim:

git add index.html

Neden konsolumuzda herhangi bir çıktı almadık? Çünkü biz basitçe dosya ekledik. Projemizin sahip olduğu dosyalar ve durumları hakkında bilgi almak için başka bir komut öğrenmemiz gerek. Unutmayın, her komut Git’te basitçe kendi işini yapar.

git status

Dosyalarımızın eklenip eklenmediğini ya da durumlarının ne olduğunu öğrenmek için bu komuda başvuracağız. Bu komut, hangi dosyalarda nasıl değişiklik yapıldığı hakkında basit bilgiler verir.

Gelin, çalıştıralım ve sonucunu görelim:

git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   index.html

Git bize açıklamalarında bile neler yapacağını söylüyor aslında. Gelin, yukarıdaki çıktıyı türkçeleştirip neler olduğuna bakalım:

Master dalındasınız

Henüz Commit yok

Commit edilecek değişiklikler:

(stage’i kaldırmak için “git rm –cached …” kullanın)

yeni dosya: index.html

Öncelikle çıktımızda hangi dalda olduğumuz bilgisi veriliyor. Ardından da Commit olup olmadığı hakkında bilgi geçiliyor. En son bölümde de, bir sonraki Commit işleminde hangi dosyaların işlem göreceğini ve dosyaların o anki durumunu bizlere veriyor.

Dikkat: Dosya bilgileri verilmeden önce, git rm --cached <file> komutuyla dosyaları eklediğimiz Staging Area alanından çıkarabileceğimiz de bizlere hatırlatılıyor.

Şimdi sizlerle bir deneme yapacağız. Nasıl olsa index.html dosyasını izleme alanına eklemiştik. Şu anda o dosyanın içeriğini biraz dolduralım. Bakalım git status komutu bizlere nasıl bir bilgi verecek.

Şimdi, aşağıdaki kodu kopyalayıp index.html dosyamızın içine yapıştırıp kaydedelim.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Git Projesi</title>
</head>
<body>
    <h1>Git projesi sayfasına hoşgeldiniz!</h1>
</body>
</html>

Şimdi git status komutunu çalıştıralım ve sonucu görelim:

git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   index.html

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   index.html

Şimdi işler biraz değişti. Dosyamız hem İşleme Alanı’nda hem de çalışma alanında gözüküyor. Birine yeni dosya diyor, birine değiştirilmiş…

Bunun nedeni şu: Siz ilk git add index.html dediğinizde Git, dosyanızı İşleme Alanı’na eklemişti fakat o zaman boştu. Şimdi değişiklik yapıp tekrar git add index.html demediğiniz için Git sizi bilgilendiriyor.

Bunun anlamı da şu arkadaşlar:

Siz bir dosyayı eklediğinizde o dosya o anki hâliyle İşleme Alanı’na eklenir. Değişiklik yapıp tekrar onu eklemezseniz, Commit ettiğinizde değişikliğiniz yansımaz ve ilk eklediğiniz haliyle yedeklenir. Bu yüzden git add komutu Git’te en çok kullanılan komuttur, diyoruz.

Şimdi tekrar git add komutunu kullanalım ve git status komutuyla sonucu görelim:

git add index.html

git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   index.html

Gördüğünüz gibi dosyamız artık sadece Yeni Dosya olarak gözüküyor. Son olarak git status komutunun -v parametresinden bahsedelim.

Bu parametre, eklenen dosyalarınız hakkında detaylı bir değişiklik bilgisini bizlere verir. Bu komutu git status -v şeklinde kullanın ve sonucu kendi gözlerinizle görün. Ayrıca git diff komutunun ne işe yaradığını da tahmin edin ve araştırın. Bu da bizden basit bir ödev olsun.

git commit

Geldik sürüm kontrolünün sürüm kontrolü olduğu noktaya. git commit komutu, belli olgunluğa ulaşan değişikliklerimizi paketlememize yarayan bir komut. Ayrıca kendisine bir de açıklama girersek, ki açıklama girmek zorunlu, tadından yenmiyor ve ne zaman nasıl bir değişiklik yapmışız bilgisini bizim için tutuyor.

Bu komutun bizler için önemli olan bir parametresi var ki o da -m parametresi. Bu parametreden sonra tırnak içinde açıklamamızı gireceğiz ve bu açıklamayla tüm değişikliklerimiz paketlenecek ve sürüm altına alınmış olacak.

Gelin aşağıdaki kodu çalıştıralım ve sonucu görelim:

git commit -m "HTML iskeleti oluşturuldu"
[master (root-commit) 5ccf5c6] HTML iskeleti oluşturuldu
 1 file changed, 12 insertions(+)
 create mode 100644 index.html

Yukarıdaki çıktıda da görüldüğü gibi, o anki sürümümüz paketlendi ve açıklaması olan HTML iskeleti oluşturuldu ile etiketlendi.

Dikkat: git commit komutunu -m parametresiz kullanırsanız önünüze varsayılan metin düzenleme uygulamanız açılır ve detaylı açıklama girmeniz beklenir. # işaretiyle başlayan satırlar görmezden gelinir ve açıklamaya dahil edilmez. Büyük projelerde detaylı açıklama girmek ve yapılan değişiklikleri detaylandırmak elzemdir ve çoğu kez, projelerin Commit kuralları vardır.

Şu andan itibaren dosyalarımızı düzenlemeye devam edebilir, dosyalarımızı tekrar Staging Area’ya ekleyebilir ve Commit ederek değişikliklerimizi paketleyebiliriz.

Bu yazımızda bahsedeceklerimiz bitti. Bir sonraki yazımızda Git’te dallanmaları ve etiketlemeleri göreceğiz. Şimdilik projenizi kendi başınıza geliştirmeye bakın. Bir sonraki yazımızda görüşmek üzere, şimdilik hoşça kalın.