Git Kurulumu ve İlk Depo Oluşturma: Adım Adım Rehber

Yazar:komut.io ekibi
0 Yorum

Bir gün üretim sunucusuna bağlandığınızda, bir önceki sistem yöneticisinin bıraktığı konfigürasyon dosyalarının üzerine yazılmış olduğunu fark etmek, insanın içini burkan o anlardan biridir. “Bir önceki hali nasıldı?” sorusunun cevabı yoktur, çünkü sürüm kontrolü yoktur. Git’i ilk kez bu yüzden sevdim: geçmişe dönebilmek için.

Bu yazıda Git kurulumundan başlayarak ilk deponuzu oluşturana kadar her adımı, gerçek bir ortamda karşılaşacağınız detaylarla anlatacağım. Ekran görüntüsü yerine terminal çıktıları, teori yerine pratik.

Git Neden Sistem Yöneticileri İçin Kritik?

Uygulama geliştiriciler Git’i kod için kullanır, biz sysadmin’ler ise konfigürasyon dosyaları, script’ler, Ansible playbook’ları, Terraform planları ve daha fazlası için kullanırız. Bir Nginx konfigürasyonunu değiştirip servisi çökerttikten sonra “bir önceki haline nasıl dönerim?” diye düşünüyorsanız, cevap Git’tir.

Infrastructure as Code (IaC) yaklaşımı artık bir tercih değil, zorunluluk. Bu yaklaşımın temel taşı da sürüm kontrolü. Dolayısıyla Git öğrenmek, sysadmin kariyerinizde ilerlemek istiyorsanız erteleyebileceğiniz bir konu değil.

Kurulum: Hangi Platform, Hangi Yol?

Linux Üzerinde Git Kurulumu

Çoğu modern Linux dağıtımında Git paket depolarında hazır gelir. Yine de elle kurulum yapmak, özellikle güncel sürümü almak istediğinizde gerekli olabilir.

Debian / Ubuntu tabanlı sistemler:

sudo apt update
sudo apt install git -y
git --version

RHEL / CentOS / AlmaLinux / Rocky Linux:

sudo dnf install git -y
# CentOS 7 için hâlâ yum kullananlar:
sudo yum install git -y
git --version

Fedora:

sudo dnf install git -y

Eğer dağıtımınızın deposundaki Git sürümü eskiyse ve güncel bir sürüm istiyorsanız, kaynak koddan derleme yapabilirsiniz. Ancak bu durum genellikle gerekmez; production sunucularda paket yöneticisi üzerinden gelen sürüm çoğunlukla yeterlidir.

Kurulumu doğrulamak için:

git --version
# Örnek çıktı:
# git version 2.43.0

Windows Üzerinde Git Kurulumu

Windows tarafında iki ana seçeneğiniz var: Git for Windows (msysgit) veya WSL (Windows Subsystem for Linux) üzerinden Git.

Git for Windows tercih ediyorsanız:

https://git-scm.com/download/win adresinden indirip kurabilirsiniz. Kurulum sırasında dikkat edilmesi gereken birkaç nokta var:

  • Default editor: Nano veya Vim’den birini seçin; Vim bilmiyorsanız Nano daha güvenli.
  • PATH environment: “Git from the command line and also from 3rd-party software” seçeneğini işaretleyin.
  • Line ending: Windows’ta çalışıyorsanız “Checkout Windows-style, commit Unix-style” seçeneği genellikle en sağlıklı olanı.

WSL kullanıyorsanız (ki tavsiye ederim), WSL terminal açıp yukarıdaki Linux komutlarını çalıştırmanız yeterli.

macOS için:

# Homebrew ile:
brew install git

# Xcode Command Line Tools ile (zaten yüklüyse):
xcode-select --install

İlk Yapılandırma: Kimliğinizi Tanıtın

Git’i kurduktan sonra ilk yapmanız gereken şey kimlik bilgilerinizi tanımlamak. Bu bilgiler her commit’e yazılır ve ekip ortamında kimin ne yaptığını anlamak için kritiktir.

