Bir ekibin içinde yazılım geliştiriyorsan, sürüm kontrol sistemi yoksa kafanın rahat olmasına imkan yok. Kodun bir satırı bile patlasa herkes birbirine girmeye başlıyor. 2017’de ilk iş yerimde, SVN ile uğraşırken bir merge kabusu yaşamıştık; biri kodu güncellemeyi unutmuş, herkesin işi çöp oldu, iki günlük emek gitti. O gün anladım, VCS olmadan yazılım yapmak, denize salına salına açılıp pusula almamak gibi.
Git ve GitHub son yıllarda Türkiye’de de standart oldu. Özellikle remote çalışan ekiplerde, bir satır kodun kimden geldiğini, neyi neden değiştirdiğini görmek büyük lüks değil, zorunluluk. Yıl 2024, hâlâ “kodu maille atar mısın?” diyen varsa uzak durmak lazım. Takım 5 kişi olsun, herkes kendi branch’inde takılsın, kod review mekanizması çalışsın, işte gerçek ekipçilik o zaman başlıyor.
Müşterili iş yapanlar için sürüm kontrolü hayat kurtarıyor. Bir özellik facepalm olursa, anında eski versiyona dönüyorsun, müşteri bir şey anlamadan sorunu çözüyorsun. Benim başıma 2022’de geldi, İstanbul’da bir e-ticaret sitesinde ödeme entegrasyonu göçtü. Neyse ki, Git’ten bir commit geriye sardık, gece 01:00’de siteyi ayakta tuttuk.
Bir de işin kariyer tarafı var. CV’de “Git biliyorum” yazmakla bitmiyor iş. Adam gibi branch açabiliyor musun, commit mesajların düzgün mü, rebase nedir biliyor musun? Ekipte bunları bilmeyen varsa her deploy öncesi dua edersin. İyi yazılımcı sürüm kontrol sistemini ezbere kullanır, çünkü kod kaybı, zaman kaybı, moral kaybı oradan başlar.
Birkaç temel tavsiye:
- Commit mesajlarını kim okuyacaksa ona göre yaz. “Update” yazıp geçme, ne güncelledin açıkça yaz.
- Ana branch’e direkt basma, pull request aç, başkası baksın.
- Her işin branch’i ayrı olsun, iş bitince birleşsin.
- Konuştuklarını, kararları kodun açıklama satırlarına değil, sürüm kontrol sistemine not düş.
Kısacası, bu işlerde kelebek etkisi var. Bir satır kodun bile izi net olmalı. Yarın öbür gün eski kodu ararken kendine küfretmek istemiyorsan, sürüm kontrolünü ihmal etme. Mazeret yok, alışkanlık haline getir.
Git ve GitHub son yıllarda Türkiye’de de standart oldu. Özellikle remote çalışan ekiplerde, bir satır kodun kimden geldiğini, neyi neden değiştirdiğini görmek büyük lüks değil, zorunluluk. Yıl 2024, hâlâ “kodu maille atar mısın?” diyen varsa uzak durmak lazım. Takım 5 kişi olsun, herkes kendi branch’inde takılsın, kod review mekanizması çalışsın, işte gerçek ekipçilik o zaman başlıyor.
Müşterili iş yapanlar için sürüm kontrolü hayat kurtarıyor. Bir özellik facepalm olursa, anında eski versiyona dönüyorsun, müşteri bir şey anlamadan sorunu çözüyorsun. Benim başıma 2022’de geldi, İstanbul’da bir e-ticaret sitesinde ödeme entegrasyonu göçtü. Neyse ki, Git’ten bir commit geriye sardık, gece 01:00’de siteyi ayakta tuttuk.
Bir de işin kariyer tarafı var. CV’de “Git biliyorum” yazmakla bitmiyor iş. Adam gibi branch açabiliyor musun, commit mesajların düzgün mü, rebase nedir biliyor musun? Ekipte bunları bilmeyen varsa her deploy öncesi dua edersin. İyi yazılımcı sürüm kontrol sistemini ezbere kullanır, çünkü kod kaybı, zaman kaybı, moral kaybı oradan başlar.
Birkaç temel tavsiye:
- Commit mesajlarını kim okuyacaksa ona göre yaz. “Update” yazıp geçme, ne güncelledin açıkça yaz.
- Ana branch’e direkt basma, pull request aç, başkası baksın.
- Her işin branch’i ayrı olsun, iş bitince birleşsin.
- Konuştuklarını, kararları kodun açıklama satırlarına değil, sürüm kontrol sistemine not düş.
Kısacası, bu işlerde kelebek etkisi var. Bir satır kodun bile izi net olmalı. Yarın öbür gün eski kodu ararken kendine küfretmek istemiyorsan, sürüm kontrolünü ihmal etme. Mazeret yok, alışkanlık haline getir.
00