Welcome to My Blog 👋

Java, Spring Framework, Microservices, Docker, Kubernetes, AWS and Others 🚀
Follow Me

Yazılım test edilmesi konusunda dikkat edilmesi gereken en büyük nokta bir test metodunda sadece tek bir senaryonun test edilmesi gerektiğidir. Bu konuda yaşanan en büyük sorun test edeceğimiz senaryonun bağımlılıklarıdır. Örneğin bizim test edeceğimiz senaryo bir dış servisi bağımlı olabilir veya bir veritabanı işlemine bağımlı olabilir. Bizim test senaryomuzu bu bağımlılıkları kullanmadan test etmemiz gerekir. İşte bu nokta mock nesneleri devreye giriyor. Mock nesneleri istenilen bir nesneyi birebir taklit eden nesnelerdir. Örneğin bir veritabanı işlemi yapan nesne yerine mock nesnesi kullanabiliriz ve o işlemden beklediğimiz cevabı mock nesnesi ile koda verebiliriz. Bu şekilde her test metodumuzda ilgilendiğimiz senaryoya odaklanabiliriz. Ayrıca gerçek işlemler çok uzun sürebilir. Örneğin bir veritabanı işlemi çok uzun sürebilir. Onlarca yüzlerce testimizin olduğunu düşünürsek yazılımı her test ettiğimizde ciddi süreler beklemek zorunda kalabiliriz. Mock nesneleri işlemleri gerçekten gerçekleştirmediği için çok hızlıdır. Bu şekilde yazılımımızı çok hızlı bir şekilde test edebiliriz.

  • Mock nesnesi istenilen gerçek bir nesneyi birebir taklit edebilir
  • Mock nesnesinin istediğimiz gibi davranmasını sağlayabiliriz


Java'da bir çok mock kütüphanesi vardır. Bunlardan bazıları;


  • Mockito
  • JMock
  • PowerMock


Suite
JUnit framework'ü ile birden fazla test sınıfımızı istediğimiz sıra ile bir arada çalıştırabiliriz. Bunun için Suite yapısı kullanılır. Örneğin aşağıdaki SuiteTest sınıfımızı çalıştırdığımızda ArabaTest ve ArabaTest2 sınıfları sırası ile çalışacaktır.

public class Araba {

    private int hiz;
    private String marka;

    Araba() {

        hiz = 0;
    }

    public int getHiz() {

        return hiz;
    }

    public void hareketEt() {

        hiz++;
    }

    public void kaclaGidiyorum() {

        System.out.println("Hız : " + hiz);
    }

    public boolean opelMi() {

        if (marka.equals("opel")) {
            return true;
        }
        return false;
    }

}

import org.junit.Assert;
import org.junit.Test;

public class ArabaTest {

    @Test
    public void hareketEdiyorMu() {

        Araba araba = new Araba();

        araba.hareketEt();

        Assert.assertNotEquals("Arabanın hızı 0'a eşit!", araba.getHiz(), 0);

        // Diğer assert fonksiyonları
        // Assert.assertArrayEquals
        // Assert.assertEquals
        // Assert.assertFalse
        // Assert.assertNotNull
        // Assert.assertNotSame
        // Assert.assertNull
        // Assert.assertSame
        // Assert.assertThat
        // Assert.assertTrue
    }

}

package deneme;

import org.junit.Test;

public class ArabaTest2 {

    @Test(expected = NullPointerException.class)
    public void hataKontrol() {

        Araba araba = new Araba();

        araba.opelMi();

    }

}


package deneme;

import org.junit.runner.RunWith;
import org.junit.runners.Suite;

@RunWith(Suite.class)
@Suite.SuiteClasses({ ArabaTest.class, ArabaTest2.class })
public class SuiteTest {

}


Ignore
JUnit framework'ünde bulunan @Ignore anotasyonu ile test sınıfımızda çalışmasını istemediğimiz metotları belirtebiliriz. Örneğin bir test sınıfımızda 4 test metodu olduğunu düşünelim ve biz bu metotlardan sadece 3 tanesinin çalışmasını istiyorsak çalışmasını istemediğimiz metodun başına @Ignore anotasyonunu ekleriz.