git config --global user.name "Ahmet Yilmaz"
git config --global user.email "[email protected]"

--global bayrağı bu ayarların sistemdeki tüm repolar için geçerli olacağı anlamına gelir. Belirli bir proje için farklı kimlik kullanmak isterseniz (örneğin açık kaynak katkıları için kişisel mailinizi kullanmak), o projenin dizininde --global olmadan aynı komutu çalıştırabilirsiniz.

Varsayılan metin editörünü ayarlayalım:

# Nano tercih edenler için:
git config --global core.editor nano

# Vim kullanıyorsanız zaten varsayılan, ama yine de açıkça belirtmek isterseniz:
git config --global core.editor vim

Branch adlandırması konusunda güncel Git versiyonları sizi master yerine main kullanmaya yönlendirebilir. Bunu global olarak ayarlamak için:

git config --global init.defaultBranch main

Tüm ayarlarınızı görmek için:

git config --list
# Belirli bir ayarı sorgulamak için:
git config user.email

Bu ayarlar ~/.gitconfig dosyasına yazılır. Merak edip direkt bakabilirsiniz:

cat ~/.gitconfig

Çıktı şöyle görünecek:

[user]
    name = Ahmet Yilmaz
    email = [email protected]
[core]
    editor = nano
[init]
    defaultBranch = main

İlk Depoyu Oluşturmak: git init

Teoriyi bir kenara bırakın, hemen pratiğe geçelim. Bir sysadmin senaryosu üzerinden gidelim: Sunucu konfigürasyonlarınızı ve yönetim script’lerinizi takip altına alacaksınız.

# Çalışma dizini oluşturup içine girelim:
mkdir ~/sunucu-konfigurasyon
cd ~/sunucu-konfigurasyon

# Git deposunu başlatalım:
git init

Çıktı şöyle olacak:

Initialized empty Git repository in /home/ahmet/sunucu-konfigurasyon/.git/

.git dizini oluştu. Bu dizin Git’in beynidir: tüm commit geçmişi, branch bilgileri, konfigürasyonlar burada saklanır. Bu dizini asla elle silmeyin veya içini karıştırmayın. Silinirse repodaki tüm geçmişi kaybedersiniz.

ls -la
# .git dizinini göreceksiniz
ls -la .git/
# HEAD, config, description, hooks/, info/, objects/, refs/ gibi dizin ve dosyalar

İlk Dosyaları Eklemek ve İlk Commit

Şimdi biraz içerik oluşturalım. Gerçek dünyada ne kullanırsak onu kullanalım:

# Basit bir README dosyası:
cat > README.md << 'EOF'
# Sunucu Konfigürasyon Deposu

Bu depo, üretim ve test sunucularımıza ait konfigürasyon dosyaları ve
yönetim script'lerini içermektedir.

## Dizin Yapısı

- /nginx: Nginx konfigürasyonları
- /scripts: Yönetim ve bakım script'leri
- /monitoring: İzleme araçları konfigürasyonları
EOF

# Bir dizin yapısı ve örnek dosya oluşturalım:
mkdir -p nginx scripts monitoring

cat > nginx/nginx.conf.example << 'EOF'
worker_processes auto;
events {
    worker_connections 1024;
}
http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;
}
EOF

Şimdi Git’in bu dosyaları nasıl gördüğüne bakalım:

git status

Çıktı:

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    README.md
    nginx/
    scripts/
    monitoring/

nothing added to commit but untracked files present (use "git add" to track)

Untracked files yani Git’in henüz takip etmediği dosyalar. Bunları staging area’ya (hazırlık alanına) almamız gerekiyor:

# Tüm dosyaları staging area'ya ekle:
git add .

# Ya da tek tek eklemek isterseniz:
git add README.md
git add nginx/nginx.conf.example

git status çıktısı artık değişti:

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   README.md
    new file:   nginx/nginx.conf.example

