Git-101 Refresher

Bir uygulamanın geliştirilme aşamasında versiyon kontrol sistemi altında ilerlenmesinin ne kadar önemli olduğunu biliyoruz. Peki en çok duyduğumuz versiyon kontrol sistemi tanımı bizim için ne anlama geliyor?

GIT Nedir?

Git, 3. Nesil versiyon kontrol sistemidir. 1. nesil de internet üzerinden bağlantı olmadan ve sadece tek dosya üzerinde versiyonlama yapılabilirken, günümüzdeki 3. nesil ile online olarak tüm projemizi versiyon kontrol ile güncel olarak ilerletebiliyoruz.

Nesiller ile ilgili daha fazla bilgi için; https://ericsink.com/vcbe/html/history_of_version_control.html

Buna bir örnek verelim. Bir projenizin olduğunu düşünelim. Bu klasörde bir arkadaşınızla çalışıyorsunuz. “test.js” dosyasında bir değişiklik yaptın. Daha sonra arkadaşın da başka bir değişiklik yaptı ve sizden sonra aynı klasöre attı. En basit böyle anlatılır sanırım :)

Bu senaryoda dosyamızın önceki versiyonunu kaybediyoruz. Git kullanırken çalışmamızı commit atarak kaydettiğimizi belirten bir nokta oluşturuyoruz. Böylelikle bize hem bir geri dönüş noktası hem de bize ortak olarak ilerlememizde versiyon kontrolünü sağlayacak bir yapı kuruyoruz.

Git kullanmayı öğrenirken aldığım ilk tavsiyeyi hiçbir zaman unutmuyorum. Ne kadar çok commit atarsan o kadar iyi, git de attığın hiçbir commit (çalışma) kaybolmaz.

Developer Acil Durum Kiti

Kurulum

Günümüzde birçok IDE veya ayrı bir program (Bkz. GitKraken, Sourcetree…) bizlere GIT kullanmamızda yardımcı olmaktadır. Ancak eğer siz de bir şeyleri yaparken hissetmek ve detayını görmek isteyen biriyseniz, console üzerinden kullanabilirsiniz.

https://git-scm.com/ üzerinden kullandığınız işletim sistemine göre programı indirip kurulumu yapıyoruz. Kurulum tamamlandıktan sonra Git Bash console’ unu çalıştırabiliyor olmalıyız.

İlk çalıştırmamızda yaptığımız işlemlerde kullanılacak username ve email kaydını oluşturmamız gerekiyor. Bu kaydı gerçekleştirmeden de git genel olarak kullanılabilir ancak commit ederken bize bir hata dönecektir.

git config --global user.name "Burak Duman"
$ git config --global user.email burak_duman35@hotmail.com

Git Bash ile nasıl kişisel kısaltmalar oluşturabileceğinizi anlatmak istiyorum. Bundan önce kısaca temel Git Komutlarından bahsedelim.

Git Temel Komutlar

• git init: Konsol üzerinde bulunduğunuz dizine git dosyamızı oluşturur.
• git clone: Depolanmış bir repository’i locale dizininize kopyalar.
• git status: Bulunduğunuz branch’te locale olarak yaptığınız değişiklikler ve durumları gözükür.
• git checkout -b ExampleBranch: ExampleBranch isminde bir branch oluşturur.
• git checkout ExampleBranch: Oluşturduğumuz branch e geçiş yapmamızı sağlar.
• git add . : Yapılan tüm değişiklikleri staged status’une geçirerek commit’ e hazır hale getirilir.
• git reset . : Staged olan tüm değişiklikleri eklemeye hazır halde changes statusune çeker.
• git add ExampleDocument.html : Tek bir dosyayı staged durumuna geçirmiş oluruz.
• git commit -m “Initial Commit” : Staged durumundaki değişikliklerimizi commit atmış oluruz.
• git push: Hazır olarak bekleyen commit’lerimizi Git dizinimizin bağlı olduğu repository üzerine atılması gerçekleşir.
• git reset - -hard : Yapılan tüm değişiklikleri silerek atılan son commit durumuna döndürür.
• git rm -f : Kayıt edilmeyen yeni klasörleri siler.
• git checkout file/directory : Girilen dizindeki dosyanın eklenmeyen değişikliklerini, en son commitlenen versiyona (HEAD’ e) geri alır.
• git checkout . : Kaydedilmeyen değişikliklerin tümünü en son commitlenen versiyona (HEAD’ e) geri alır.

Örnek olarak, burada ilk adımda yaptığımız değişiklikleri kırmızı olarak görüyoruz.

Daha sonra “git add x” komutu ile değişiklik yapılan dökümanı staged durumuna getirdik.

Tekrar git status komutu ile durumları listelediğimiz zaman staged durumun yeşil, unstaged durumda olan dosyalarımızın kırmızı listelendiği karşımıza çıkıyor.

Ben Git Bash ile bu şekilde yaptığım işlemleri daha detaylı ve gözle görülür olarak kullanıyorum. Bu işlemlerin bir çoğu başta söz ettiğimiz yardımcı toollar ile tamamlanabiliyor. Toollar bize ne kadar kolaylık sağlasa da bazı hatalar git bash üzerinden çok daha rahat anlaşılabiliyor.

Bu durumlarda hatayı anlamak ve çözmek kendimce daha kolay olduğunu düşünüyorum.

Git Kısa Komutlar (Alias) Nasıl Oluşturulur?

Benim gibi konsol üzerinden ilerlemeyi sevenler için burada yaptığımız işlemleri de kısaltmak mümkün.

Git kurulumunu gerçekleştirdikten sonra,

\Git\etc\profile.d

dizinini açıyoruz. “aliases.sh” dosyasını herhangi bir text editör veya not defteri ile görüntüleyin. Yok ise oluşturun.

Dökümanın en üst kısmına,

GitBash Alias Tanımlama

alias “isim”=”komut”

şeklinde istediğimiz kısaltmaları dosyamıza ekliyoruz.

Not: Windows bu dosyayı değiştirmeye karşı koruyor ise, dosyayı silip yenisini oluşturabilir veya dosyanın kopyasını güncelledikten sonra değiştirerek sorunu çözebilirsiniz.

Oluşturduğumuz kısaltmalar ile kendi dil alanımızı oluşturmuş olup, zaman olarak da bir tasarruf sağlamış oluruz.

Şirketimizde Git Kullanımı

Remote olarak çalışmaya geçtiğimiz bu dönemde Hesapkurdu-Koalay ekibi olarak Git kullanımımızı ortak olarak düzenli bir şekilde ilerletiyoruz. Peki bu sürecimiz nasıl ilerliyor,

Projelerimizde Main, Staging ve Development olmak üzere 3 ana branch bulunuyor.

Main: Production (Canlı) ortamında bulunan projemizin güncel halini bulunduruyor.
Staging: Bir sonraki deployment sürecinde main e geçişi yapılacak olan geliştirmelerin güncel halinin bulunduğu branchimiz.
Development: Developer tarafından yapılan geliştirmenin test den geçtikten sonra staging aşamasına geçiş süreci için bekleyeceği branchimiz.

Peki bu aşamalara geçişler nasıl ilerliyor?

1- Planlamamızda aldığımız story için EkipAdı/EkipKodu-StoryNumarası ile development ortamından bir branch açıyoruz.

2- Tamamlanan geliştirmemizi test dönüşleri olumlu sonuçlandıktan sonra development’ a merge için PR (Pull Request) açıyoruz. Test fail olduysa development devam :)

Test Aşamalarımız

Code Review süreci, ekibimiz kod kalitesini, gözden kaçan hataları veya ileride hata yaratabilecek noktaları analiz etmesine ve yorumlama aşamasıdır. Bu aşama ileriye dönük kontrol olmak ile birlikte bazı noktalarda bilgi aktarımı da sağlamaktadır.

PR aşamasında ekipten en az 2 kişiden onay almadığı sürece geliştirme development branchine mergelenmiyor.

3- Merge işlemi tamamlandıktan sonra development branch imiz haftalık olarak Staging versiyonuna güncellenmesi için PR açılıyor. Bu PR da oluşan conflictler ve değişiklikler kontrol ediliyor.

4- Staging ortamında 3 gün kontrollerimizi yaptıktan sonra, Staging -> Master geçişi ve kontrolleri Release Manager tarafından gerçekleştiriliyor.

5- Release branchleri kullanmıyoruz, bunun yerine tag’leme ile main branchindeki release versiyonları yönetmeyi tercih ediyoruz.

Release Manager her hafta ekibimizden bir developer olmak üzere cycle şeklinde ilerliyor.

İlk medium yazım olarak farklı bir anlatım biçimi kullandım. Yanlış olduğum noktalar var ise şimdiden özür dilerim.

Umarım faydalı bir paylaşım olmuştur :)

Saygılarımla.