Bu sayfada · 9 başlık
GitLab Hakkında Bilmen Gereken 5 Temel Soru
Kod barındırma, gelişmiş CI/CD (sürekli entegrasyon/sürekli dağıtım) boru hatları ve DevOps süreçlerini tek bir çatı altında yönetmek için kullanılan kurumsal platformdur.
Otomatik test ve sunucu dağıtım senaryoları, şirket içi özel sunucuda kendi Git altyapısını kurma, kod güvenliği denetimleri yapılır.
Kendi sunucusunda veri tutmak isteyen kurumsal şirketlerde, savunma sanayiinde, telekomda ve DevOps ekiplerinde kullanılır.
gitlab.com bulut servisi olarak veya şirketin kendi Linux sunucusuna (Self-hosted) kurularak çalıştırılır.
Güçlü yerleşik CI/CD araçları ve veriyi kendi sunucunda saklama esnekliği sunarak kurumsal güvenliği garanti eder.
GitLab ne için kullanılır?
Projeleri saklamak ve paylaşmak
CI/CD ile kodu otomatik test edip yayınlamak
Görev takibi (issue) ve proje yönetimi
Şirket içi sunuculara kurulabilen kapalı sistemler
GitLab kullanırken duyacağın kavramlar
- Merge request
- GitHub'daki pull request'in GitLab'daki adı: değişiklikleri ana koda ekleme önerisi.
- Pipeline
- Kodu her gönderdiğinde sırayla çalışan otomatik işler (test, derleme, yayınlama).
- Runner
- Pipeline'daki işleri çalıştıran bilgisayar.
- Issue
- Yapılacak işleri ve hataları takip etmek için açılan kayıt.
Nasıl kurulur?
Adımları görsellerle takip et. Ekran görüntüsüne dokunarak büyütebilirsin; sürümüne veya işletim sistemine göre düğmelerin yeri değişebilir.
- 1
-
2
Bilgisayarında Git kurulu olsun.
Şekil 2 · Terminalde Git'in kurulu olduğunu kontrol et. (temsili çizim) -
3
Şirketler GitLab'ı kendi sunucularına da kurabilir. Bu iş genelde sistem yöneticileri tarafından yapılır.
Şekil 3 · Şirketler GitLab'ı kendi adreslerinde çalıştırır; sen sadece giriş yaparsın. (temsili çizim)
Nasıl kullanılır?
Adım adım ilk kullanım. Kod kutularındaki "Kopyala" butonuyla komutları kopyalayabilirsin.
Yeni proje oluştur
New project → Create blank project. Projeye bir isim ver ve oluştur.
Yeni proje oluştur; boş depo ve README seçimini incele.
Grup, proje adı ve görünürlük seçeneklerinin kimin erişebileceğini etkilediğini öğren.
Örnek verinin doğru projede bulunduğunu yeniden açarak kontrol et.
Uygulama: İki sayıyı toplayan küçük bir Python dosyası oluştur.
Kontrol: Proje ve dal hedefleri doğru.

Videoyla adım adım izle · 2:55
Türkçe açıklamalı sessiz görsel anlatım. Sesli ders veya kesintisiz ekran kaydı değildir. Duraklatıp kendi ortamında uygula.
Video bölümleri ve tam metin
Yeni proje oluştur
Yeni proje oluştur; boş depo ve README seçimini incele.
İşin mantığı
Grup, proje adı ve görünürlük seçeneklerinin kimin erişebileceğini etkilediğini öğren.
Uygula ve gözlemle
Örnek verinin doğru projede bulunduğunu yeniden açarak kontrol et.
Somut görev
İki sayıyı toplayan küçük bir Python dosyası oluştur.
Kontrol et
Proje ve dal hedefleri doğru.
Takılırsan
Job beklemede — Runner erişimi, etiketler ve hesap kotalarını kontrol et; YAML sözdizimi tek neden değildir.
Kendine sor
Runner ne yapar? Yanıt: Pipeline işlerini gerçek bir çalıştırma ortamında yürütür.
Projeyi gönder
Bilgisayarındaki projeyi GitLab'a gönder (adresi kendi projenle değiştir):
git remote add origin https://gitlab.com/kullanici-adin/proje.git
git push -u origin main
Yerel depodaki remote adresini doğrula; uygun dala gönder.
Bir değişiklik dalı oluşturup ana dalı doğrudan değiştirmeden ilerle.
Gönderilen kayıtların web arayüzündeki geçmişte göründüğünü kontrol et.
Uygulama: unittest ile normal ve sınır değer testleri yaz.
Kontrol: YAML dosyası ile runner farkını biliyorum.

Videoyla adım adım izle · 3:20
Türkçe açıklamalı sessiz görsel anlatım. Sesli ders veya kesintisiz ekran kaydı değildir. Duraklatıp kendi ortamında uygula.
Video bölümleri ve tam metin
Projeyi gönder
Yerel depodaki remote adresini doğrula; uygun dala gönder.
İşin mantığı
Bir değişiklik dalı oluşturup ana dalı doğrudan değiştirmeden ilerle.
Uygula ve gözlemle
Gönderilen kayıtların web arayüzündeki geçmişte göründüğünü kontrol et.
Komut / kod · 1
Önce komutun ne yapacağını oku; işletim sistemi farklarını yazılı rehberde kontrol et.
Kod
git remote add origin https://gitlab.com/kullanici-adin/proje.git
git push -u origin mainSomut görev
unittest ile normal ve sınır değer testleri yaz.
Kontrol et
YAML dosyası ile runner farkını biliyorum.
Takılırsan
Yerelde geçiyor CI’da kalıyor — Çalışma dizini, dil sürümü, bağımlılıklar ve ortam değişkenlerini karşılaştır.
Kendine sor
YAML dosyası bulunması pipeline’ın geçtiğini kanıtlar mı? Yanıt: Hayır; işin çalışması ve sonuç günlüğü ayrıca görülmelidir.
Otomatik test (CI/CD)
Projeye .gitlab-ci.yml adında bir dosya eklersen GitLab her gönderimde içindeki komutları otomatik çalıştırır:
test:
script:
- echo "Testler çalışıyor..."
.gitlab-ci.yml işlerin tarifidir; kendisi çalıştırıcı değildir.
Önce tek job içinde küçük bir komut çalıştır; sonra gerçek test ekle.
Job günlüğünü aç; hangi ortamda hangi komutun çalıştığını ve neden bittiğini oku.
Uygulama: Yerelde python -m unittest komutunu çalıştır.
Kontrol: Job günlüğünü okuyabiliyorum.

Videoyla adım adım izle · 3:20
Türkçe açıklamalı sessiz görsel anlatım. Sesli ders veya kesintisiz ekran kaydı değildir. Duraklatıp kendi ortamında uygula.
Video bölümleri ve tam metin
Otomatik test (CI/CD)
.gitlab-ci.yml işlerin tarifidir; kendisi çalıştırıcı değildir.
İşin mantığı
Önce tek job içinde küçük bir komut çalıştır; sonra gerçek test ekle.
Uygula ve gözlemle
Job günlüğünü aç; hangi ortamda hangi komutun çalıştığını ve neden bittiğini oku.
Komut / kod · 1
Önce komutun ne yapacağını oku; işletim sistemi farklarını yazılı rehberde kontrol et.
Kod
test:
script:
- echo "Testler çalışıyor..."Somut görev
Yerelde python -m unittest komutunu çalıştır.
Kontrol et
Job günlüğünü okuyabiliyorum.
Takılırsan
Secret gerekti — Kodu sırla doldurma; hizmetin korumalı değişken ve yetki modelini belgelerden öğren.
Kendine sor
Merge request neden yararlı? Yanıt: Değişikliği, test sonucunu ve inceleme tartışmasını bir yerde toplar.
Görevleri takip et
Issues bölümünden yapılacak işleri ve hataları kaydedip ekip arkadaşlarına atayabilirsin.
Bir issue içinde beklenen davranışı ve kabul ölçütünü yaz.
Daldaki düzeltmeyi merge request ile issue’ya bağla.
Testin sonucu, değişiklik farkı ve açıklama birlikte incelenir; tek başına yeşil pipeline’a dayanma.
Uygulama: Örnek .gitlab-ci.yml içinde bir Python ortamı ve test komutu tanımla.
Kontrol: Başarısız bir testin pipeline sonucuna etkisini gördüm.

Videoyla adım adım izle · 2:55
Türkçe açıklamalı sessiz görsel anlatım. Sesli ders veya kesintisiz ekran kaydı değildir. Duraklatıp kendi ortamında uygula.
Video bölümleri ve tam metin
Görevleri takip et
Bir issue içinde beklenen davranışı ve kabul ölçütünü yaz.
İşin mantığı
Daldaki düzeltmeyi merge request ile issue’ya bağla.
Uygula ve gözlemle
Testin sonucu, değişiklik farkı ve açıklama birlikte incelenir; tek başına yeşil pipeline’a dayanma.
Somut görev
Örnek .gitlab-ci.yml içinde bir Python ortamı ve test komutu tanımla.
Kontrol et
Başarısız bir testin pipeline sonucuna etkisini gördüm.
Takılırsan
Secret gerekti — Kodu sırla doldurma; hizmetin korumalı değişken ve yetki modelini belgelerden öğren.
Kendine sor
Merge request neden yararlı? Yanıt: Değişikliği, test sonucunu ve inceleme tartışmasını bir yerde toplar.
Sık karşılaşılan sorunlar ve çözümleri
Bir yerde takılırsan önce buraya bak.
Pipeline kırmızı (başarısız) oldu
Çözüm: Başarısız olan işe (job) tıkla ve kayıtlarını oku; hata mesajı orada yazar.
Gönderim reddediliyor
Çözüm: Ana dal (main) korumalı olabilir. Yeni bir dal açıp oraya gönder ve merge request oluştur.
Sık sorulan sorular
GitHub mı, GitLab mı? +
Bireysel projeler ve açık kaynak için GitHub daha yaygın. Kendi sunucusunu isteyen şirketler ve güçlü CI/CD arayanlar GitLab'ı tercih edebilir. İkisinin mantığı aynı.
İpuçları
- GitHub biliyorsan GitLab'a geçmek çok kolay; mantık aynı.
- Bir projeyi GitHub'dan tek seferde aktarabilirsin: New project → Import project.
- CI/CD öğrenmek için GitLab'ın hazır şablonlarından başla.
GitLab uygulamalı eğitim atölyesi
GitLab, Git depolarını görev takibi ve CI/CD süreçleriyle bir araya getirir. Kaynak kodu depolamak ile testlerin çalışmasını otomatikleştirmek ayrı katmanlardır. İlk çalışmada bir dosya, bir dal ve küçük bir test akışıyla bu parçaları birbirine bağlayacağız.
Pipeline, bir iş akışının aşamalarını; job ise çalıştırılacak belirli işi tanımlar. Runner bu işi yürüten ortamdır. Bir YAML dosyasının depoda bulunması testin gerçekten çalıştığını kanıtlamaz; iş günlüğü ve çıkış durumunu görmelisin.
Merge request değişikliği incelemeye açar. Başarılı pipeline bir kalite sinyalidir ama doğru ürün davranışının tek kanıtı değildir. Ne test ettiğini ve neyi kapsam dışında bıraktığını açıklamak, yalnızca yeşil işaret görmeyi hedeflemekten daha öğreticidir.
Kurulum öncesi ve doğrulama
- GitLab hesabı veya erişebildiğin bir örnek alan olsun.
- Sır içermeyen küçük bir depo seç.
- Pipeline çalıştırmak için runner erişimi ve hizmet koşullarını kendi hesabında kontrol et; ücretli kaynak başlatma gerekliliğini varsayma.

Videoyla adım adım izle · 5:00
Türkçe açıklamalı sessiz görsel anlatım. Sesli ders veya kesintisiz ekran kaydı değildir. Duraklatıp kendi ortamında uygula.
Video bölümleri ve tam metin
Küçük bir Python fonksiyonu için test pipeline’ı
GitLab, Git depolarını görev takibi ve CI/CD süreçleriyle bir araya getirir. Kaynak kodu depolamak ile testlerin çalışmasını otomatikleştirmek ayrı katmanlardır. İlk çalışmada bir dosya, bir dal ve küçük bir test akışıyla bu parçaları birbirine bağlayacağız.
Hazırlık
GitLab hesabı veya erişebildiğin bir örnek alan olsun. Sır içermeyen küçük bir depo seç.
Proje adımı 1
İki sayıyı toplayan küçük bir Python dosyası oluştur.
Proje adımı 2
unittest ile normal ve sınır değer testleri yaz.
Proje adımı 3
Yerelde python -m unittest komutunu çalıştır.
Proje adımı 4
Örnek .gitlab-ci.yml içinde bir Python ortamı ve test komutu tanımla.
Proje adımı 5
Pipeline’ın gerçekten çalıştığını ve test çıktısını iş günlüğünden doğrula.
Proje adımı 6
Bir testi bilinçli boz; kırmızı sonucun nedenini düzelt ve merge request açıklamasına yaz.
Başarı ölçütü 1
Proje ve dal hedefleri doğru.
Başarı ölçütü 2
YAML dosyası ile runner farkını biliyorum.
Başarı ölçütü 3
Job günlüğünü okuyabiliyorum.
Başarı ölçütü 4
Başarısız bir testin pipeline sonucuna etkisini gördüm.
Bitirme çalışması: Küçük bir Python fonksiyonu için test pipeline’ı
- İki sayıyı toplayan küçük bir Python dosyası oluştur.
- unittest ile normal ve sınır değer testleri yaz.
- Yerelde python -m unittest komutunu çalıştır.
- Örnek .gitlab-ci.yml içinde bir Python ortamı ve test komutu tanımla.
- Pipeline’ın gerçekten çalıştığını ve test çıktısını iş günlüğünden doğrula.
- Bir testi bilinçli boz; kırmızı sonucun nedenini düzelt ve merge request açıklamasına yaz.
Başarı ölçütlerin
- Proje ve dal hedefleri doğru.
- YAML dosyası ile runner farkını biliyorum.
- Job günlüğünü okuyabiliyorum.
- Başarısız bir testin pipeline sonucuna etkisini gördüm.
Sorun giderme masası
Job beklemede
Runner erişimi, etiketler ve hesap kotalarını kontrol et; YAML sözdizimi tek neden değildir.
Yerelde geçiyor CI’da kalıyor
Çalışma dizini, dil sürümü, bağımlılıklar ve ortam değişkenlerini karşılaştır.
Secret gerekti
Kodu sırla doldurma; hizmetin korumalı değişken ve yetki modelini belgelerden öğren.
Kendini kontrol et
Runner ne yapar?
Pipeline işlerini gerçek bir çalıştırma ortamında yürütür.
YAML dosyası bulunması pipeline’ın geçtiğini kanıtlar mı?
Hayır; işin çalışması ve sonuç günlüğü ayrıca görülmelidir.
Merge request neden yararlı?
Değişikliği, test sonucunu ve inceleme tartışmasını bir yerde toplar.
Bir sonraki modüller
- Pipeline aşamaları ve artifacts
- Merge request inceleme
- Korunan dallar ve değişkenler
Bu içerik işine yaradı mı?
Görüşünü aşağıdan işaretleyebilir ve varsa notunu bırakabilirsin.