ps

git nedir?

[Kaynak](https://juristr.com/blog/2013/04/git-explained/)Kaynak

Teknoloji dünyasında belki de en sık kullanılan, en sık kullanılması gereken programlardan biri git sanıyorum. Bu kadar hayati öneme sahip olmasına rağmen hem bu konuda pek kaynak olmadığını, hem de sık sık yanlış pratiklerin uygulandığını görüyoruz. Bu konu hakkında sizinle bir çay içmek isterdim fakat şu an için yazıyla yetinmek gerek sanıyorum. Yazı biraz uzun olabilir, arada goygoy falan vardır, affola. Direk uygulamaya geçmek isteyenler “Nasıl kullanıyoruz bu meredi?” adlı bölüme atlayabilir, direk uygulamalı olarak öğrenmeyi deneyebilirler; yazının ilk yarısında Git’in tarihinden ve nasıl çalıştığından bahsetmeye çalıştım.

git nedir?

git aslında bir versiyon kontrol sistemidir, İngilizce kaynaklarda VCS — Version Control System olarak geçer. Temel amacı, yazılım geliştirme sürecini küçük parçalara bölmek, projenin hayatı boyunca çeşitli mihenk taşları yerleştirmek ve bu mihenk taşları arasında hızlıca hareket edebilmenizi sağlayabilmek aslında. Tamamen bir komut satırı programı olan *Git *sayesinde projede yaptığınız herhangi bir değişikliği o an kaydedebilir, dilediğiniz zaman bu değişikliği geri alabilir veya bir süre sonra projenin bu noktadaki haline geri dönebilirsiniz.

Örneğin projenizde yeni bir özellik geliştiriyorsunuz, fakat bu özelliği geliştirirken projenizi bozabileceğinizi öngörüyorsunuz. İşte tam bu noktada, bu riski almadan önce Git’e diyorsunuz ki “projenin şuanki halini kaydet, sonra sorucam sana.”, o da “eyvallah reis” diyip projenin o anki halini alıp saklıyor. Bunu yaparken de dosyaları olduğu gibi kopyalamıyor, tam o ana ait bir imaj saklıyor, bunun nasıl olduğunu daha sonra tartışacağız. Bu işlemin arkasından siz istediğiniz değişiklikleri yapıyorsunuz, artık olursa olur suyu, olmazsa bulgur suyu. Yaptığınız değişikliğe küfürler edip geri almak istediğiniz noktada Git kardeşimize söylüyorsunuz, lafınızı ikiletmeden eski halini getiriyor.

Yazılım geliştirme işi sık sık hata ayıklama, deneme-yanılma gibi işler gerektirdiği için böyle bir versiyon kontrol sisteminin çok önemli olduğu konusunda anlaştığımızı varsayıyorum. Fakat Git yalnızca bizim arkamızı toplamakla kalmıyor, aynı şekilde aynı proje üzerinde çalışan takımların da işini müthiş kolaylaştırıyor. Proje üzerindeki değişikliklerin paylaşılmasını sağlıyor, aynı satır üzerinde işlem yapıldığında tercih yapma zorunluluğu getiriyor, geliştiriciye özel dosyaların dağıtılmasını engelliyor, kısacası takımların işini muazzam ölçüde kolaylaştırıyor.

Tarihi

İşin aslı, bu Git dediğimiz araç, Linux’un yaratıcısı abimiz Linus Torvalds tarafından yaratılmış. Sitelerine koydukları kısa tarihlerine göre, buradan ulaşabilirsiniz, 2002 yılında Linux projesi için versiyon kontrol sistemi olarak BitKeeper adlı ücretli aracı ücretsiz olarak kullanmaya başlamışlar. Fakat 2005 yılında bu şirket ile olan ilişkileri bozulmuş, şirket de kendilerine verilen beleş iznini kaldırmış. Ek olarak Wikipedi’de yazıldığına göre BitKeeper adlı şirket, Linux çekirdek geliştirme projesine katkıda bulunan geliştiricilerden Andrew Tridgell adlı abinin BitKeeper’ın kaynak koduna ters-mühendislik yapıp araklamaya çalıştığını iddia etmiş, bu da bu ilişkinin bitişine sebep olmuş. Bu olaya sinirlenen Linus reis sizi bitirecem demiş, sonuç olarak Git’i yaratmış.

Linus reis aslında Git’i yaratmadan önce problemi varolan uygulamalar ile çözmek istemiş. Bu sebeple BitKeeper ve benzeri uygulamaları kullanırken gördüğü eksikleri düzeltilmesi gereken problemler olarak not almış, araştırmalarını bu yönde yapmış. Fakat halihazırda piyasada bulunan araçlar sorunlarına çözüm olmayınca kendi araçlarını yapma ihtiyacı hissetmiş. Velhasılıkelam, Linus reis 3 Nisan 2005’te başlamış projeye. Bu mail üzerinden anlattığı tarihlere göre, 6 Nisan’da duyurmuş projeyi, 7 Nisan’da da proje kendi versiyonlamasını yönetiyor hale gelmiş, self-hosting denilen durum. Linux çekirdeğinde yapılan ilk commit ise 16 Nisan tarihini göstermekte imiş. Linus başkan iki hafta içerisinde projeyi ana hatlarıyla ortaya koyduktan sonra da 26 Temmuz tarihinde Junio Hamano adlı abimize teslim etmiş projenin bakım ve sürdürülme işlemlerini, ki kendisi halen Git projesinin ana geliştiricisi imiş, şurada Linus Torvalds’ın kendisini mail grubuna tanıttığı mail görülebilir.

Gerek olmadığı halde tarihe girdik, açıkçası ben de merak ediyodum, biraz da o yüzden gireyim dedim, neyse devam ediyorum şimdi.

Nasıl çalışır?

Git tamamen dağıtık bir versiyon kontrol sistemi. Bu şu anlama geliyor: projenin herhangi bir yerdeki herhangi bir kopyası tam bir depo (repository) halinde saklanıyor. Yani projenin uzak sunucudaki kopyasını bilgisayarınıza kopyaladığınızda proje olduğu gibi bilgisayarınıza geliyor, bilgisayarınızda o proje deposunun tamamı saklanıyor. Bu proje depolarına repository deniyor, bu kelimenin kısası olarak repo diyeceğim yazının bazı yerlerinde. Dolayısıyla ilk kopyalama operasyonunuzla tüm repo bilgisayarınıza gelmiş oluyor.

Git, bu repo ile beraber üç katmandan oluşmakta. Birincisi, halihazırda çalışmakta olduğunuz klasörünüz, görselde “Working Repository”. İkinci katman ise “Staging” katmanı. Staging aşaması projenizde bazı değişiklikler yaptığınız fakat bu değişiklikleri henüz kaydetmediğiniz alandır. Staging’den sonra ise değişikliklerinizi kaydettiğiniz commit operasyonu gelir, bu da katman olarak değişikliklerinizi repo’nuza yazdığınız alandır. Görselde bu katmanlar kabaca görselleştirilmiş.

How Git WorksKaynak

Projenizi bir git repo’sundan çalışma klasörünüze kopyalarsınız, görseldeki “Checkout the project” operasyonu, artık lokalinizde de bir git repo’nuz olur ve tüm işlemler bu lokal repo’nuz üzerinden ilerler. Ardından değişikliklerinizi yaparsınız fakat henüz kaydetmemişsinizdir, “Stage Fixes” operasyonu. Bu değişiklikleri kaydetmek istediğinizde ise ilgili komutu çalıştırarak “Commit” operasyonunu yapmış olursunuz. “Commit” işleminiz ile de lokal git repo’nuza yaptığınız değişikliklerin bir kaydı düşülmüş olur. İlgili operasyonların komutlarına daha sonra gelicez.

Git, diğer versiyon kontrol sistemlerinden biraz daha farklı çalışıyor. Subversion gibi versiyon kontrol sistemleri değişiklik yapılan dosyaların değişimlerini saklıyor. Yani versiyon 2’de değişen A dosyası için “versiyon 1’in üzerine neler değişmiş” bilgisini saklayarak versiyonları saklıyor. Fakat Git’te bu işlemler “snapshot”, yani anlık alınan görüntüler olarak saklanıyor. Bu şu anlama geliyor, her kayıt operasyonunuzla beraber Git, projenizin o anki halinin bir fotoğrafını çekiyor ve bunu saklıyor. Bu işlemde yalnızca değişen dosyaların tümünün fotoğrafını saklarken aynı kalan dosyaların son hallerine birer bağlantı tutuyor. Eğer “lao ben niye hep aynı dosyaları saklıyorum, aradakilere gerek yok” diyorsanız bunun için de bazı Git komutları var, ki bunlar delta, yani değişimleri saklayarak repo boyutunuzu küçültebiliyor, fakat temelde Git’in snapshot’larla çalıştığını bilmeniz yeterli. Eğer bu delta mantığının detaylarını merak ediyorsanız şu bağlantıdaki İngilizce döküman faydalı olabilir.

Versiyon kontrol sistemlerinin bir güzel yanı da dallar, yani branch’ler. Branch’ler aynı projenin birden fazla versiyonu üzerinde aynı anda çalışmanızı, bu versiyonlar arasında hızlıca gezinmenizi sağlarlar. Branch’ler bir kökten çıkıp ayrılan ve ileride tekrar birleşen farklı dallar gibi düşünülebilir kabaca. Aşağıdaki görsel yardımcı olabilir:

Sample Branching Flow Kaynak

Görseldeki siyah renkli yol “master” adı verilen, ana branch’i temsil ediyor. Bir projede Git kullanmaya başladığınız an varsayılan branch olarak “master” branch’i gelir ve bu branch üzerinde çalışmaya başlarsınız. Bu branch’in dışında mavinin çeşitli tonlarıyla gösterilmiş branch’ler ise özellik branch’lerini temsil ediyorlar. Branch’ler ile çalışırken bunlara benzer çeşitli branch’ler açabilir, her bir özelliği ayrı branch’lerde geliştirebilirsiniz. Bu sayede özellikler izole ortamlarda geliştirilebilir, geliştiriciler birbirlerinin işlerini bozmaz, ek olarak bir özelliğin geliştirilmesi de çalışmanızı bloklayacak şekilde olmaz.

Branch’lerin en önemli güzelliklerinden biri aynı anda farklı şeyler üzerinde çalışmaya izin vermesi aslında. Örneğin, projenizin ilk versiyonunu yayına çıktınız, geliştirmeye devam ediyorsunuz. İkinci versiyonunuzu çıkarırken bir özellik üzerinde çalışıyorsunuz. Fakat bir aksilik oldu, özelliği beklediğiniz sürede çıkaramıyorsunuz ve vakit ihtiyacınız var. Bu esnada patronunuz yayındaki sürümde önemli bir hata olduğunu, sorunu acilen düzeltmeniz gerektiğini belirtti. Siz bu sıralar ikinci versiyon için olan özelliği geliştiriyordunuz, fakat bu esnada projenin canını çıkarmışsınız, hiçbir kısmı doğru düzgün çalışmıyor, eski haline getirmeniz bile çok uzun zaman alacak. İşte tam bu noktada patronun yedi ceddine küfretmeden önce sakince konsolunuzu açıyorsunuz, sırasıyla aşağıdaki komutları yazıyorsunuz:

git checkout master
git checkout -b v1-bugfix

Sonuç olarak v1-bugfix adındaki lokkum gibi branch’inize geçmiş oluyorsunuz. Geliştirdiğiniz özellik kendi branch’inde duruyor, siz de yeni branch’inizde hatayı düzeltip geri birleştiriyorsunuz, patron mutlu, siz dertsiz, dünya birkaç saniyeliğine güzelleşiyor.

Bu branch’ler aslında ayrılan dallar, ve bunların ana dallarına birleştirilmeleri gerekiyor ki proje tek koldan ilerleyebilsin, herkesin çalışmaları aynı temelde buluşsun, işte bu birleştirme işlemine “merge” deniyor. Merge operasyonu, branch’leri birbirleriyle birleştirmeye yarar, aynı noktada buluşmalarını sağlıyor. Bu sayede her branch kendi getirdiği özelliği ana branch’e birleştiriyor, ana branch de adeta bir takım gibi diğer branch’lerin getirdiği her şeyi birleştirip kullanmış oluyor.

Nasıl kullanıyoruz bu meredi?

Buradaki ders için bir Git repository’si oluşturdum, şu linkten ulaşabilirsiniz. Tüm komutlar bu yazı için oluşturduğum boş bir projede çalıştırılacak, içinde de çok küçük Markdown dosyaları saklayacağım. İlerleyen bölümlerde Git’i Windows’ta kullanıyor olacağım, dolayısıyla komutları Windows üzerinde Git Bash ile kullanacağım, fakat MacOS veya Linux işletim sistemlerinde de aynı komutları kullanabilirsiniz, hiçbir şey değişmeyecektir. Başlıyoruz.

Yükleme

Yükleme operasyonları işletim sistemleri arasında farklılıklar göstermekte. Nasıl kurulacağına dair gerekli bilgilere buradan ulaşabilirsiniz.

Kullanım

Öncelikle projemizin başlayacağı klasörümüzü oluşturuyoruz. Kullanım için herhangi bir klasörde çalışmamız gerek, örnek olması açısından projeye sıfırdan başlıyoruz. mkdir komutu bize medium-git-demo adlı bir klasör oluşturacak, cd komutu ise oluşturduğumuz klasöre gitmemizi sağlayacak.

mkdir medium-git-demo
cd medium-git-demo

Aslında her şey Git repo’muzu yaratmamızla başlıyor. Bunun için init komutunu çalıştıracağız.

git init

Bu komutu çalıştırmamızla beraber şöyle bir mesaj göreceksiniz:

Initialized empty Git repository in C:/Users/burak/Code/medium-git-demo/.git/

Bu, repo’muzu başarıyla oluşturduğumuz anlamına geliyor, tebrikler. Sıradaki işlemimiz ise yeni bir dosya oluşturmak. Test etmek için bir test dosyası oluşturacağız ve içine “Hello World” yazacağız, bunu aşağıdaki komut ile yapabiliyoruz.

echo "Hello World" >> README.md

Yukarıdaki echo komutu ile README.md adlı bir dosya oluşturduk ve içine “Hello World” yazdık. Şimdi Git repo’muzda bu değişikliğin nasıl göründüğünü görmek istiyoruz. Bu iş için çok sık kullanacağımız bir komut var, o da git status komutu. Bu komut ile repo’muzun şu anki durumunda sahnelenmemiş ve sahnelenmiş fakat kaydedilmemiş dosyaları görebiliyoruz. Şimdi projemizde bunu test etmek için aşağıdaki komutu çalıştırıyoruz.

git status

Bu komutun çıktısı olarak ise aşağıdaki metni görüyoruz.

On branch master
Initial commit
Untracked files:
    (use "git add <file>..." to include in what will be committed)

**        README.md**

nothing added to commit but untracked files present (use "git add" to track)

Çıktı metninde gördüğümüz metni satır satır incelersek:

Bu çıktı, sahnelenmiş ve sahnelenmemiş dosyaları farklı renklerde gösteriyor aynı zamanda, en azından Windows üzerinde default Git Bash kurulumunda böyle gösteriyor. Yukarıdaki çıktıda README.md dosyamız kırmızı görünüyor örneğin.

Buraya kadar anlaştıysak, dosyamızı sahneleme kısmına geliyoruz. Yeni dosyamızı eklemek için git add komutunu kullanıyoruz. Bu komut parametre olarak eklenecek dosyaların yolunu alıyor, biz içinde bulunduğumuz klasördeki dosyaların tümünü eklemek için şu anki klasörümüzü işaret eden . , yani nokta işaretini kullanacağız.

git add .

Komutu çalıştırdığımızda herhangi bir çıktı almayı beklemiyoruz, yalnız Windows sistemlerde aşağıdaki uyarıyı alabilirsiniz, yalnızca satır sonlarındaki karakterlerin Windows platformuna uygun olması için dönüştürüldüğünü haber veriyor, dolayısıyla önemli bir şey değil, es geçebilirsiniz.

warning: LF will be replaced by CRLF in README.md. The file will have its original line endings in your working directory.

Şimdi tekrar git status yaptığımızda sahnelenmiş dosyamızı görebileceğiz.

git status

Çıktı olarak ise aşağıdaki metni alacağız:

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

Bu çıktıda ilk iki satır bir önceki status ile aynı. Fakat bu aşamada artık değişikliğimiz sahnelendi, commit’lenmeye hazır. Değişikliğimizi commit’lerken ne değişiklikler yaptığımızı açıklayan bir commit mesajı ile birlikte commit’liyoruz. Bu işlem için aşağıdaki komutu kullanıyoruz.

git commit -m "İlk dosyamızı oluşturduk."

Bu commit ile birlikte artık dosyamızı Git repo’muza kaydetmiş oluyoruz. Artık tekrardan git status komutunu çalıştırırsak nothing to commit, working tree clean şeklinde bir mesaj alacağız, bu da henüz sahnelenecek bir değişikliğimiz olmadığını belirtiyor.

Yeni dosya eklerken veya varolan bir dosyayı değiştirirken aynı işlemleri uyguluyoruz aslında. Bir örnek olarak bu dosyayı tekrardan değiştirelim. Dosyamızı Notepad, Sublime Text gibi herhangi bir metin editörüyle açıp içindeki metni aşağıdaki ile değiştirelim:

# Merhaba Dünya!

Dosyamızı kaydedip çıkalım. Şimdi tekrar git status yaptığımızda ise ilk eklediğimizdekine benzer bir çıktı ile karşılaşıyoruz:

On branch master
Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)

        **modified:   README.md**

no changes added to commit (use "git add" and/or "git commit -a")

Bu sefer şunu görüyoruz ki artık Initial commit metni status çıktısında görünmüyor, bunun sebebi ilk commit’imizi artık tamamlamış olmamız. Bunun dışında bir de use “git checkout şeklinde bir satır gelmiş, bu metin de halihazırda yapmış olduğumuz değişiklikleri iptal etmek istiyorsak kullanabileceğimiz komutu gösteriyor, bunu da es geçiyorum. Yine aynı şekilde aşağıdaki komutları sırasıyla çalıştırırsak ikinci commit’imizi tamamlamış oluyoruz.

git add .
git commit -m "README değişiklikleri kaydedildi."

Bu operasyonların ardından ikinci commit’imiz de kaydedilmiş oluyor. Şu ana kadar iki commit gerçekleştirdik ve bir dosya üzerinde çalıştık. Bu iki komutu listelemek için ise git log` komutunu kullanabiliriz. Komutu çalıştırdığımızda ise aşağıdaki gibi bir çıktı alacağız:

commit 7b02cffb132b78f4d40e925af71a961e9ea65847
Author: Burak Karakan <[email protected]>
Date:   Tue Jun 27 03:31:28 2017 +0300

    **README değişiklikleri kaydedildi.**

commit babe48326ab25f7356535ecfceb6147d35d1f3c7
Author: Burak Karakan <[email protected]>
Date:   Tue Jun 27 03:22:41 2017 +0300

    **İlk dosyamızı oluşturduk.**

Log çıktımızda kaydettiğimiz commit’lerimizi görebiliyoruz. Bununla beraber commit’i kim yapmış, ne zaman yapmış gibi bilgileri de edinebiliyor, aynı zamanda ilgili commit’in 7b02cf şeklinde görülen hash değerine de erişebiliyoruz. Bu değeri kullanarak ileride dilersek geri dönebiliriz bu commit’e.

Faydalı Komutlar

git basli basina dev bir program, dolayisiyla tum ozelliklerini ve kisayollarini ogrenmek epey zaman alacaktir, ayni zamanda cogu durum icin de gereksiz olur.

git branch & git checkout

Yeni bir branch oluşturmak için iki komut kullanabiliriz, bunlardan ilki git branch <branch_adı> şeklindeki komut. Bu komut ile <branch_adı> adında bir branch’imiz olur, fakat henüz o branch’e geçmemişizdir. Şu an bulunduğumuz branch’i bırakıp yeni branch’imize geçmek istiyorsak git checkout <branch_adı> şeklindeki komutu kullanabiliriz. Fakat hem yeni bir branch oluşturup hem de o branch’e geçmek istiyorsak bunun tek komuta indirilmiş hali olarak ikinci yöntemimiz olan git checkout -b <branch_adı> var. Bu komut sayesinde hem <branch_adı> adında bir branch oluşturuyoruz, hem de o branch’e geçiyoruz, ki kendisi çok kullanışlı bir komut, sık sık kullanırsınız muhtemelen.

Varolan bir branch’i silmek için ise git branch -d <branch_adı> komutu kullanılabilir.

git merge

Branch açma işleminin tersi olarak sık sık branch’leri birleştirmemiz de gerekebiliyor. Bu işlemin adı “merge”, dolayısıyla işlemi yapan komut da git merge <branch_adı> şeklinde. Adını <branch_adı> şeklinde verdiğimiz branch’i şu an üzerinde bulunduğumuz branch’e birleştirir. Örneğin feature adlı branch’teyiz ve işimizi bitirdik, bu branch’i dev isimli branch’e merge etmek istiyoruz. Bu işlem için sırasıyla aşağıdaki komutları kullanabiliriz:

git checkout dev
git merge feature

checkout komutu ile birlikte dev adlı branch’imize geçtik, merge komutu ile de feature adlı branch’i dev branch’ine birlestirmis olduk.

git diff

Bir branch’i bir diğerine merge’lemeden evvel değişiklikleri görmek isteyebilirsiniz. Bunun için kullanışlı bir komut olan git diff yardımcı olacaktır. Örnek kullanım ise şu şekilde:

git diff <asıl_branch_adı> <mergelenecek_branch_adı>

git clone

Uzak sunucuda varolan bir repo’yu kendi bilgisayarımıza çekmek istediğimizde ise ihtiyacımız olan operasyona klonlama deniyor, ilgili komut ise git clone komutu. Bu komut ile uzak sunucuda bulunan bir repository’i olduğu gibi bilgisayarımızda bir klasöre kopyalayabiliriz. Örnek olarak bu proje için kullandığım GitHub repo’sunu kendinize kopyalamak isterseniz çalıştıracağınız komut şu olacaktır:

git clone [email protected]:karakanb/medium-git-demo.git

Bu komut ile Git bizim için ilgili linkteki repo’yu bulacak, komutu çalıştırdığımız klasörde repo ile aynı isimde bir klasör oluşturacak ve dosyaları buraya indirecek. Örneğin yukarıdaki komutu çalıştırdığınızda bilgisayarınızda medium-git-demo adlı bir klasör oluşacak, onun içerisinde ise proje dosyalarına erişebileceksiniz.

Ek olarak bu operasyonun ardından Git, komuta verdiğiniz URL’i de projeye origin olarak ekleyecek. Bu origin ismi ise URL için bir kısaltma vazifesi görüyor. Bu kısayolu projenize ekledikten sonra URL yazmanız gereken komutlarda sadece origin yazarak istediğiniz sonuca ulaşabileceksiniz. Bu kısayol değişkenlerine uzak sunucu adreslerini temsil ettiklerinden remote adı veriliyor.

git push

Lokalde istediğiniz geliştirmeleri yaptınız, bunları uzaktaki sunucuya ulaştırmak istiyorsunuz. Bu noktada ise git push komutu yardımınıza koşuyor. Bu komut sayesinde lokaldeki sunucunuzu uzak sunucunuzla eşleyebiliyorsunuz, repo’nuzun ayrı bir yedeğini de orda saklayıp başkalarıyla da paylaşabiliyorsunuz. Projenin içerisinde daha önceden tanımlanmış bir origin remote’unun olduğunu varsayıyorum, bu durumda repo’nuzu origin adresindeki uzak sunucuyla eşlemek için git push origin master demeniz yeterli olacaktır. Buradaki origin remote adını belirtirken master ise göndermek istediğiniz branch adını belirtir. Eğer bir clone operasyonu yaptıysanız ve düzenli olarak push yapıyorsanız, ilk push komutunuza -u şeklinde bir bayrak ekleyerek Git’in push operasyonu için default olarak bu adresi kullanmasını salık vermiş oluyorsunuz; bu default uzak sunucu adresine ise upstream branch deniyor. Bu sayede bu branch icin tekrar eden push operasyonlarınızda yalnızca git push yazmanız yeterli oluyor. Örnek bir kullanımı buraya bırakıyorum.

# Git'e default olarak origin adresini kullanmasını söylüyoruz.
git push -u origin master

# Artık sadece push yazmamız yeterli oluyor.
git push

git pull

Diyelim ki bir takımla çalışıyorsunuz ve herkes aynı uzak sunucuya push yapıyor. Bu esnada zaman zaman sizin repo’nuz, uzak sunucudaki repo’dan geri kalacaktır doğal olarak. Repo’nuzu en güncel haline getirmek için ise git pull komutunu kullanabilirsiniz. git push komutu ile hemen hemen aynıdır kullanımı, yine eğer bir upstream branch’iniz var ise yalnızca git pull yazarak repo’nuzu güncelleyebilirsiniz. Aksi takdirde ise komutun tam halini yazarak çekmek istediğiniz adresi ve branch’i belirttiğinizde gidip o branch’i size getirecektir.

git pull origin

Çeşitli Kaynaklar

Öncelikle eğer İngilizce bilgisi yeterli düzeyde ise kesinlikle Git’in “Getting Started” dökümanını öneriyorum. Yine İngilizce olarak Atlassian’ın Git hakkında hazırladığı kapsamlı dökümanlar var, baya lokum gibi anlatmışlar şekil şukul resimler falan da koyarak, o da çok faydalı olacaktır. Yine İngilizce olarak Git komutlarını interaktif olarak öğrenebileceğiniz, çalıştırıp deneyebileceğiniz bir kaynak olarak şu adresi kullanabilirsiniz, epey kullanışlı. Bunların dışında Türkçe olarak “git — basit rehber” adında, komutları ve kullanım örneklerini anlatan bir kaynak var, şuradan ulaşabilirsiniz. Bununla beraber yazıyı oluştururken karşılaştığım Ali Özgür beyefendi tarafından oluşturulmuş çok kapsamlı bir online kitap mevcut, şuradan ulaşabilirsiniz, kitap detaya girmesi açısından çok başarılı bir kaynak.

Tüm bu kaynaklar elinizin altında olsa da, Git’i öğrenmek size kalıyor. Benim tavsiyem, bir iki örnek ile basitçe başlamaya çalışmanız yönünde. Zaten zaman içerisinde karşılaştığınız problemler sizi Git’in farklı özellikleri ile tanıştıracak, bu sayede daha detaylı olarak öğrenmiş olacaksınız uygulamayı.

Sonuç?

Bu yazı ile beraber Git ve versiyon kontrol dünyasına bir adım atmış olmanızı umuyoruz. Aslında yazıyı tek başına bir kaynak haline getirmekten ziyade Git öğrenmeye çalışan kullanıcıya yardımcı bir kaynak haline getirmek istedik, o yüzden Git’in tüm detaylarını anlatmaktan ziyade eksik kalabilecek noktalara dokunup temellerini vermeyi amaçladık, umuyoruz ki faydalı olmuştur. Başka bir yazıda ücretli ve ücretsiz Git sunucu alternatiflerini tartışmayı planlıyorum, bu adımdan sonra orası faydalı olabilir.

Yazı içerisinde hatalar yapmış olabilirim, genel kullanım örnekleri üzerinden giderek kabaca anlatmaya çalıştım. Eksikleri buradan veya [email protected] adresi üzerinden iletirseniz hızlıca düzeltebilirim. Yazıyı okuyup önceden feedback veren Cem Ozan Altunbey, Burak Sayın ve Furkan Hatipoğlu kankilerime teşekkürlerimi iletiyorum.

Sevgiler.

n