Şimdi ilk commit’i yapalım:

git commit -m "ilk commit: README ve nginx ornek konfigurasyon eklendi"

Çıktı:

[main (root-commit) a1b2c3d] ilk commit: README ve nginx ornek konfigurasyon eklendi
 2 files changed, 25 insertions(+)
 create mode 100644 README.md
 create mode 100644 nginx/nginx.conf.example

Tebrikler, ilk commit’iniz tamamlandı.

Commit Mesajları: Küçük Ama Kritik Bir Konu

Commit mesajları konusunda biraz durmak istiyorum çünkü bu konuda gereksiz yere özensiz davranıldığını sıkça görüyorum.

Kötü commit mesajı örnekleri:

  • “düzeltme”
  • “update”
  • “asdfgh”
  • “bi şeyler değişti”

İyi commit mesajı nasıl olmalı? Kısa ama açıklayıcı. Neyi değiştirdiğinizi değil, neden değiştirdiğinizi anlatmalı:

  • “nginx: SSL sertifika yenileme sonrasi konfigurasyon guncellendi”
  • “backup-script: hata durumunda Slack bildirimi eklendi”
  • “monitoring: disk doluluk esigi yuzde 85ten yuzde 90a cikarildi”

Üç ay sonra o commit’e baktığınızda ne değiştiğini değil, neden değiştiğini anlayabilmeniz gerekir. Çünkü dosyada ne değiştiğini git diff ile zaten görebilirsiniz.

.gitignore: Takip Etmek İstemediklerinizi Belirtin

Her dosyanın Git’te takip edilmesi gerekmez. Geçici dosyalar, log dosyaları, şifreler (evet, lütfen şifreleri commit etmeyin) veya sistem dosyaları bunların başında gelir.

cat > .gitignore << 'EOF'
# Log dosyalari
*.log
logs/

# Geçici dosyalar
*.tmp
*.bak
*.swp

# Hassas bilgiler
*.key
*.pem
secrets/
.env

# OS dosyalari
.DS_Store
Thumbs.db

# Editor dizinleri
.vscode/
.idea/
EOF

git add .gitignore
git commit -m "gitignore: log, gecici ve hassas dosyalar eklendi"

Önemli uyarı: .env veya şifre dosyalarını bir kez bile commit ettiyseniz, sonradan .gitignore‘a eklemek o dosyayı geçmişten silmez. Geçmişten silmek için git filter-branch veya BFG Repo Cleaner gibi araçlara ihtiyaç duyarsınız. Bu yüzden baştan dikkatli olmak çok önemli.

Var Olan Bir Klasörü Git Deposuna Dönüştürmek

Bazen mevcut bir script klasörünüzü Git kontrolüne almak istersiniz. Bu da git init ile yapılır, sadece boş dizin yerine içi dolu bir dizinde çalışırsınız:

cd /etc/nginx
# Dikkat: production'da direkt /etc altında çalışmak yerine kopyasında deneyin
git init
git add nginx.conf sites-available/ snippets/
git commit -m "nginx: mevcut konfigurasyon ilk kez git kontrolune alindi"

Burada dikkat edilmesi gereken nokta: /etc/nginx altındaki tüm dosyaları git add . ile eklemek yerine, yönetmek istediğiniz dosyaları seçerek ekleyin. Dinamik olarak değişen veya hassas bilgi içeren dosyaları eklemekten kaçının.

Depo Geçmişini İncelemek

Birkaç commit yaptıktan sonra geçmişe bakmak isteyeceksiniz:

git log

Uzun ve ayrıntılı çıktı gelir. Daha okunabilir bir format için:

git log --oneline
# Çıktı örneği:
# b3c4d5e gitignore: log, gecici ve hassas dosyalar eklendi
# a1b2c3d ilk commit: README ve nginx ornek konfigurasyon eklendi

git log --oneline --graph
# Branch yapısını görsel olarak gösterir

Bir dosyanın geçmişini görmek için:

git log --oneline -- nginx/nginx.conf.example

Belirli bir commit’te ne değiştiğini görmek için:

git show a1b2c3d
# Ya da en son commit:
git show HEAD

Uzak Depo Bağlantısı: GitHub veya Self-Hosted GitLab

Yerel depo güzel, ama bir sunucu çöktüğünde ne olur? Uzak depo (remote repository) bu sorunu çözer ve ekip çalışmasını mümkün kılar.

GitHub, GitLab veya Bitbucket üzerinde bir depo oluşturduktan sonra yerel deponuzu bağlayabilirsiniz:

# Uzak depoyu ekle:
git remote add origin https://github.com/kullaniciadi/sunucu-konfigurasyon.git

# Bağlantıyı doğrula:
git remote -v

# Yerel commit'leri uzak depoya gönder:
git push -u origin main

-u bayrağı bu push işlemini varsayılan upstream olarak kaydeder. Bir sonraki seferinde sadece git push yazmanız yeterli olur.

Kurumsal ortamlarda self-hosted GitLab çok daha yaygın tercih edilir, çünkü kodunuz kendi sunucularınızda kalır. Bağlantı aynı şekilde çalışır, sadece URL farklı olur:

git remote add origin https://gitlab.sirket.local/ops/sunucu-konfigurasyon.git

SSH ile Kimlik Doğrulama

HTTPS yerine SSH kullanmak, parola girmekten kurtarır ve daha güvenlidir. Önce SSH anahtarı oluşturun:

# SSH anahtar çifti oluştur:
ssh-keygen -t ed25519 -C "[email protected]"
# Dosya yolunu ve passphrase'i soracak, varsayılanları kabul edebilirsiniz

# Public anahtarı görüntüle ve kopyala:
cat ~/.ssh/id_ed25519.pub

Bu public anahtarı GitHub/GitLab hesabınızın SSH Keys bölümüne yapıştırın. Ardından remote URL’yi SSH formatına çevirin:

git remote set-url origin [email protected]:kullaniciadi/sunucu-konfigurasyon.git

# Bağlantıyı test et:
ssh -T [email protected]
# "Hi kullaniciadi! You've successfully authenticated..." mesajını görmelisiniz

Sık Karşılaşılan Sorunlar ve Çözümleri

“Please tell me who you are” hatası:

git config --global user.email "[email protected]"
git config --global user.name "Adiniz"

Yanlış dosyayı staging’e eklediyseniz:

git restore --staged dosya_adi.txt
# Eski Git versiyonlarında:
git reset HEAD dosya_adi.txt

Son commit mesajını değiştirmek istiyorsanız (henüz push etmediyseniz):

git commit --amend -m "duzeltilmis commit mesaji"

Bir dosyayı son commit’teki haline döndürmek:

git restore dosya_adi.txt
# Eski versiyon:
git checkout -- dosya_adi.txt

Sonuç

Git kurulumu ve ilk depo oluşturma aslında teknik olarak basit adımlar. Asıl önemli olan bu alışkanlığı sistematik hale getirmek: her konfigürasyon değişikliği bir commit, her script güncellemesi bir commit, her önemli değişiklik önce bir branch.

Sistem yöneticisi olarak Git’i benimsemek, “bir şeyleri bozduk ve geri dönemiyoruz” krizlerini büyük ölçüde ortadan kaldırır. Bir Nginx konfigürasyonu mı çöktü? git diff ile neyin değiştiğini görün, git restore ile geri dönün. Bir backup script’i beklenmedik davranmaya başladı mı? Geçmiş commit’lere bakın, kim ne zaman ne değiştirmiş anlayın.

Bundan sonraki adım olarak branch kullanımını, git merge ve git rebase kavramlarını incelemenizi tavsiye ederim. Ama önce bugün anlattıklarımı bir sunucunuzda uygulayın. Öğrenmenin en iyi yolu hâlâ yaparak öğrenmek.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir