GitLab nedir ve Git ile nasıl kullanılır: clone, push, merge request, CI/CD

GitLab nedir

GitLab, Git repository'lerinin tutulduğu ve ekip çalışmasının etrafında kurulduğu bir platformdur: kod incelemesi, merge request (birleştirme talebi), görevler, wiki, konteyner kayıt defteri ve yerleşik CI/CD. Kısaca GitLab, «kendi derleme hattı olan ve isterseniz kendi sunucunuzda da kurabileceğiniz bir GitHub» gibidir. Pek çok şirket, Türkiye'de de, kodunu iç ağa kurulan GitLab'da tutar.

Proje 2011'de kod barındırmak için açık kaynaklı bir uygulama olarak başladı; ardından etrafında GitLab Inc. şirketi kuruldu. Platform iki sürümde bulunur: açık kaynak olan ve kendi sunucunuza ücretsiz kurabileceğiniz Community Edition ile ücretli özellikleri olan Enterprise Edition. Bulut servisi gitlab.com'da planlar Free, Premium ve Ultimate olarak adlandırılır.

Kavramları karıştırmamak önemlidir. Git, bilgisayarınızda çalışan bir sürüm kontrol sistemidir. GitLab ise repository'nin uzak bir kopyasını barındıran ve ekip için arayüz ile araçlar ekleyen bir servistir. Git olmadan GitLab ile çalışamazsınız, ama GitLab olmadan da Git gayet iyi çalışır.

Git ve GitLab arasındaki fark

«Git ve gitlab nedir» diye arayanlar genellikle bir iş ilanında ya da işe başladıkları ilk günde iki kelimeyle karşılaşır. Fark, bir belgeyle bulut depolama hizmeti arasındaki fark gibidir: Git dosya değişikliklerini, commit geçmişini ve dalları yerelde izler. GitLab bu geçmişi ağ üzerinden alır ve tarayıcıda gösterir.

Kodla ilgili tüm işlemleri (commit, branch, merge) hâlâ Git ile yaparsınız. GitLab, sonucu git push ile alır ve meslektaşlarınızla tartışmanızı sağlar.

GitLab ve GitHub arasındaki farklar

İki servis de Git repository'lerini tutar ve kod incelemesini destekler; bu yüzden temel becerileriniz neredeyse aynen taşınır. Farklar vurgularda ve kurulum modelindedir.

Pratikte bir geliştirici çoğu zaman ikisini birden kullanır: kişisel projeler ve portföy GitHub'da, kurumsal iş kodu şirketin GitLab'ında. Git komutları aynıdır; değişen yalnızca uzak repository'nin adresidir.

gitlab.com mu, kendi sunucu mu (self-hosted)

Bulut servisi gitlab.com kişisel projeler ve küçük ekipler için uygundur: kaydolursunuz ve hemen repository oluşturursunuz. Güncellemeler, yedekleme ve erişilebilirlik GitLab'ın sorumluluğundadır. Ücretsiz paketin sınırları (katılımcı sayısı, CI dakikası, depolama alanı) zaman zaman değişir; güncel koşullar için plan sayfasına bakın.

Self-hosted GitLab, şirketin kendi sunucusuna kurduğu sürümdür: Linux paketi, Docker veya Kubernetes ile. Kod iç ağdan çıkmaz, LDAP ile kurumsal girişe bağlanabilir ve derlemeler için kendi runner'larınızı kurabilirsiniz. Karşılığında yönetici güncellemelerden ve yedeklerden sorumludur. Geliştirici için fark neredeyse görünmezdir: adres gitlab.com olmaz, örneğin gitlab.sirket.com.tr olur.

GitLab için Git yapılandırması

İlk commit'ten önce ad ve e-posta ayarlayın: bunlar geçmişe yazılır ve GitLab commit'leri e-posta üzerinden profilinize bağlar.

git config --global user.name "Ali Yılmaz"
git config --global user.email "ali@example.com"

Windows'ta Git Bash'te çalışmak uygundur: Git for Windows ile birlikte kurulur ve ssh-keygen içerir, dolayısıyla bu yazıdaki tüm komutlar değişiklik gerekmeden çalışır. Ardından erişim yöntemini seçin: token ile HTTPS ya da SSH anahtarı.

