GIT ve GITHUB1. Git Nedir?GIT aslında, dağıtık çalışan sürüm kontrol sistemi (DVCS) ve kaynak kod yönetim (SCM) aracıdır. DVCS: Distributed Version Control System, SCM: Source Code Management anlamına gelir. Eşdeğer diğer araçlardan öne çıkan farkları ise;

• Herhangi bir merkez sunucuya ihtiyaç duymadan, offline olarak çalışabilmesi• Güvenilirlik, commit’lerin tekil olması• Hızlı olması• Az yer tutması• Sıfır maliyetle branching (dallanma) yapabilmek ve merge etmek (birleştirebilmek)• Deployment ve benzeri işler için de kullanılması.

1.1 Versiyon (Sürüm) Kontrol Sistemi Nedir?

Versiyon kontrolünü bir dosya veya bir küme dosyadaki değişiklikleri takip edebilmek için uyguladığımız bir yöntem olarak tanımlayabiliriz. Git gibi sistemler tüm bu değişikliklerin tarihçesini ve içeriğini elektronik olarak bizim için takip ederek kayıt altına almamızı sağlayan veri tabanları olarak düşünülebilir.

Bu sistemleri kullanarak herhangi bir anda üzerinde çalıştığınız dosyaların o anki hallerini kaydedebilir, daha sonra da isterseniz bu dosyaların kaydedilmiş ve kontrol altına alınmış herhangi bir haline geri dönebilirsiniz.

Versiyon kontrol sistemleri en basit anlamda dosyalarınızdaki değişikliklerin tarihçesini takip edip kayıt altında tutan sistemlerdir. Bu nedenle versiyon kontrol sistemlerini yedekleme veya diğer yazılım geliştirme araçları ile karşılaştırmak doğru olmaz.

Versiyon kontrolünün en temel bileşeni repository denilen yapıdır. Repository, dosyalarınızdaki tüm değişiklikleri ve bu değişiklikler ile ilgili ilave bilgileri (değişikliği kim, ne zaman yaptı ve değişiklik ile ilgili girilen açıklamalar) ayrı birer versiyon olarak kayıt altında tutan bir veri tabanıdır. Git tüm bu bilgileri genellikle dosya sisteminde gizli bir klasör olarak oluşturulan .git isimli klasör içinde bir dizi dosya olarak tutar.

Local (Yerel) Repository: Local repository, kendi bilgisayarınızda proje klasörünüzün altında bulunan .git klasörüdür. Bu repository üzerinde sadece siz çalışabilirsiniz ve değişiklikler yerel diskinize kaydedilir.Remote (Uzak) Repository: Remote repository'ler ise genellikle uzaktaki bir sunucuda yer alırlar ve bu sunucudaki .git klasöründen ibarettirler. Takım çalışması söz konusu ise takımdaki kişiler değişikliklerini bu uzaktaki repository üzerinden paylaşırlar.

1.1.1 Versiyon (Sürüm) Kontrolüne Neden İhtiyacımız Var?

Uyumlu Ekip Çalışması: Beraber çalıştığınız diğer kişiler ile aynı dosyalar üzerinde çalışabilmek için ihtiyacımız var. Versiyon kontrol sistemi kullanıldığında ise ekibinizdeki herkes özgür bir şekilde istediği dosyalar üzerinde güvenli bir şekilde istediği değişikliği yapabilir. Herkes değişikliklerini tamamladıktan sonra da tüm değişiklikler versiyon kontrol sistemi kullanılarak sağlıklı bir şekilde merge (birleştirme) edilebilir.

Versiyonların Takip Edilebilmesi: Üzerinde çalıştığınız bir dosyanın veya bir dizi proje dosyasının zaman içinde farklı versiyonları oluşur ve bu versiyonların kayıt altına alınması gerekir. Versiyon kontrol sistemi kullandığınızda sizin çalıştığınız disk alanında proje dosyalarının sadece bir

�1

versiyonu bulunur, bu dosyaların daha önceki halleri versiyon kontrol sisteminin denetimindedir. Bu sayede istediğiniz zaman önceki versiyonlara geri dönebilir, versiyonlar arasındaki farklılıkları rahatlıkla inceleyebilir ve versiyonları kaydederken eklediğiniz ilave bilgileri ve yorumlarınızı rahatlıkla görebilirsiniz.

Önceki Versiyonlara Geri Dönebilme: Bu özelliği sayesinde dosyalarınızı ve projenizi istediğiniz şekilde değiştirebilirsiniz. Eğer yeni eklediğiniz özelliklerden dolayı projenizde sıkıntılar yaşarsanız, hemen önceki çalışan versiyonlardan birine dönebilirsiniz.

Yedekleme: Git sayesinde aynı projede çalışan herkesin kendi bilgisayarında projenin tam bir tarihçesi tutulur. Merkezi versiyon kontrol sistemi sunucusunda bir sorun oluştuğunda takımdaki herhangi birinin kendi diskindeki projeyi sunucuya geri yüklemesi yeterlidir. Diğerleri de kendi bilgisayarlarındaki proje dosyalarını geri yüklenen proje dosyaları ile senkronize edebilirler.

1.2 Git Konfigürasyonu

3 kapsamlı konfigürasyon bulunur:

Local: Sadece içinde bulunduğunuz (dizin) repository için geçerlidir. Kişisel projelerinizde kişisel e-posta adresi kullanırken, şirket projelerinde şirket tarafından verilen e-posta adresini kullanmanız gerekebilir.Global: Bilgisayara giriş yapmış (login olmuş) kullanıcının erişim yetkisi olan tüm repository’ler için geçerlidir. Değer atarken —global anahtar kelimesi kullanılır.System: Bilgisayardaki tüm kullanıcıları etkileyen en üst seviyedeki konfigürasyondur. Değer atarken —system anahtar kelimesi kullanılır.

1.2.1 Kullanıcı Adı ve Email Ayarlama

Git ayarlarından en önemli olanları kullanıcı adınız ve email adresinizdir. Git, ayar olarak tanımladığınız değerleri commit vb. işlemlerde otomatik olarak kullanır.

Burada —global ifadesini kullanarak, bu ayarları tüm projelerimiz için geçerli hale getirdik. Eğer belli bir proje dahilinde bu ayarları yapmak istersek —global ifadesini kaldırarak, aşağıdaki şekilde gerçekleştirebilirsiniz.

1.3 Commit

GIT, kendi içinde özel bir GRAPH(Directed Acyclic Graph) yapısı kullanıyor. Kendi özel yapısı içinde GIT değişiklikleri kendi yöntemleriyle saklar.

Akla gelebilecek en basit yöntem delta-diff yani sadece değişen şeyleri saklamak yerine GIT komple o anın fotoğrafını çeker. Bu aslında o an’ın snapshot’ı dır ve GIT buna Commit der.

Commit yaptığınız zaman GIT, adı commit-object olan bir taşıyıcı saklar. Bu taşıyıcı içinde stage edilmiş içerik, commit’i yapan kişi bilgileri, varsa bağlı olduğu bir üst commit ya da branch’lerin merge edilmesi (birleştirilmesi) sonunda oluşmuş bir commit ise birden fazla branch bilgisi saklar. Bunlar aslında birer işaretçi yani pointer’dır.

�2

git config —-global user.name “kullaniciAdinizi” git config —-global user.email “emailiniz”

git config —-global user.name “kullaniciAdinizi”

Commit, içinde hangi tree yapısına dahil olduğu bilgisini de saklar. İlk commit dışındaki tüm commit’lerin bir parent-commit’i bulunur. Sıfır bir repo içinde yapılan ilk commit aslında o repo’nun root-commit’idir. Hiçbir commit’ten türememiştir.

Daha iyi anlamak için aşağıdaki log çıktısını inceleyin:

Bu çıktıya göre, Son yapılan commit: b72ce45cafdc. Bu commit’in parent’ı 504714498c31 ve 504714498c31 commit’in parent’ı 49261317ef93. Parent’ı olmayan tek commit: b1d90b39ba10

Bu log çıktısının şematik halinin nasıl olduğunu görmek istersek,

Zaman çizelgesi soldan-sağa akarken commit’lerin ilişkisi tam ters şekildedir. Her zaman kim kimin üstü altı (parent/child) durumu önemlidir.

1.3.1 Commit Mesajı Nedir?

Kullanıcının yaptığı değişiklikleri tarif ettiği, anlattığı kayıttır. En basit ve hızlı bir şekilde commit mesajı yazmak için

kullanırız.

1.3.2 Versiyon Kontrolünün Commit ile İlgili Altın Kuralları

1) Sadece Birbiri İle Alakalı Değişiklikleri Commit Edin

Değişikliklerinizi commit etmeye karar verdiğinizde birbiri ile alakalı değişiklikleri tek bir commit olarak ele almaya özen gösterin. Eğer bu şekilde commit etmeye özen göstermezseniz;

• Commit’inizdeki değişiklikleri inceleyen ekip arkadaşlarınız yaptığınız değişikliklerden hangisinin hangi konu ile ilgili olduğunu anlamakta güçlük çekeceklerdir.

• Alakalı alakasız değişiklikler tek bir commit içinde yer aldığı için herhangi bir nedenle belirli ve tek bir değişikliği geri almakta güçlük çekeceksiniz.

Alakalı ve alakasız değişiklikleri tek bir commit ile ele almak yerine örneğin iki ayrı sorunu gidermek için yaptığınız değişiklikleri iki ayrı commit ile kayıt altına almalı veya daha büyük bir özellik üzerinde çalışırken bu özelliği oluşturan ve anlamsal bir bütün olarak ifade edilen daha küçük özellikleri de ayrı commit’ler ile kayıt altına almalısınız.

2) Anlamlı Commit Mesajları

Commit işlemi sırasında yazacağınız bilgilendirici bir mesaj hem ekibinizdeki diğer kişilerin hem de daha sonra kendinizin, yapılan değişikliği daha rahat ve hızlı anlamanızı sağlayacaktır. Mesajınıza

�3

*b72ce45cafdc (HEAD -> master) fixed grammar at licence section *504714498c31 hooks folder deleted *49261317ef93 Release: v0.1.0 *b1d90b39ba10 [root] initial commit

master | 49261317ef93 <- 504714498c31 <- b72ce45cafdc (son commit)

git commit -m “MESAJ”

kısa bir özet satırı yazdıktan sonra bir sonraki satırda da değişikliğin nedeni ve içeriği hakkında bilgi verebilirsiniz.

1.3.3 İyi Bir Commit Nasıl Olmalıdır?

1) Commit'inizde sadece kavramsal olarak ilişkili değişiklikleri içermeye özen göstermelisiniz. Zaman zaman iki farklı konu veya sorun ile ilgili aynı anda veya çok kısa aralıklarla değişimli olarak çalışmak zorunda kalabilirsiniz. Bu şekilde yapılan bir çalışma sonrasında commit zamanı geldiğinde mümkün ise iki konu ile ilgili değişikliklerinizi bir defada commit etmek yerine iki defada ayrı ayrı commit edin.

2) Tamamlanmamış değişikliklerinizi kesinlikle commit etmemeye özen gösterin.3) Commit'leriniz kısa ve açıklayıcı mesajlar içermeli.4) Son olarak da sık sık commit işlemi yapmayı alışkanlık haline getirmeniz faydalı olacaktır.

Tekrardan kısaca özetlemek istersek; 1) İlk satırda (50 karakteri geçmeden) özet bilgi vermek2) Detayları bir boş satır bırakıp alta yazmak3) Mutlaka yapılan değişiklikleri iyi izah etmek

Bu şekilde bir commit yazabilmek için yukarıda verdiğimiz git commit -m “MESAJ” yerine

yazmalısınız. Bu yöntemle karşınıza önceden belirlemiş olduğunuz text editörü çıkar ve rahat bir şekilde commit’inizi yazabilirsiniz.

Son olarak iyi bir commit örneği için aşağıdaki örneği inceleyebilirsiniz.

Kısa log’a bakan kullanıcı;

şeklinde açıklayıcı bir şekilde bu commit hakkında bilgi edinebilecektir.

�4

Sitemizin yeni bölümü için index sayfası oluşturuldu.

Yaptığımız projede, ABCD bölümü için yeni statik bir html sayfası gerekiyordu, bunun için index.html dosyasını oluşturdum ve front-end’i yazacak arkadaşa gerekli bilgiyi verdim.

Yeni bir paragrafta aynı markdown kullanır gibi kullandım.

- Bu şekilde list item yaptım, - Listeye devam ettim

# Initial commit

$ git log —-oneline

8833c9cfc Sitemizin yeni bölümü için index sayfası oluşturuldu. : :

git commit

‘#’ ile başlayan satırlar yorum satırlarıdır, mesajlara dahil edilmezler.

1.3.4 Commit Tarihçesi

Git, projeniz üzerinde çalıştığınız her anda yaptığınız commit işlemlerini kayıt altına almaktadır. Git’in commit’leriniz ile ilgili kayıt altına aldığı tarihsel bilgileri görmek için;

komutunu kullanırız. Bu komut tüm commit’ler ile ilgili bilgileri, en son commit en üstte olacak şekilde, tarihsel olarak sıralar. Eğer Terminal pencerenize sığmayacak kadar çok tarihsel kayıt var ise son satırda : simgesi yer alacaktır, klavyenizden SPACE/BOŞLUK tuşuna basarak bir sonraki sayfanın listelenmesini, q tuşuna basarak da listelemenin sonlandırılmasını sağlayabilirsiniz.

Görsel: Log Çıktısı

Terminal'de listelenen her commit tarihçesi kaydı, diğer bilgilerin yanı sıra, aşağıdaki temel bilgileri içerir:• Commit’in Hash değeri• Commit’i gerçekleştiren kişinin adı ve email’i• Commit tarihi • Commit mesajı

git log komutunu kullanarak commit işlemi ile ilgili bilgilendirici çoğu bilgiyi görmemize rağmen -p parametresi ile dosyalarda yapılan değişiklikleri de ayrıntılı olarak görebilirsiniz.

1.4 Git’de Dosya Durumları ve Dosya Sistemleri

Git'de dosyalarınız genel olarak iki durumda olabilir: • Untracked (Takip Edilmeyen): Bu dosyalar versiyon kontrolü altında olmayan veya sizin henüz

versiyon kontrolü yapmak için Git’e eklemediğiniz dosyalardır. Bu dosyalardaki değişiklikler siz dosyaları git’e eklemediğiniz sürece versiyon kontrolüne tabi değildir.

• Tracked (Takip Edilen): Bu dosyalar ise Git’in versiyon kontrolü takibi altında olan dosyalardır. Bu dosyalar üzerinde yapacağınız tüm değişiklikler Git tarafından takip edilmektedir.

Staging Area: Çoğu versiyon kontrol sisteminde değişiklikleriniz iki yerde kaydedilir; • Yerel diskinizdeki çalışma klasörünüz (working folder) veya

• Versiyon kontrol sisteminin veri tabanı�5

git log

Ancak Git'de değişikliklerinizin kayıt altına alındığı üçüncü bir alan daha vardır ki buna Staging Area denir ve Git'in en temel kavramlarından birisidir. Staging Area'yı, proje dosyalarımızdaki bir dizi değişikliği remote repository'ye göndermeden önce kayıt altında tuttuğumuz veri tabanı/alan olarak tanımlayabiliriz. Eğer Stating Area’ya eklediğimiz dosyayı henüz takibe almak istemiyorsak ya da değişikliği geri almak istiyorsak git reset HEAD <filename> diyerek o dosyayı UNSTAGE etmemiz gerek.

HEAD: Bulunduğunuz branch’deki en yeni / en son commit’i işaret eder.

Görsel: Git Dosya Sistemi

Son commit işleminizden sonra proje dosyalarınızda yaptığınız değişiklikleri listelemek için git status komutunu kullanabilirsiniz. Bu komutu kullandığınız takdirde Git size ayrıntılı bir durum bilgisi sunar. Bu bilgileri 3 ana grupta toplayabiliriz:• Changes to be committed (Commit edilmeye hazır dosyalar): Bu gruptaki dosyalar git add veya

git rm komutu ile Staging Area’ya eklediğimiz dosyalardır. Bu dosyalar bir sonraki commit’imizin içinde yer alacaktır.

• Changes not staged for commit (Commit için henüz hazır olmayan dosyalar): Bu gruptaki dosyalar değişiklik yaptığımız fakat henüz Staging Area’ya eklemediğimiz dosyalardır. Bu dosyalar bir önceki grubun içine eklemediğimiz sürece bir sonraki commit’e dahil olmayacaklardır.

• Untracked files (Versiyon takibinde olmayan dosyalar): Bu gruptaki dosyalar ise henüz versiyon kontrolü altına almadığımız dosyalardır.

1.5 Basit Kullanım Örneği

Git çok sayıda komut içerir. Bunların bazılarını çok sık kullanırken bazılarını ise çok az kullanacaksınız. Komut satırınızdan;

derseniz, karşınıza sık kullanabileceğiniz komutların açıklandığı bir döküman gelecek.

Genel olarak çok sık kullanacağınız komutları listelemek istersek;

�6

git help everyday

1 git init 2 git log 3 git status 4 git checkout 5 git add

6 git reset 7 git commit 8 git pull 9 git push

1.5.1 Local Bir Proje Oluşturmak

Versiyon kontrolü altında yeni bir proje oluşturmak ya da var olan bir projenizi versiyon kontrolü altına almak isterseniz, öncelikle projenizin olduğu klasörün içerisinde git init komutunu çalıştırmalısınız. Örneğin ben GitOrnek dosyasını versiyon kontrolü altına almak istiyorum. Üzerinde çalıştığım dosyayı versiyon kontrolü altına almadan önce ls komutu ile içeriğini görüntülemek istediğimde boş olduğunu görüyorsunuz. git init komutu ile bu dosyayı versiyon kontrolü altına aldığımda ise Git boş bir repo yaratıldığını bana söylüyor. Daha sonra ise o klasörümdeki dosyalarımı ls -la komutu ile görüntülediğimde .git isimli gizli bir klasörün olduğunu görüyorum.

Proje klasörümüzde eğer dosyalar ve başka klasörler olmuş olsaydı bu dosyaların ve klasörlerin hiçbiri henüz Git tarafından versiyon kontrolü altına alınmamıştı.

!! Versiyon kontrolü altına almak istemediğimiz dosyalarÖrneğe devam etmeden önce bilmemiz gereken bir diğer kısım da, geliştirme ortamları ve işletim sistemlerinde kullandığımız araçlar tarafından ara bir ürün olarak üretilen ve aslında doğrudan versiyon kontrolü altına almak istemediğimiz dosya veya klasörler olacaktır. Örneğin macOS’un otomatik olarak ürettiği gizli DS_Store isimli klasör veya C++ derleyicileri tarafından üretilen .o uzantılı obj dosyaları gibi. Hangi dosyaların versiyon kontrolü altında tutulacağına siz karar verirsiniz. Bu dosyaları tanımlamak için proje klasörüne eklenen .gitignore dosyası kullanılır.

Şimdi klasörümüzün içine bir tane dosya atalım ve reponun durumuna bakalım:

Gördüğünüz gibi takip dışında dosyalar (Untracked files) var. Şimdi bu dosyaları takip altına almak için git add <file> komutumuzu uygulayalım:

�7

Bu aşamadan sonra Git yeni bir dosya takip etmeye başladığını anladı yani README.md dosyasını yukarıda açıklamasını yaptığımız STAGING AREA’ya almış olduk. README.md dosyamız artık commit edilmeye hazır haldedir.

Son olarak da commit işlemimizi gerçekleştirelim:

1.5.2 Remote Repository’deki Bir Projeyi Local’e Kopyalamak

Remote repo’daki bir projeyi local’e kopyalamak için öncelikle cd komutu ile kopyalamak istediğiniz dizine gitmelisiniz. Sonrasında ise:

Uzak repo’nun adresi aşağıdakilerden biri olabilir: • ssh://user@server/git-repo.git• kullanıcıadı@sunucuadı:git-repo.git• http://example.com/git-repo.git• https://example.com/git-repo.git• git://example.com/git-repo.git

1.6 Branching

Git’in en önemli mekanizmalarından biri branching (dallanma) yaklaşımıdır. Branching denilen yöntem aslında Git dışındaki diğer versiyon kontrol sistemlerinde de öteden beri kullanılmaktadır. Ancak Git’deki branching yaklaşımı kullanım kolaylığı ve yüksek performansı nedeniyle diğerlerinden ayrılır. O an için çalıştığınız yani içinde bulunduğunuz branch her ne ise, o branch’den ya da başka bir branch’den N tane, belki de onlarca, yüzlerce kopya çıkartabilirsiniz ve bu işlem SIFIR MALİYETLİ bir işlemdir.

�8

git clone uzak_reponun_adresi

1.6.1 Branching Olmasaydı Neler Olabilirdi?

Farz edelim ki bir alışveriş sitesi üzerinde çalışıyorsunuz ve geliştirdiğiniz Sepet modülü yerine 3.parti bir modül kullanılması kararı alındı ve sizin de kendi modülünüzü ana yazılımdan sökmeniz istendi. Bu durumda sökmeniz gereken modül kodunu tespit edip diğer modülleri etkilemeden nasıl sökecektiniz? Buna çözüm olarak projenizin aşama aşama kopyalarını alabileceğinizi düşünebilirsiniz, ancak bu durumda da karşınıza şöyle problemler çıkacaktır: • Bu klasörler versiyon kontrolünden olmadığı için ekibin geri kalanı ile iş birliği yapmanız çok

zorlaşacak.• Farklı değişiklikleri entegre etmek çok zor ve hataya açık bir işlem olacak.• Aynı zamanda klasörleri kopyaladıkça, kendi disk alanınızdan yiyeceksiniz. 1 GB’lık bir proje

üzerinde çalıştığınızı düşünün. Bu projenin farklı farklı 20 tane kopyasını aldığınızı düşündüğünüzde disk alanınızdan gereksiz yere 20 GB’lık yeri heba etmiş olacaksınız.

• Bir diğer sıkıntı ise aldığınız kopyaların isim karışıklığıdır. Klasörlerin isimleri şöyle olabilir proje, proje_yedek, proje_yedek_1 vs. Böyle klasörleriniz olduğunu düşünün, peki hangi klasörlerde hangi dosyaları niye değiştirdiniz? Bu da karşınıza ayrı bir problem olarak çıkacaktır.

1.6.2 Branching Yapısı

Branching, bir önceki başlıkta verdiğim sorunların önüne geçmek için kullanabileceğimiz bir araç ve yaklaşımdır. Branching ile farklı bağlamları birbirinde kolayca izole ederek her birini kolayca ve ayrı ayrı yönetebilirsiniz.

Görsel: Örnek bir branching

Herhangi bir anda yaptığınız değişiklikler sadece aktif olarak üzerinde çalıştığınız branch'e (dal) yansıyacak, diğer branch’ler bu değişikliklerden etkilenmeyecektir. Böylece aynı anda birden fazla branch üzerinde özgürce çalışabilirsiniz ve en önemlisi de bu çalışmalarınızdan bir kısmının çöpe dönmesinden çekinmeden denemelerinizi yapabilirsiniz.

1.6.3 Branch’ler İle Çalışmak

Git'de branch kullanımı tercihe bağlı değildir, aslında farkında olmasanız bile projeniz üzerinde çalışırken her zaman aktif tek bir branch üzerinde çalışırsınız. Git'de projenizi ilk oluşturduğunuzda Git varsayılan olarak sizin için master adı verilen bir branch oluşturur ve siz bu branch üzerinde çalışmaya başlarsınız.

git branch yeni_branch komutunu çalıştırdığınızda Git sizin için projenizdeki dosyaların o anki halini barındıran yeni_branch isimli bir branch oluşturur.

Git, git branch ile oluşturduğunuz yeni branch’i otomatik olarak aktif hale getirmez!!

�9

Branch’i oluşturduktan sonra git branch komutunu çalıştırdığınızda Git size projeniz için oluşturduğunuz tüm branch’leri listeler ve aktif olan branch’i başına da * simgesi olacak şekilde gösterir.

git status komutunu çalıştırdığınızda da aktif olan branch “On branch …” ifadesi ile gösterilir.

Yeni oluşturduğunuz branch’e geçmek isterseniz git checkout yeni_branch komutunu kullanabilirsiniz. Eğer bir branch’i hem oluşturup hem de o branch’e geçmek isterseniz git checkout -b yeni_branch komutunu kullanabilirsiniz.

1.6.4 Basit Bir Branching Akışı

Günlük çalışma hayatınızda kullanabileceğiniz basit bir branching akışına örnek verelim ve bu senaryomuzun şöyle geliştiğini düşünelim: 1. Bir web sitesi üzerinde çalışmaya başladınız. 2. Bu siteye yeni bir özellik eklemek için bir branch oluşturdunuz. 3. Bu yeni branch üzerinden değişikliklerinizi yapmaya başladınız.

Bu sırada web sitesinde bir güvenlik açığı tespit edildiğini bildiren bir email aldınız. Acil olarak bu güvenlik açığını gidermeniz için yapmakta olduğunuz çalışmayı bırakmanız ve bu durumu düzeltmeniz gerekiyor. Böyle bir durumda aşağıdaki adımları takip edebilirsiniz:

1. Aktif branch’inizi web sitenizin son stabil versiyonunun bulunduğu master branch olarak değiştirdiniz.

2. Güvenlik açığını giderme çalışmanız için yeni bir branch oluşturdunuz.

�10

git branch loginsorunu komutunu kullanarak branch oluşturduk git checkout loginsorunu komutu ile bu branch’i aktif hale getirdik

git checkout master komutu ile

3. Güvenlik açığını giderecek değişikliği tamamladınız, testlerinizi yaptınız ve bu değişikliği Staging Area’ya ekleyip sonrasında da commit ettiniz.

4. master branch’imizi aktif hale getirdik.

5. Commit ettiğiniz değişikliği web sitenizin stabil versiyonunu içeren master branch’imize merge ettik.

6. Daha önce üstünde çalışmakta olduğunuz yeni özellik ile ilgili değişiklikleri içeren branch'inizi aktif hale getirerek çalışmanıza kaldığınız yerden devam edebilirsiniz.

1.6.5 Değişiklikleri Merge Etmek

Merging en basit anlamda herhangi bir branch'de yaptığımız değişiklikleri master branch'imiz ile birleştirme veya master branch'e entegre etme işlemidir(branch -> [merge] -> master).

!! Bir branch'deki değişikliklerinizi sadece master branch’iniz ile merge etmek zorunda değilsiniz. Kullandığınız Git çalışma pratiğine bağlı olarak herhangi bir branch'i başka bir branch'e merge edebilirsiniz.

Değişikliklerinizi master branch’inize merge etmek durumlardan sadece bir tanesidir, günlük çalışmanız sırasında karşılaşacağınız diğer bir durum ise üzerinde çalıştığınız branch'e master branch'deki değişikliklerin merge edilmesidir(master -> [merge] -> branch). Bu durumu doğurabilecek aşağıdakilere benzer durumlar ile karşılaşabilirsiniz: • Büyük bir ekipte çalışıyorsunuz ve ekip arkadaşlarınız yaptıkları değişiklikleri sık sık master

branch’e merge ediyorlar. Bu durumda siz de uzun zamandır üzerinde çalıştığınız branch’in master’dan geri kalmaması için merge işlemi yapmak isteyebilirsiniz.

• Tek başınıza çalışıyorsunuz ancak farklı zamanlarda farklı sebepler ile master branch’e merge ettiğiniz bir çok düzeltme yaptınız. Diğer yandan da daha uzun soluklu bir çalışmanızı ayrı bir branch üzerinde yapıyorsunuz. Üzerinde çalıştığınız branch’in master’daki değişikliklerden geri kalmaması için merge yapmak isteyebilirsiniz.

!! Commit’leri değil branch’leri entegre etmek! Git’de değişiklikleri merge etme işlemi sırasında kaynak branch’inizde tekil olarak hangi değişiklikleri (commit’ler) merge etmek istediğinizi belirtmezsiniz. Bunun yerine Git’de doğrudan kaynak branch’inizin tamamını hedef branch’e merge edersiniz, çünkü Git hangi değişikliklerin hedef branch’de bulunmadığını otomatik olarak olarak tespit edip sadece bunların entegre edilmesini sağlar. Kaynak branch’deki değişiklikler her zaman HEAD’e yani aktif branch’iniz hangisi ise ona entegre edilir.

Git’de merge işlemi çok basit iki adımda yapılır:

�11

git add login.xyz login.html login.css ile değişiklikleri Staging Area’ya gönderdikgit commit -m “Özel karakter içeren kullanıcı adlarında ortaya çıkan güvenlik sorunu giderildi” ile değişiklerimizi commit ettik.

git merge loginsorunu

git checkout yeniozellik_xyz komutu ile

git checkout master komutunu kullandık

1. git checkout komutu ile değişikliklerin aktarılacağı hedef branch’inizi aktif (HEAD) hale getirirsiniz.

2. git merge komutu ile kaynak branch’deki commit edilmiş değişiklikler HEAD’e entegre edilir.

1.6.6 Checkout, HEAD ve Working Copy Kavramları

Git'de bir branch otomatik olarak o branch için yaptığınız son commit işlemine bir işaretçi tutar ve hangi dosyaların o branch'e ait olduğunu bilir. Herhangi bir anda bir proje için tek bir branch aktif olabilir. Bu branch'e HEAD denir ve Working Copy içindeki (Working Copy'yi projenizin yerel diskinizdeki dosyalarının tamamı olarak düşünebilirsiniz) dosyalar aktif olan branch'e yani HEAD'e aittir. Diğer branch’lerinizdeki dosyalar diskiniz üzerinde değil Git'in veri tabanında (.git klasörü içinde özel bir formatta) bulunur.Farklı bir branch'i aktif hale getirmek için git checkout komutu kullanılır. Bu durumda Git otomatik olarak sizin için iki şey yapar: 1. Aktif hale getirdiğiniz branch’i HEAD yapar. 2. Aktif hale getirdiğiniz branch’e ait dosyaları Git veri tabanından diskinize kopyalar ve önceki branch’e ait dosyaları diskinizden kaldırır. Yani Working Copy’nize yeni branch’e ait olan dosyaları koyar.

Branch konusuna girişte bahsettiğimiz SIFIR MALİYETLİ durumu buradan gelmektedir.

1.6.7 Branching İş Akışları

Nasıl kullanıldıklarına bağlı olarak branch’leri iki ana grup altında toplayabiliriz:

1) Kısa Vadeli / Konu Bazlı Branch’lerProjelerinizde branch kullanımı konusunda korkmamalısınız. Örneğin yeni özellikleri kodlarken, bug fix yaparken veya deneysel özellikler ile ilgili çalışırken istediğiniz şekilde kolayca ve hızlı bir şekilde üstelik düşük maliyetli branch’ler oluşturabilirsiniz. Bu tür amaçlar için oluşturulan branch’lerin iki ortak özelliği vardır:

• Bu branch’ler tek konu veya değişiklik için oluşturulur. Örneğin size bildirilen bir hata için oluşturduğunuz branch üzerinde “GitHub İle Sistem Giriş” benzeri yeni bir özelliği kodlamayınız.

• Bu branch’ler üzerindeki çalışmanız göreceli kısa sürmektedir. Çalışmamız tamamlandığında bu branch’leri master veya daha geniş kapsamda tarif edilen bir branch’e merge edip sileriz.

2) Uzun Vadeli Branch’lerİkinci türdeki branch'ler ise daha üst seviyede anlam taşırlar ve yeni özellikler, bug fix ve deneysel çalışmalar gibi odaklanmış konular yerine projenizin stabil, test ve development gibi aşamalarını temsil ederler. Bu tür branch’ler projeniz üzerinde geliştirme yaptığınız sürece varlıklarını sürdüreceklerdir.• Genelde bu tür uzun soluklu branch’ler üzerinde doğrudan değişiklik yapmazsınız.

Çalışmalarınızı kısa vadeli branch’ler üzerinde yaparak değişiklikleri bu branch’lere entegre edersiniz.

• Uzun soluklu branch’ler arasında bir hiyerarşi vardır. Genellikle master branch projenizin stabil versiyonudur ve hiyerarşik olarak bir altında geliştirmelerinizi entegre ettiğiniz ve daha az stabil olabilen development branch’i yer alır.

1.6.8 Basit ve Faydalı Branching Stratejileri

1) Sadece Bir Tane Uzun Soluklu Branch Kullanın

Daha önce de belirttiğimiz gibi birden fazla uzun soluklu branch kullanabilirsiniz ancak çoğu zaman bu tip bir yaklaşım karışıklıklara ve fazladan efor sarf etmek gibi zorluklara sebep olabilir. Tek bir

�12

uzun soluklu branch kullanmanız durumunda (genelde master ismi kullanılır) işiniz önemli miktarda sadeleşip kolaylaşacaktır.

Bu yaklaşım ile çalışmanız durumunda master branch’iniz projenizin stabil kodunu barındırmalıdır. Kodunuzun stabil olmasını garantilemek için master branch’e entegre edilen (merge) tüm değişikliklerin testler, kod okuma vs. gibi kalite kontrol yöntemleri ile denetlenmesi gerekecektir. Bunun bir yansıması olarak değişikliklerin doğrudan master branch üzerinde yapılmaması gibi bir zorunluluk doğacaktır. Eğer git checkout master ve sonrasında git commit komutlarını çalıştırıyorsanız bilin ki stabilite kuralını ihlal ediyorsunuz.

2) Konu Bazlı Branchler’i Bolca Kullanabilirsiniz

Projeniz için yeni bir özellik üzerinde çalışmak için, bug fix yapmak için veya deneysel özellikleri ve iyileştirmeleri kodlamak için ayrı birer branch oluşturmaktan ve bu branch'ler üzerinde değişikliklerinizi yapmaktan çekinmeyin. Bu yaklaşım nerdeyse tüm branching iş akışlarında çok sık kullanılan ve sizin de alışkanlık haline getirmeniz gereken bir yaklaşımdır.

Sadece bir tane uzun soluklu ve stabil branch'iniz (master) olduğu için konu bazlı branch’lerinizin hepsini bu ana branch'i baz alarak oluşturup değişikliklerinizi tamamlayıp kalite kontrol sürecinizi (testler, kod okuma vs) de işlettikten sonra bu değişiklikleri tekrar ana branch'iniz olan master'a entegre etmelisiniz.

Diğer yandan siz kendi konu bazlı branch'inizde değişiklikleri yaparken ekip arkadaşlarınız da arada kendi değişikliklerini master branch'e entegre ediyor olacaklarıdır. Bu durumda da kendi branch'inizi master branch'deki değişiklikler nedeniyle güncel tutmak için master'daki değişiklikleri de kendi konu bazlı branch'inize sıkça entegre etmelisiniz.

Bu basit akışta unutmamanız gereken tek bir altın kural var; değişikliklerinizi kalite kontrol süreçlerinizi işletmeden ana branch'iniz olan ve her zaman stabil olması gereken master'a entegre etmeyin aksi durumda master branch'inizin stabilitesini bozabilirsiniz.

3) Remote ve Yerel Branch’lerinizi Senkronize Edin

Git'de remote ve yerel branch'leriniz pratik olarak birbirinden tamamen bağımsızdırlar. Ancak gündelik çalışmanız sırasında kendi bilgisayarınızda oluşturduğunuz branch'lerin uzaktaki sunucudaki eşleniğinin de olmasını sağlamalısınız.

4) Değişikliklerinizi Sıkça Remote Branch’lere Yükleyin (Push)

Remote branch’ler ile yerel branch’leri sadece yapısal olarak değil yaptığınız değişiklikler anlamında da senkronize etmelisiniz. Bu şekilde ekibinizin geri kalanı da sizin yaptığınız güncel değişikliklerden haberdar olacak ilave olarak yerel branch'lerinizi yedeğini almış olacaksınız.

1.6.9 Versiyon Kontrolünün Branch ile İlgili Altın Kuralları

1) Branch’leri Bol Bol Kullanın

Branch’ler Git’in en güçlü özelliklerinden birisidir. Branch’ler farklı bağlamlarda çalışmaktan kaynaklanabilecek karmaşanın önüne geçmek için biçilmiş kaftandır. Branch’leri bug fix’ler, yeni özellikler üzerinde çalışmak veya deneysel özellikleri geliştirmek için bol bol kullanın.

2) Yarım Yamalak Değişiklikleri Asla Commit Etmeyin!

Tam anlamıyla bitirmediğiniz ve test etmediğiniz bir değişikliği asla commit etmeyin. Üzerinde çalışacağınız değişiklikleri planlarken bu değişiklikleri mümkün olduğunca küçük parçalar halinde ele almaya özen gösterirseniz yaptığınız değişiklikleri kayıt altına almak için henüz

�13

tamamlanmamış değişiklikleri commit etmek zorunda kalmazsınız. Buna rağmen ara safhada kayıt altına almak istediğiniz değişiklikler olursa Git’in Stash özelliğini kullanabilirsiniz.

1.7 Versiyon Belirlemek ya da Tag’lemek

1.7.1 Etiketlerinizi Görüntüleme

Git’de mevcut etiketleri görmek isterseniz, git tag komutunu yazmanız yeterlidir.

Bu komut etiketleri alfabetik bir şekilde sıralar. Belirli bir örüntü ile eşleşen etiketleri aramak isterseniz git tag -l ‘v0.1.*’ şeklinde arayabilirsiniz.

1.7.2 Etiket Oluşturma

Git’de kullanılan başlıca iki etiket tipi vardır: hafif ve açıklamalı. Hafif etiketler hiç değişmeyen dallar gibidir, belirli bir kaydı işaret ederler. Açıklamalı etiketler ise, Git veri tabanında bütünlüklü nesneler olarak kaydedilirler. Etiketleyenin adını ve e-posta adresini içerirler aynı zamanda bir etiket mesajına sahiptirler. Bu bilgilere ulaşabilmeyi olanaklı kılmasından dolayı açıklamalı etiketlerin kullanılması önerilir.

1.7.2.1 Açıklamalı Etiketler

Açıklamalı etiketler için tag komutunu çalıştırırken -a seçeneğini kullanmak gerekir.

-m seçeneği ile birlikte etikete mesaj da dahil ederiz. Açıklamalı bir etiket mesajı için bu şekilde belirlemezseniz, Git mesajı yazabilmeniz için bir editör açacaktır.

git show komutunu kullanarak etiketlenen kayıtla birlikte etikete ilişkin verileri de görebilirsiniz:

�14

1.7.2.2 Hafif Etiketler

Kayıtların bir dosyada depolanmasından ibarettir, başka hiçbir bilgi tutulmaz. Hafif etiket oluştururken -a, -s ya da -m seçeneklerini kullanmamalısınız.

Şimdi etiket üzerinde git show komutunu çalıştıracak olsanız, etiketle ilgili ek bilgiler göremezsiniz. Komut yalnızca kaydı gösterir:

2. GitHub Nedir?GitHub versiyon kontrol sistemleri için(örneğin Git) uzak bir depo(repository)dur. Uzak depo demek, bir havuz olarak da düşünülebilir. Birçok yazılımcının bir araya geldiği, bir projenin kopyası üzerinde çalışarak projenin alt sürümlerini çıkardığı ya da çeşitli ihtiyaçlarını giderdiği ve yaptığı değişikliği havuza gönderdiği bir sosyal kodlama alanıdır. 

2.1 GitHub’da nasıl proje oluşturulur?

GitHub üzerinde repository oluşturabilmek için öncelikle bir GitHub hesabınızın olması gerekmektedir. Ücretsiz bir şekilde hesap oluşturabilirsiniz. GitHub’ta private (gizli) repo oluşturmak isterseniz, bunun için belli bir ücret ödemeniz gerekmektedir, aksi takdirde GitHub’da bulunan projeleriniz public (halka açık) bir şekilde bulunacaktır.

GitHub üzerinden yeni bir repository oluşturmak için GitHub anasayfasında bulunan Repositories sekmesine tıklayın. Bu sekmede yeni bir repo oluşturmak için sağ tarafta bulunan New butonuna basmalısınız.

�15

New butonuna bastığınız takdirde karşınıza aşağıdaki gibi bir ekran gelecektir:

Yukarıda en üst kısımda repo’nun sahibini ve repo’ya vereceğiniz ismin olduğu alanı görürüz. Repo’ya isim olarak istediğinizi yazabilirsiniz. Bu alanların altında ise projenin kısa, basit bir açıklamasını yazabileceğiniz alan bulunmaktadır. Açıklama kısmının altında ise projenizin gizli (private) mı yoksa herkes tarafından görülebilir (public) mi olduğunu seçtiğiniz kısım vardır. Projenizi gizli(private) yapmak istiyorsanız yukarıda da bahsettiğim gibi belli bir ücret ödemelisiniz (öğrenci ya da akademisyen değilseniz). En altta ise README.md dosyası, .gitignore ve license için alanlar bulunmaktadır. Bunları seçmek size kalmıştır ancak seçmeniz faydanızadır. Create repository dediğiniz takdirde yeni bir repo oluşturmuş olacaksınız.

2.2 GitHub’da Bulunan Bir Projeye Katkıda Bulunmak

GitHub’da bulunan bir projeye katkıda bulunmak isterseniz öncelik olarak projeyi fork etmeniz lazım. Projeyi fork edebilmek için projenin GitHub anasayfasında sağ üst tarafta bulunan Fork butonuna basmanız gerekmektedir.

Bastıktan sonra katkıda bulunmak istediğiniz repo’nun kendi profilinizde Repositories sekmesinin altında bulunduğunu göreceksiniz. Bu projede yapacağınız değişiklikler ana projeyi etkilemeyecektir.

Projede eklemeyi düşündüğünüz özellikleri ekledikten sonra ya da hatalı gördüğünüz kısımları düzelttiğinizi düşünüyorsanız, kendi değiştirdiğiniz kısımları ana projeye merge etmek isteyebilirsiniz. Bunun için Pull Request oluşturmalısınız. Pull Request oluştururken yaptığınız değişiklikleri anlatmak faydalı olacaktır. Proje sahibi yaptığınız değişikliklere bakıp, onları test

�16

ettikten sonra, eğer uygun bulursa Pull Request’inizi onaylayacaktır. Onaylaması durumunda sizin eklediğiniz kısımlar ile ana proje merge olacaktır ve projeye katkıda bulunmuş olacaksınız. Eğer proje sahibi yaptığınız değişiklikleri uygun bulmazsa, Pull Request yaptığınız yerde yorum halinde neden onaylamadığını büyük ihtimalle size bildirecektir. Gerekli düzenlemeleri yaptıktan sonra tekrardan Pull Request oluşturabilirsiniz.

2.2 GitHub’da Bulunan Bir Projeyi Bilgisayarımıza Çekmek

GitHub’da bulunan bir projeyi kendi bilgisayarınıza indirip, localden çalışabilirsiniz. Bunun için yapmanız gereken şey repo’nuzun sayfasına girmek ve orada bulunan Clone or download butonuna tıklamak. Bunu yaptığınız takdirde size repo’nuzun URL adresini verecektir.

Bu adresi kopyalayıp bilgisayarınızda bu repo’yu klonlamak istediğiniz konuma geldiğiniz zaman git clone <URL_adresi> şeklinde kullanmalısınız.

Yukarıdaki ekran alıntısında göreceğiniz üzere öncelikle bilgisayarımda repo’yu kopyalamak istediğim bir klasör yarattım ve onun içine girdim. Çalışmak istediğim klasörün içerisine girdikten sonra git clone <URL_adresi> komutunu kullanarak uzak repo’daki projeyi kendi bilgisayarıma klonlamış oldum. Bu sayede internet olmadan da rahatça proje üzerinde çalışabileceğim.

Faydalı olması dileğiyle,

Ekrem Candemir

�17

Kaynakça ve Referanslar

1. Git Püf Noktaları - Uğur Özyılmazel

2. Git 101 - Ali Özgür

3. Git Guide - Roger Dudler

4. Atlassian

5. Git-Scm

�18