Önsoz

Son yıllarda Git'in bir ana akım VCS (Version Control System) haline geldiğini söylemek yanlış olmaz. Gerek hobi projelerde gerek profesyonel ekiplerde Git bir genel kabul olarak oturmuş durumda. Birçok projenin geliştirilme sürecindeki değişiklikleri yönetmek için gereksinim duyulan temel eylemleri Git başarıyla sağlayan bir araçtır. Git'in yaygınlığına örnek olarak birçoğumuz günlük geliştirme süreçlerimizde bir noktada temel Git komutları olan commit atma ve push atma eylemlerini gerçekleştiriyoruz.

Bu noktada uzun süredir gözüme çarpan, ve bence bir kültür haline gelmiş olan, bir gözlemi dile getirmek istiyorum. Git yaygın olarak kullanılan bir araç olmasına rağmen ne yaptığı ve nasıl çalıştığı anlaşılmıyor. Birçok ekibin ve birçok insanın commit, push ve merge dışında bir kullanıma ihtiyacı olmuyor. Bu üç eylem de yalnızca, kullanılan grafiksel uygulamalar ile (örneğin JetBrains, SourceTree, Visual Studio) veya GitHub veya GitLab gibi platformlar üzerindeki grafiksel düğmeler ile gerçekleştiriliyor. Bu durum çoğunlukla fazlasına ihtiyaç duymayan kullanıcılar için yeterli oluyor. Ancak işler yolunda gitmediği zaman eller ayaklara dolaşmaya başlıyor. Bu durum örneğin main branche uzun süre önce yanlış bir development branch merge edilmiş olduğunun fark edildiği zaman bunun nasıl olduğunu ve nasıl geri çevrilebileceğini çözmek için saatlerin harcanmasına sebep olabiliyor.

Bu sorunu "bilgi yetersizliği" olarak özetleyerek yazıyı noktalayabiliriz, ki yanlış bir çıkarım da olmaz. Ancak bana göre bu durumda "bilgi yetersizliği" sadece bir semptom, bir sonuç olarak meydana gelmekte. Bu semptomu oluşturan farklı bir sebep olduğunu düşünüyorum. Bana göre birçok kişi odaklandıkları şeylerin sadece sonuçlarıyla ilgileniyor. Bunu yanlış bir yaklaşım olarak isimlendirmemek gerekli. Bu yaklaşım genelde işe yarıyor ve bu noktalarda büyük bir mental yük tasarrufu sağlıyor. Günlük düzenli olarak kullandığınız buzdolabının motorunun hangi prensipleri kullanarak çalıştığını bilmenin bize çok bir faydası olmayacaktır. Ancak sadece sonuçlara odaklanmanın elimize ayağımıza dolaşmaya başladığı noktaları gözden kaçırmamamız gerektiğini düşünüyorum. Bu noktalara vardığımız durumlarda bu faydacı "sadece sonuçlara odaklanma" yaklaşımını değiştirmemizin bize büyük faydası olacaktır.

Birçoğumuz kullandığımız yazılım araçlarının da sadece düzenli olarak kullandığımız kısımlarını öğreniyoruz. Bu çoğu zaman zamandan tasarruf sağlayıp dikkatimizin dağılmasının önüne geçiyor. Git de bu kullandığımız araçlardan birisi. Ancak Git'in çok önemli bir farkı var. Git geliştirme süreçlerimizin tam merkezinde yer alan bir araç. Aynı codebase üzerinde birden çok kişinin bir arada birbirini engellemeden çalışabilmesine olanak sağlıyor. Codebase büyüdükçe yapılan değişikliklerin kayıt altına alınmasını ve takip edilmesini oldukça kolaylaştırıyor. Geliştirici arkadaşların yaptıkları geliştirmeden çok projenin yönetimine zaman ayırmasını engelliyor, ve bu sayede geliştirme süreçlerimizin ivmelenmesini sağlıyor. Sağladığı kolaylıkları göz önünde bulundurarak Git'in sadece bir commit atma aracı olarak görülmesinden çok daha fazla ilgiyi hak ettiği kanaatindeyim. Sonuçta kullandığımız buzdolabının kullanım kılavuzunu okumaktan da zarar gelmez.

Bu dökümanda referans olarak alınabilecek bir kaynak oluşturmayı amaçlıyorum. Git'in mental modeline bilgimin yettiği kadar değinmeye çalışacağım. Böylelikle Git'i her şeyin iyi gitmediği durumlarda nasıl faydalı bir şekilde kullanabileceğimizi daha iyi göreceğiz.