HTTPS ile giriş: personal access token

Git'in HTTPS işlemleri için hesap parolasını kullanmamanız önerilir; iki faktörlü doğrulama açıksa zaten çalışmaz. Bunun yerine GitLab profil ayarlarındaki Access tokens bölümünde bir personal access token oluşturun. Kodla çalışmak için read_repository ve write_repository izinleri yeterlidir; bir son kullanma tarihi belirleyin ve token'ı hemen kaydedin, çünkü bir daha gösterilmez.

İlk push'ta veya clone'da Git kullanıcı adı ve parola sorar: GitLab kullanıcı adınızı girin, parola yerine token'ı yazın. Kimlik bilgisi yöneticisi (Git for Windows ile gelir) bunu hatırlar, tekrar girmeniz gerekmez.

SSH anahtarıyla giriş

SSH günlük kullanım için daha rahattır: anahtarı bir kez ekleyin, bundan sonra hiçbir şey yazmanız gerekmez.

ssh-keygen -t ed25519 -C "ali@example.com"
cat ~/.ssh/id_ed25519.pub

.pub dosyasının içeriğini (genel anahtar) GitLab profil ayarlarında SSH Keys bölümüne yapıştırın. Bağlantıyı şöyle test edebilirsiniz:

ssh -T git@gitlab.com
Welcome to GitLab, @ali.yilmaz!

GitLab git clone: repository nasıl klonlanır

Proje sayfasında SSH ve HTTPS için iki adres içeren bir Code düğmesi vardır. İstediğinizi kopyalayın ve git clone çalıştırın:

# HTTPS ile
git clone https://gitlab.com/my-group/my-project.git

# SSH ile
git clone git@gitlab.com:my-group/my-project.git

GitLab'da proje yolu alt grupları içerebilir, örneğin gitlab.com/company/backend/api.git; bu normaldir, adresi olduğu gibi kopyalayın.

Token ile GitLab git clone

Birinin parola girebileceği bir yer olmayan betiklerde ve sunucularda token doğrudan adreste verilir. Kullanıcı adı olarak GitLab kullanıcı adınızı ya da hizmet adı oauth2'yi kullanabilirsiniz:

git clone https://oauth2:TOKEN_BURAYA@gitlab.com/my-group/my-project.git

Dikkat: böyle bir adres .git/config dosyasına kaydedilir ve komut geçmişine düşebilir. Otomasyon için en az izinli, süreli bir deploy token ya da project access token kullanın; CI içinde ise yerleşik CI_JOB_TOKEN değişkenini tercih edin.

GitLab'a git push: kodu gönderme

Proje zaten yerelde varsa, GitLab'da boş bir proje oluşturun (ekstra commit olmasın diye README eklemeden) ve uzak repository'yi bağlayın:

git remote add origin git@gitlab.com:my-group/my-project.git
git branch -M main
git push -u origin main

Bayrak -u yerel dalı uzak dala bağlar; bundan sonra git push ve git pull yazmanız yeterlidir. Günlük döngü diğer servislerle aynıdır:

git switch -c feature/login
git add .
git commit -m "Giriş formunu ekle"
git push -u origin feature/login
git pull

Etiketler ayrıca gönderilir: git push origin v1.2.0 ya da hepsini birden git push --tags. GitLab'da etiketler Tags bölümünde görünür ve çoğu zaman bir yayın hattını başlatır.

GitLab git push sırasında sık görülen hatalar

• HTTP Basic: Access denied — kullanıcı adı yanlış ya da token yerine parola girilmiş. write_repository yetkisi olan bir token oluşturun ve kimlik bilgisi yöneticisindeki eski kaydı silin.
• Permission denied (publickey) — GitLab SSH anahtarınızı tanımıyor. Genel anahtarın profilinizde olduğunu kontrol edin ve ssh -T git@gitlab.com komutunu çalıştırın.
• You are not allowed to push code to protected branches — dal (genellikle main) korumalıdır. Değişikliklerinizi kendi dalınıza gönderin ve bir merge request açın.
• rejected ... (fetch first) — sunucuda sizde olmayan commit'ler var. git pull --rebase çalıştırıp push'u tekrarlayın.
• remote: Project not found — adreste yazım hatası var ya da projeye erişiminiz yok; rolünüzü proje sahibinden öğrenin.

GitLab'da merge request

Merge request, GitHub'daki pull request'in karşılığıdır: dalınızı ana dala birleştirme talebidir. Kod satırlarına yorum yazılan, CI kontrollerinin çalıştığı ve birleştirme kararının verildiği yer burasıdır. Yeni bir dalı push ettikten sonra GitLab terminalde MR oluşturma bağlantısını gösterir; web arayüzünde de MR oluşturma önerisi çıkar.

MR'ı doğrudan komut satırından push seçenekleriyle de oluşturabilirsiniz:

git push -o merge_request.create -o merge_request.target=main origin feature/login

Tipik akış şöyledir: görev için dal → commit'ler → push → MR → inceleme ve yeşil pipeline → merge. Birleştirmede GitLab commit'leri tek bir commit'te toplayabilir (squash) ve kaynak dalı silebilir. MR'da çakışma varsa en basit çözüm, dalı yerelde git pull --rebase origin main ya da git merge main ile güncellemek, çakışmaları çözmek ve tekrar push etmektir.

Bitmemiş işleri Draft olarak işaretleyin: böyle bir MR yanlışlıkla birleştirilemez, ama meslektaşlarınız değişiklikleri görüp tartışabilir.

GitLab'da CI/CD: .gitlab-ci.yml

GitLab'ın öne çıkan özelliği yerleşik CI/CD'dir. Repository'nin köküne bir .gitlab-ci.yml dosyası koymanız yeterlidir: her push'ta GitLab, aşamalardan (stages) ve işlerden (jobs) oluşan bir pipeline başlatır. İşleri runner'lar çalıştırır: gitlab.com'da ortak runner'lar vardır, kendi sunucunuzda bunları ayrıca kurmanız gerekir.

stages:
  - test
  - deploy

test:
  stage: test
  image: python:3.12
  script:
    - pip install -r requirements.txt
    - pytest

deploy:
  stage: deploy
  script:
    - ./deploy.sh
  rules:
    - if: $CI_COMMIT_TAG

Bu örnekte testler her push'ta çalışır, deploy işi ise yalnızca bir etiket gönderildiğinde başlar: git tag v1.0.0 ve git push origin v1.0.0. Pipeline sonuçları doğrudan merge request içinde görünür; kontroller geçmeden birleştirmeyi engelleyebilirsiniz.

GitLab'da repository nasıl silinir

Git komutları sunucudaki bir projeyi silemez: git push yalnızca dalları ve etiketleri değiştirir. Proje web arayüzünden silinir: proje ayarları, General bölümü, Advanced bloğu ve onay adını yazmanızı isteyen silme düğmesi. Owner rolü gerekir. Yerel kopya kalır; bu yalnızca .git içeren bir klasördür.

Yerel repository'yi sunucudaki hiçbir şeyi silmeden GitLab'dan ayırmak istiyorsanız git remote remove origin yeterlidir.

Ne zaman GitLab seçilmeli

• Kodun dış bir bulut servisine çıkamaması ve kendi sunucunuza ihtiyaç duyulması.
• Üçüncü taraf servislere ihtiyaç duymadan hazır bir CI/CD istenmesi.
• Ekip hiyerarşisi olan büyük bir kurum; iç içe gruplar ve esnek roller işe yarar.
• GitLab kullanan bir şirkete katılıyorsanız: bu durumda seçim zaten yapılmıştır, ama Git becerileriniz tamamen taşınır.

Portföy ve açık kaynak için genellikle GitHub tercih edilir: topluluğu daha geniştir ve projeler daha görünürdür. Aynı projeyi iki serviste de tutmanızda bir engel yoktur; bir repository'nin birden fazla remote'u olabilir.

Sonuç

GitLab, Git repository'leri için merge request tabanlı inceleme, görevler ve yerleşik CI/CD sunan bir platformdur; hem bulutta hem de kendi sunucunuzda çalışır. Onunla çalışmak tanıdık komutlara indirgenir: token veya SSH anahtarıyla girişi ayarlayın, sonra clone, commit, push ve merge request. Uzak repository'ler ve ekip süreçleri Git kursunda uygulamalı olarak ele alınmaktadır.