JUnit framework'ü ile test sınıflarımızı yazarken yanlış senaryoları da test etme ihtiyacı duyabiliriz. Bir senaryoda verilmesi gereken hatanın gerçekten verilip verilmediğini kontrol etmemiz gerekebilir. Bu durumlar için JUnit framework'ü bizim için kullanışlı bir yapı sunuyor. Örnek;

public class Araba {

    private String marka;

    public boolean opelMi() {

        if (marka.equals("opel")) {
            return true;
        }
        return false;
    }

}

import org.junit.Test;

public class ArabaTest {

    @Test(expected = NullPointerException.class)
    public void hataKontrol() {

        Araba araba = new Araba();

        araba.opelMi();

    }

}

JUnit framework'ünde test senaryomuzu çalıştırdıktan sonra beklediğimiz sonuçların olup olmadığını tespit etmek için assert sınıfının fonksiyonlarını kullanırız. Örnek;

public class Araba {

    private int hiz;

    Araba() {

        hiz = 0;
    }

    public int getHiz() {

        return hiz;
    }

    public void hareketEt() {

        hiz++;
    }

    public void kaclaGidiyorum() {

        System.out.println("Hız : " + hiz);
    }

}

import org.junit.Assert;
import org.junit.Test;

public class ArabaTest {

    @Test
    public void hareketEdiyorMu() {

        Araba araba = new Araba();
        
        araba.hareketEt();
        
        Assert.assertNotEquals("Arabanın hızı 0'a eşit!", araba.getHiz(), 0);

        // Diğer assert fonksiyonları
        // Assert.assertArrayEquals
        // Assert.assertEquals
        // Assert.assertFalse
        // Assert.assertNotNull
        // Assert.assertNotSame
        // Assert.assertNull
        // Assert.assertSame
        // Assert.assertThat
        // Assert.assertTrue
    }

}

JUnit, Java dilinde uygulamalarımızı test etmek için kullanabileceğimiz bir test framework'üdür. JUnit web sitesi ve github adresi;


JUnit framework'ünü örneğin maven projesi olarak çalışıyorsak ilgili dependency bilgisini ekleyerek kullanabiliriz. Aynı şekilde jar olarak da projemize ekleyebiliriz. Projemizin yapısına göre projemize ekleyebiliriz.

JUnit Nasıl Çalışır? JUnit Yaşam Döngüsü

JUnit framework'ünde test sınıflarımızı Java ile yazarız. Test sınıflarımızda metotlarımızın başına @Test anotasyonunu ekleyerek kullanırız. JUnit yaşam döngüsünde temel anotasyonlar şunlardır;
  • @BeforeClass (Test sınıfımız çalıştığında en başta sadece bir kez çalışır) 
  • @Before (Her test metodundan önce bir kez çalıştır) 
  • @Test (Test metotlarını belirtmek için kullanılır) 
  • @After (Her test metodundan sonra bir kez çalışır) 
  • @AfterClass (Test sınıfımız çalıştığında en son sadece bir kez çalışır) 



Unit test yazdığımız yazılım her biriminin ayrı ayrı test edilmesidir. Buradaki birim yazılımdaki en küçük parçaya denir. Nesneye yönelik programlama dünyasında en küçük birim sınıflardır. Sınıflar tek başlarına var olabilen ve belirli işleri yapabilen yapılardır. Nesneye yönelik programlamada unit test ile sınıflarımızın yapmaları gereken işleri doğru yapıp yapamadıklarını test ederiz. Unit testte her birim kendi başına test edilmelidir ve bir birim bir başka birime bağlı olmamalıdır. 

Birim testin ana amacı yazılımdaki hataları bulmak değildir. Zaten test mantığının temelinde test kodunun yazılımdan önce yazılması gerekir. Bunun nedeni yazılımdan ne beklediğimizin, hangi durumlarda nasıl çalışması gerektiğinin önceden belirlenmesi gerektiğidir. Eğer bunlar daha önceden belirlenmemişse o yazılımın sağlıklı bir şekilde geliştirilmesi pek mümkün değildir. İşte bu noktada bu durumlar belirlendiğinde bu durumlara göre test sınıflarınında yazılması gereklidir. Daha sonra yazdığımız kod bu belirlediğimiz durumlarda doğru çalışacak kod olmalıdır.

Test sınıflarının bir diğer önemli özelliği de kodumuzu değiştirmemiz gerektiği durumlarda ortaya çıkar. Günümüzde ihtiyaçlar çok sık değişebiliyor. Kod yazıldıktan sonra veya daha kod yazılırken ihtiyaçlar değişebiliyor. Bu durumlarda kodda yaptığımız değişikliğin kodumuzu nasıl etkileyeceği çok büyük problem oluyor. Ancak elimizde daha önceden yazılmış test sınıfları olduğunda yapılan değişiklik sonrası yazılımı test etmek çok kolay olabiliyor.

Bir birimi test ederken yaşanan en büyük problemlerden biride bağımlılıklardır. Örnek olarak bir sınıfın bir metodu veritabanı işlemi yapabiliyor olabilir veya dış bir servisten veri alabiliyor olabilir. Normalde test ederken bu bağımlılıkları da çalıştırırız. Ancak birim test mantığı böyle değildir. Birim testte, test edilen o birimin kodudur. Bağımlılıkların doğru çalışıp çalışmadığı değildir. Bu nedenle birim testte sadece bağımlılıkların doğru bir şekilde çağırılıp çağırılmadığı test edilir. Bu işlem için yazılmış bir çok mekanizma vardır. 

Test sınıflarımızı yazmak için ortaya çıkmış bir çok framework vardır. Bunlardan bazıları;
  • JUnit
  • MSTest
  • NUnit
  • XUnit
  • MbUnit
Birim test yazarken dikkat edilmesi gerekenler;
  • Her test metodunda sadece bir senaryo test edilmelidir.
  • Test metotlarımızı gerekli ortamın hazırlanması, senaryonun çalıştırılması ve sonuçların kontrolü şeklinde bölümlere ayırabiliriz.
  • Test metotlarımızın isimleri test edilen senaryoyu açıklayacak şekilde olmalıdır. Anlamsız bir isimlendirme yerine uzun bir isimlendirme daha iyidir.
  • Test edilen birim diğer birimlerden tamamen bağımsız olmalıdır.
  • Her test metodu diğer test metotlarından bağımsız çalışabilmelidir.

Github projelerini incelediğinizde çok güzel yazılmış readme dosyalarını görebilirsiniz. Bu yazımda nasıl readme dosyası yazılır onu anlatacağım.
Github'ta readme yazarken word standartlarını veya html standartlarını kullanamazsınız. Github'ın bunun için geliştirdiği kendi standartları vardır. Bu standartları kullanarak çok güzel readme dosyaları yazabilirsiniz. Github'ın bu konudaki resmi dökümanına aşağıdaki linkten ulaşabilirsiniz.


Şimdi bu standartları nasıl kullanacağınıza geçelim. Github projenizde bir readme dosyası ekledikten sonra aşağıdaki örnekleri kullanarak bir readme yazabilirsiniz.

Başlık Eklemek

# The largest heading
## The second largest heading
###### The smallest heading



Yazı Standartları

Sol taraftaki gibi yazdığımızda, sağ taraftaki gibi bir çıktı alabiliyoruz.



Alıntı Yapmak

In the words of Abraham Lincoln:

> Pardon my French



Consol Komutu Eklemek


Some basic Git commands are:
```
git status
git add
git commit
```



Link Eklemek

This site was built using [GitHub Pages](https://pages.github.com/).



Liste Eklemek


- George Washington
- John Adams
- Thomas Jefferson




1. James Madison
2. James Monroe
3. John Quincy Adams



Emoji Eklemek


@octocat :+1: This PR looks great - it's ready to merge! :shipit:




Kullanabileceğiniz emoji listesine buradan ulaşabilirsiniz.

Resim Eklemek


![Image of Yaktocat](https://octodex.github.com/images/yaktocat.png)




Kod Eklemek


```javascript
if (isAwesome){
  return true
}
```



Bu yazımda Git ile sık kullanılan komutları ve kısa açıklamalarını paylaşacağım.

apt-get install git-all : Git kurulumu için kullanılır.

git --version : Git versiyonunu görmek için kullanılır

git config -global user.name "ad soyad" : Git'te kullanılacak ad soyad bilgisini girmek için kullanılır.

git config -global user.email "email" : Git'te kullanılacak mail bilgisini girmek için kullanılır.

git config -global --list : Config dosyamızın içeriğini gösterir.

git init projeAdi : Bulunan dizini bir git repository sine dönüştürür.

git status : Projedeki dosyaların durumunu gösterir.

git log : Projemizdeki tüm commit'lerin bilgilerini gösterir.

git log --oneline : Projemizdeki tüm commit'lerin bilgilerini gösterir. Git log'a göre daha az bilgi gösterir. Çok commit olduğunda takip kolaylaşır.

git branch : Yerelimizde hangi branch'lar olduğunu ve bizim hangi branch'ta olduğumu gösterir.

git branch branchAdı : Yeni branch oluşturmak için kullanılır.

git branch -d branchAdı : Branch'ı silmek için kullanılır.

git branch --remote : Git sunucumdaki branch'ları gösterir.

git checkout branchAdı : BranchAdı ile belirttiğimiz branch'e geçeriz.

git checkout -b branchAdı : Yeni branch oluşturmak için kullanılır.

git add dosyaadi.uzanti : Localimdeki dosyaadi ile belirttiğim değişiklikleri staging area'ya taşır.

git add . : Klasördeki tüm değişiklikleri staging area'ya taşır.

git rm --cached dosyadi.uzanti : Staging area'daki dosyayı kaldırır. Dosya local'de durmaya devam eder.

git commit -m "commit mesajı" : Staging area'daki deişiklikleri git repository'sine taşır.

git checkout commitId : Localimizi commitId ile belirttiğimiz commit zamanındaki duruma geri döndürür. Diğer commit durumları repository'den silinmez. İstersek o commit id'ler ile o duruma dönebiliriz.

git revert commitId : Bu komut commitId ile verdiğimiz commit'te yaptığımız değişiklikleri geri alan bir commit yaratır ve commitler. Bu işlem o commit te yapılan her şeyi geri alır ve yeni bir commit'miş gibi davranır.

git reset commitId --hard : O commit'i komple siler. Bir daha geri dönüş olmaz. Yaptığımız commit in tamamen yanlış olduğunu düşünüyorsak kullanabiliriz.

git reset commitId --soft : O commit'i staging area'ya geri alır.

git remote add origin githubLink : localimizi github'taki repository ile eşleştirir.

git push origin master : Local'imizdeki commit'leri uzak sunucuya (github repository'si) göndermek için kullanılır. Sunucu adı origin genelde bu isim kullanılır bir standart. Branch adı master. Bunlar farklılık gösterebilir.

git remote -v : Remote(Uzak sunucu) bağlantımızı gösterir.

git clone githubLink : Verdiğimiz repository'i local'imize çeker. Daha sonra yapacağımız push işlemlerinde link vermemize gerek kalmaz. Defaul sunucu adı'da origin olur.

git diff branch1Adi branch2Adi : İki branch arasındaki farkları gösterir.


git merge branchAdi : BranchAdi ile belirttiğimiz branch'ı bulunduğumuz branch'ın üzerine yazar. İki branch'ı birleştirmiş yani merge etmiş oluruz.

Git ile bir proje üzerinde çalışırken yaptığımız değişiklikleri geri alabilir dilersek daha sonra tekrar ileri alabiliriz. Yaptığımız her değişiklik bir versiyonlama mantığı ile düşünebiliriz. Git'te yapılan her değişikliğin yani her commit'in bir id bilgisi tutulur. Bu id bilgileri ile projemizi istediğimiz commit'in olduğu andaki duruma getirebiliriz. İstersek bu değişiklikler hiç olmamış gibi tüm olanları silebiliriz, istersek sadece geri dönüp kontrol edebilir sonra tekrar ilk hale dönebiliriz. Git'te değişiklikleri geri alabilmek için üç farklı yöntem vardır. Bu yöntemlerin etkileri farklıdır ve farklı durumlarda kullanılırlar.

Revert
Bu komut, commit id ile belirttiğimiz commit'in yaptığı tüm değişiklikleri geri alacak şekilde proje dosyalarımızın üzerinde değişiklik yapar. Bu değişiklikleri daha sonra staging area'ya taşırız ve daha sonra depomuza commit ederek projemizi o ana döndürürüz. Bu işlemler projemizin tarihçesine yansır. Örnek verecek olursak bir proje oluşturduğumuzu ve commit1, commit2, commit3 mesajlarıyla üç commit yaptığımızı varsayalım. Daha sonra revert komutunu commit2'nin id si ile çalıştırdığımızı düşünürsek bu komut commit2 ile yapılan değişiklikleri geri alacak şekilde dosyalar üzerinde değişiklik yapar. Daha sonra biz bu değişiklikleri normal değişiklikler gibi commit edebiliriz. Tarihçemizi kontrol ettiğimizde(git log) şöyle bir sıra ile karşılaşırız. 

Commit1
Commit2
Commit3
Revert Commit2

Buradaki mantık değişiklikleri geri alan bir commit atılmasıdır ve tüm süreç daha sonradan tarihçede görülebilir.

Aşağıdaki gösterildiği gibi revert komutunu kullanabiliriz. Commit id yazan kısma değişikliklerini geri almak istediğimiz commit'in id bilgisini yazarız. Bu bilgiyi 'git log' komutu ile öğrenebiliriz.

git revert commitId

Reset
Bu komut projemizi, commit id ile belirttiğimiz commit olduktan sonraki hale getirir. Commit id ile belirttiğimiz commit olduktan sonra yaptığımız tüm değişiklikleri siler. Bu komutun iki farklı kullanımı vardır. Hard kullanımı ile dosyalar tamamen silinir ve tarihçe kaydı da temizlenir. Yani belirtiğimiz commit id den sonra yaptığımız tüm commit'ler sanki hiç yapılmamış gibi silinir ve tamamen temizlenir. Soft kullanımı ise hard kullanımı ile aynıdır tek farklı değişiklikleri git deposundan siler ancak local'imizden silmez. Daha sonra istersek local'den silebiliriz veya o değişiklikler üzerinde istediğimiz değişikliği yapıp tekrar commit edebiliriz.

git reset commitId --hard
git reset commitId --soft



Checkout
Bu komut, projemiz üzerinde bir zaman tünelindeymişiz gibi hareket etmemizi sağlar. Git deposuna yaptığımız her commit'in olduğu durumu bir zaman dilimi olarak düşünürsek, local'imizi istediğimiz bir zaman dilimindeki hale getirir. Bu durumdan git deposundaki proje dosyaları etkilenmez sadece biz local'imizde bir zaman tünelindeymişiz gibi zamanı geri veya ileri alabiliriz. Ayrıca bu işlem tarihçe dosyasına da yansımaz.

git checkout commitId


Bu yazımda Git'te bulunan branch kavramını anlatacağım. Branch, Türkçe'de dal anlamına gelmektedir. Buradan anlaşılacağı üzere projemizin yeni bir dalını oluşturmak anlamına gelir. Projemiz birbirinden bağımsız olarak birden fazla şekilde geliştirilmesi gerekebilir. Buradaki farktan kasıt projenin aynı olması ama uygun durum oluşana kadar birbirinden bağımsız olması gerektiğidir. 

Örneğin iş dünyasında dev, test, uat ve prod gibi branch'lar kullanılır. Bunların anlamı şöyledir;

  • Dev ortamı, projeyi geliştiren developer'ların kodlarını sakladıkları branch'tır. Bu kodları hazır olduğunu düşündükleri zaman test ortamına merge ederler. Yani test ortamına gönderirler. Buradaki uygunluktan kasıt, üzerinde çalıştıkları kod parçalarının kullanıma hazır olduğunu düşündükleri uygunluktur.
  • Test ortamı, projeye eklenen kodların test mühendisleri tarafından test edildiği branch'tır. Dev ortamından bağımsız olarak bu ortamda test edilmeye hazır kodlar bulunur. Oysaki dev ortamında daha üzerinde çalışılan, test için uygun olmayan kodlarımızda bulunuyordu.
  • Uat ortamı, projemizde test'ten geçen kodların gerçek dünyada kullanılmadan önce son kez test edildiği branch'tır.
  • Prod ortamı, projemizin gerçek dünyada kullanılabilir halinin bulunduğu branch'tır. Buraya gönderilen tüm kodlar direkt olarak projemizi kullanan kullanıcıları etkiler.


Yukarıdan örnekten anlaşılacağı gibi bir proje geliştirirken projenin farklı durumlarını saklamamız ve bunlar üzerinde çalışma yapmamız gerekebilir. Bu durumlarda branch kullanılır.

Aşağıdaki komut ile bir branch oluşturulur. Branch komutu, o an projemizin bulunduğu hali kopyalar ve yeni bir branch olarak oluşturur. Daha sonra projemizin ilk hali ve yeni branch ayrı projelermiş gibi düşünülebilir. Birinde yaptığımız değişiklik diğerini etkilemez. Burada dikkat edilmesi gereken konu projemizi ilk oluşturduğumuzda master branch'ı oluşur. Biz yeni bir branch oluşturmadığımız sürece sadece master branch'ı olur ve biz bu branch üzerinde işlem yaparız. Branch adı ile branch'imize vermek istediğimiz adı belirtiriz.

git branch branchAdı

Eğer bir branch'ı silmek istersek aşağıdaki komutu kullanabiliriz. Branch adı ile silmek istediğimiz branch'ın adını belirtiriz.

git branch -d branchAdı

Aşağıdaki komut ile local'imizdeki branch'ları ve bizim hangi branch üzerinde olduğumuzu görebiliriz.

git branch 

Aşağıdaki komut ile eğer uzak depo kullanıyor isek o depodaki branch'ları görebiliriz. Yeni bir branch oluşturduğumuzda bu branch'taki değişiklikleri uzak depoya gönderirsek otomatik olarak branch uzak depoda da oluşturulacaktır.

git branch --remote

Aşağıdaki komut ile hangi branch üzerinde çalışmak istediğimizi belirtiririz ve local projemiz o branch'e göre güncellenir.

git checkout branchAdı

Branch'lar üzerinde değişiklik yaptıktan sonra iki branch arasındaki farklılıkları görmek için aşağıdaki komutu kullanırız.

git diff branch1Adi branch2Adi

Eğer iki branch'ın kodlarını birleştirmek istersek yani örneğin dev ortamındaki kodlarımızı int ortamına taşımak istersek aşağıdaki komutu kullanırız. Aşağıdaki komut, komut ile belirttiğimiz branch'ın üzerinde yaptığımız değişiklikleri üzerinde bulunduğumuz branch'a da uygular. Bu şekilde iki branch'ta o anda aynı kodları içerir.

git merge branchAdi


Bu yazımda Github'taki bir projeyi kendi bilgisayarımıza nasıl indirebiliriz onu anlatacağım. Aslında bu işlem çok basittir. Github'ta indirmek istediğimiz repository'nin sayfasını açtığımızda 'clone or download' yazan yeşil bir buton göreceğiz. Bu buton o deponun linkidir. Bu linki kopyalayarak işe başlayabiliriz.


Daha sonra konsolumuzu açarak aşağdıdaki kodumuzu çalıştırdığımız zaman bulunduğumuz dizine Github repository'sinde bulunan proje gelecektir. GithubLink ile belirtilen kısma kopyaladığınız linki yapıştırmanız gerekiyor.

git clone githubLink

Bu işlem tamamlandığında bulunduğunuz dizine dosyaların indirildiğini göreceksiniz.



Daha önceki yazılarımda basitçe Git'i nasıl kullanabileceğimizi ve uzak depoyu anlatmıştım. Github'ın bir uzak depo olduğunu söylemiştim. Bu yazımda Git ile Github'ın nasıl kullanılacağını anlatacağım.

Önceki yazıyı okuyarak bir Git projesi oluşturduğunuzu ve değişikliklerinizi commit ettiğinizi varsayıyorum.

İlk önce kendi bilgisayarımızdaki projemiz ile Github Repository'sini eşleştiriyoruz. Github'ta yeni bir repository oluşturarak 'clone or download' kısmında bulunan repository linkimizi kopalıyoruz. Daha sonra aşağıda bulunun komuttaki GithubLink yazan kısım yerine bu linki yapıştırıyoruz. Bu komutta origin uzak depomuza verdiğimiz takma ad olarak düşünülebilir. Başka bir isimde verilebilir ama genelde bu isim kullanılır.

git remote add origin githubLink

Eşleştirme işlemini yaptıktan sonra aşağıdaki komut ile projemizin eşleştiği deponun bilgilerini görüntüleyebiliriz.

git remote -v

Aşağıdaki komut ile projemizde yaptığımız commit'leri uzak depoya yani Github depomuza gönderebiliriz. Bu komuttaki origin yukarıda eşleştirme işleminde belirttiğimiz uzak depo adımız. Eğer eşleştirme işleminde farklı bir isim verdiyseniz buraya o ismi yazmanız gerekir. Master ise bizim branch'imizin adını belirtir. Branch konusunu bilmiyorsanız sorun değil öğrendikten sonra oturacaktır. Eğer yeni bir branch oluşturmadıysanız default olarak branch'imiz master'dır.

git push origin master

Bu komuttan sonra bizden username ve password isteyecektir. Github hesabımızın bilgilerini yazdıktan sonra dosyalarımızın Github deposuna eklendiğini göreceksiniz.


Bir önceki yazıda Git'in ne olduğunu ve nasıl kurulacağını anlatmıştım. Bu yazıda Git'in nasıl kullanıldığını ve en basit işlemlerini anlatacağım. Daha detaylı işlemlerini daha sonraki yazılarda anlatacağım.

Kısaca Git Ortamları

Git projelerimizde birden fazla ortam bulunur. Bunlar sırasıyla local'imiz, geçiş bölgesi, git deposu(local repository) ve uzak depo'dur(remote repository). Bu ortamlar kısaca şu işe yarar;

  • Local'imiz, projemizin bir örneğini bulundurduğumuz kendi proje dizinimizdir ve bu örnek üzerinde değişikliklerimizi yaparız.
  • Geçiş bölgesi, git deposuna göndermek istediğimiz değişiklikleri eklediğimiz bir liste olarak düşünebiliriz. Commit işleminde sadece bu listeye eklediğimiz değişiklikler git deposuna eklenir.
  • Git Deposu, kendi bilgisayarımızda bulunan Git'in kendi standartlarına göre bizim projemizi sakladığı depodur. Projemizin son halini bu depoda saklarız. Local'imizde yaptığımız değişiklikleri bu depoya gönderiririz.
  • Uzak Depo, aslında Git'i kullanmamızdaki temel amaçları sağlayan ortamdır. Proje üzerinde çalışan herkesin kendi local'i, geçiş bölgesi ve git deposu bulunur. Bu ortamlar herkesin kendi bilgisayarında bulunur. Biz birden fazla kişi olarak bir proje üzerinde çalıştığımızda ortak bir ortam ararız. İşte bu ortamı sağlayan uzak depodur. Herkes kendi deposundaki dosyaları uzak depoya gönderir(push etmek) ve bu şekilde ortak olarak bir proje üzerinde çalışılır. Aynı zamanda kendi bilgisayarımızdaki depomuz yanlışıkla silinse bile uzak depodan biz projemizi tekrardan kendi bilgisayarımıza indirebiliriz. Uzak deponun en güzel örneği Github'tır. Github bizim için bu hizmeti sağlar.

Git Kullanımı

Aşağıdaki komut ile bulunduğumuz dizinde bir Git projesi oluşturabiliriz. ProjeAdi olan yere projenizin adını girmelisiniz. Bu bilgi opsiyoneldir. Eğer bu bilgi girilmezse hangi klasörde isek o klasör bir git projesine çevrilir. Eğer proje adını girersek bulunulan klasör içerisine proje adında bir klasör açılır ve bu klasör git projesine çevrilir.

git init projeAdi

Git projesine çevirdiğimiz klasörün içerisine git adında bir klasör oluşturulur. Gizli klasör olarak oluşturulur bu yüzden görüntüleyemeyebilirsiniz. Bu klasör bulunduğu klasörün bir Git projesi olduğunu belirtir ve gerekli ayarları içerir. Git projesine dönüştürdüğümüz klasöre ben bundan sonra kısaca projemiz diyeceğim. Projemize bir dosya eklediğimizde veya projemizdeki bir dosyayı değiştirdiğimizde Git bu değişiklikleri otomatik algılar. Bu değişiklikleri görmek için aşağıdaki komutu kullanabiliriz.

git status

Yaptığımız değişiklikleri istersek geçiş bölgesine(staging area) taşıyabiliriz. Projemizde bir çok deişiklik yaptığımızda hepsini depomuza göndermek istemeyebiliriz. Burada depo dediğimiz şey Git'in projemizi sakladığı ortamlara denilebilir. Biz bazı değişiklikleri bu depoya göndermek istediğimiz için depoya göndermek istediğimiz değişiklikleri geçiş bölgesine taşırız. Bu işlemi aşağıdaki komut ile yapabiliriz. Dosya adı ile geçiş bölgesine taşımak istediğimiz dosyayı belirtiriz. Eğer nokta koyarsak Git'in tüm dosyaları geçiş bölgesine taşıması gerektiğini söyleriz.

git add dosyaAdi

git add .

Eğer geçiş bölgesindeki değişikliklerimizi Git deposuna göndermek istersek aşağıdaki komutu kullanırız. Bu işleme commit denir. Git projemizi kendine uygun şekilde depo(repository) adı verdiğimiz yerde saklar. Daha sonra Git üzerinde yapabileceğimiz tüm işlemleri (değişiklikleri geri alma, birden fazla kişinin yaptığı değişiklikleri birleştirme, vs) bu depo sayesinde yapabiliriz. Commit mesajı olarak istediğiniz bir mesaj girebilirsiniz. Proje büyüdüğü zaman projeye eklediğiniz her bir değişikliğin ne anlama geldiğini takip etmeniz açısından anlamlı bir şeyler girmeniz daha doğru olacaktır.

git commit -m "commit mesajı"

Aşağıdaki komut ile projemizde yaptığımız commit'lerin hepsini görebiliriz. Bu şekilde projemizde ne gibi değişiklikler olmuş ekipteki kimler ne zaman projeye kod eklemiş, neler eklenmiş bunları takip edebiliriz. Her commit'in üzerinde bulunan uzun sayılardan oluşan kod commit'lerin id bilgisidir. Commit'ler üzerinde işlem yaparken bu id bilgisini kullanırız.

git log

Aşağıdaki kod ile commit'ler üzerinde hareket edebiliriz. Örneğin projemizde 10 commit olmuş ve biz projenin daha eski bir haline erişmek istiyoruz. Örneğin projeyi 5. commit'in yapıldığı zamandaki haline döndürmek istiyoruz. Bu durumda aşağıdaki komutu kullanırız. Bu komuttaki commitId dönmek istediğimiz commit'in id bilgisidir. Yukarıdaki komut ile bu id bilgisini öğrenebileceğimizi söylemiştik. Burada dikkat edilmesi gereken bir noktada projeyi zamanda geri aldığımızda proje sadece bizim local'imizde değişiklik gösterir. Git deposunda bulunan projemizde herhangi bir değişiklik olmaz.

git checkout commitId