Git ve GitHub Arasındaki Fark Nedir? VPS Kullanımı

GitHub nedir?

GitHub, Git depolarını barındıran ve bu depolar etrafında bir web sitesi oluşturan bir hizmettir. Git, kendi bilgisayarınızda veya kendi sunucunuzda çalışan sürüm kontrol programıdır. GitHub, 2018 yılından beri Microsoft'a ait olan ve Git üzerinde çalışan bir şirketin ürünüdür. Git'i her gün kullanabilir ve GitHub'ı hiç açmayabilirsiniz. Ancak Git olmadan GitHub'ı kullanamazsınız.

Bu ayrım, bir VPS (sanal özel sunucu) sahibi olduğunuz anda önem kazanır. Git, yapılandırma dosyalarınızın ve dağıtım betiklerinizin geçmişini kaydeden araçtır. GitHub ise sunucunun kendisi dışında bu geçmişin bir kopyasının tutulduğu, ayrıca derleme ve inceleme işlemlerinin yürütüldüğü yerdir. Bu kılavuz, boş bir klasörden sunucu üzerinde bir dağıtıma kadar olan süreci tek bir örnek üzerinden takip eder ve karşılaşılan her yeni terimi ilk geçtiği yerde tanımlar.

Git'in kendi başına yaptıkları

Git bir sürüm kontrol sistemidir: bir dizinin zaman içindeki durumunu kaydeder, böylece neyin, ne zaman ve neden değiştiğini görebilirsiniz. 2005 yılında Linux çekirdeği çalışmaları için yazılmıştır. Dağıtık bir yapıdadır; bu, bir deponun her kopyasının tüm geçmişi barındırdığı anlamına gelir. Tasarımında merkezi bir sunucu yoktur. Bir iş arkadaşınızın dizüstü bilgisayarı, herhangi bir sunucu kadar eksiksiz bir kopyadır.

Git'i kurun ve kimlik bilgilerinizi ayarlayın. Git, bir commit işlemini isim ve e-posta adresi olmadan kaydetmeyi reddeder; çünkü her ikisi de commit'in içine yazılır.

sudo apt update && sudo apt install -y git
git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Ubuntu 24.04 üzerinde git --version komutu git version 2.43.0 çıktısını verir. Son birkaç yıl içindeki herhangi bir sürüm, aşağıdakilerin tamamı için aynı şekilde davranır.

Örnek: VPS dağıtım dosyalarınız için bir depo

Bir depo (repository), genellikle "repo" olarak kısaltılır, Git tarafından izlenen bir dizindir. Bir dizin, içinde gizli bir .git klasörü oluşturan git init komutunu çalıştırdığınızda depoya dönüşür. O klasör, deponun kendisidir. .git dosyasını silerseniz, elinizde geçmişi olmayan sıradan bir dizin kalır.

mkdir vps-deploy && cd vps-deploy
git init -b main
printf '.env\n*.key\n' > .gitignore

-b main, ilk dalı main olarak adlandırır. Bu komutu kullanmazsanız, Git varsayılan dal adı hakkında uzun bir ipucu yazdırır. .gitignore, Git'in asla izlememesi gereken yolları listeler. Gizli bilgilerinizi içeren dosyayı ilk günden bu listeye ekleyin; çünkü bir kez commit edilen bir dosya, silseniz bile geçmişte kalmaya devam eder ve dosyayı düzgün bir şekilde kaldırmak, ondan sonra gelen her commit'in yeniden yazılmasını gerektirir.

Commit'ler: geçmişin birimi

Şimdi bir betik ekleyin ve bunu kaydedin.

printf '#!/bin/sh\nsudo systemctl restart caddy\n' > restart.sh
git add restart.sh .gitignore
git commit -m "Add restart script and gitignore"
git log --oneline

git add, bir değişikliği bir sonraki commit'e dahil edilecek dosyaların listesi olan staging area (hazırlık alanı) içerisine taşır. git commit ise bu listeyi tek bir girdi olarak geçmişe yazar. Bir commit, takip edilen tüm dosyaların bir anlık görüntüsünü, bir mesajı, yazarı, zaman damgasını ve kendisinden önceki commit'e işaret eden bir göstericiyi barındırır. git log --oneline, her biri a1b2c3d gibi kısa bir hash ile başlayan, commit başına tek satırlık bir çıktı verir. Bu hash, commit'in adıdır ve neredeyse tüm Git komutları tarafından kabul edilir.

git add adımını atlarsanız git commit, no changes added to commit (use "git add" and/or "git commit -a") yanıtını verir. Hiçbir şey bozulmamıştır. Git, staging area'nın boş olduğunu ve dolayısıyla anlık görüntüsü alınacak bir şey bulunmadığını belirtmektedir. git status, ne yapacağınızı bilemediğiniz durumlarda çalıştırılması gereken komuttur: mevcut branch'i, hazırlanan değişiklikleri ve Git'in görebildiği ancak henüz takip etmediği dosyaları listeler.

Dallar: ikinci bir geçmiş satırı

Dal, bir commit'i işaret eden hareketli bir göstergedir. main bir daldır ve Git için herhangi bir özel durumu yoktur. Bir dal oluşturmanın maliyeti yoktur; çünkü Git dosyalarınızı kopyalamak yerine yeni bir gösterge yazar.

git switch -c add-backup
printf '#!/bin/sh\nrestic backup /srv\n' > backup.sh
git add backup.sh
git commit -m "Add nightly backup"
git switch main
ls

git switch main işleminden sonra backup.sh listede görünmez. Hiçbir şey silinmemiştir. Dosya add-backup dalında mevcuttur ve main dalında hiçbir zaman bulunmadığı için, geçiş yaptığınızda Git dosyayı çalışma dizininizden kaldırmıştır. Bu durum herkesi bir kez şaşırtır. git switch add-backup komutu dosyayı geri getirir.

Uzak depolar: GitHub'ın devreye girdiği yer

Şu ana kadar yapılan her şey, ağ bağlantısı olmayan tek bir makinede çalıştırıldı. Remote (uzak depo), aynı deponun başka bir kopyası için tanımlanmış bir URL'dir. GitHub, bu kopyalardan birini sizin için barındırır. Ana uzak depo için geleneksel isim origin olarak belirlenmiştir.

GitHub web sitesi üzerinden boş bir depo oluşturun ve ardından ona bağlanın. Burada HTTPS yerine SSH tercih edin: SSH anahtarı kontrolünüz altında olan bir dosyadır ve kişisel erişim belirteçleri (personal access token) gibi süresi dolmaz.

ssh-keygen -t ed25519 -C "vps-deploy"
cat ~/.ssh/id_ed25519.pub
ssh -T git@github.com

Ekrana yazdırılan genel anahtarı (public key) kopyalayıp GitHub hesabınızdaki SSH anahtarları sayfasına yapıştırın, ardından testi tekrar çalıştırın. Çalışan bir anahtar Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. yanıtını verir. GitHub size bir kabuk (shell) erişimi sağlamaz, bu nedenle bu reddetme işlemi başarılı olduğunuz anlamına gelir. git@github.com: Permission denied (publickey). hatası, anahtarınızın sunulmadığı veya kabul edilmediği anlamına gelir; bu durumda .pub dosyasını yapıştırdığınızdan ve yanındaki özel anahtarı (private key) kullanmadığınızdan emin olun.

git remote add origin git@github.com:yourname/vps-deploy.git
git push -u origin main

git push komutu, commit'lerinizi uzak depoya gönderir. -u komutu, yerel main dalının uzak main dalını takip ettiğini kaydeder; böylece daha sonra sadece git push komutunu çalıştırmak yeterli olur. git clone <url> komutu, yeni bir makinede bunun tersini yapar: deponun tamamını geçmişiyle birlikte kopyalar ve sizin için origin ayarını yapılandırır. HTTPS uzak depo da kullanılabilir; bu yöntem herhangi bir web sayfasıyla aynı protokol üzerinden çalışır ve 22 numaralı çıkış portunu engelleyen ağlarda yardımcı olur. Bu cümlenin detaylandırılması gerekirse, bir HTTP isteğinin aslında nelerden oluştuğu konusu mekaniği açıklamaktadır.

Pull request, issue ve fork: Git değil, GitHub olan kısımlar

Yukarıdaki her şey Git'tir ve herhangi bir sunucu üzerinde çalışır. Aşağıdaki üç terim ise GitHub özellikleridir. Diğer barındırma servisleri bunları kopyalar ve Git'in kendisi bu kavramlardan haberdar değildir.

Pull request (PR), bir branch'in diğerine birleştirilmesi için yapılan ve tartışma ortamı sunan bir istektir. add-backup push işlemini yapar, main üzerinde bir PR açarsınız; site, farkları commit bazında gösterir. İnsanlar tekil satırlara yorum yapabilir. Otomatik kontroller, branch üzerinde başarılı veya başarısız sonuçlar bildirir. Birleştirme (merge) butonuna tıkladığınızda GitHub, kendi kopyası üzerinde birleştirme işlemini gerçekleştirir ve ardından main güncellenir. Bu isim, bir maintainer'dan kendi branch'inizi onlarınkine çekmesini (pull) istediğiniz orijinal iş akışından gelir.

Issue, bir hata veya görev için numaralandırılmış bir tartışma başlığıdır. Deponuzda (repository) değil, GitHub'ın veritabanında yaşar. Bir barındırma servisi seçmeden önce bunu bilmek önemlidir: depoyu klonladığınızda tüm commit'leri alırsınız ancak hiçbir issue gelmez. Issue'ları dışarı aktarmak için API çağrısı yapmanız gerekir.

Fork, başkasına ait bir deponun sunucu tarafındaki kendi kopyanızdır. Bu kopya üzerinde yazma yetkiniz vardır; buraya bir branch push edebilir ve kendi kopyanızdan orijinal depoya bir pull request açabilirsiniz. Maintainer'ların sizi hiç tanımadığı bir projeye bu şekilde katkıda bulunursunuz. Fork, GitHub üzerinde yaşayan ve nereden geldiğini hatırlayan bir klondur.

Yazılımlar bu üç öğeyi de bir insanın kullandığı aynı API üzerinden okur. Kendi sunucunuzda çalıştırdığınız bir pull request inceleme ajanı, yeni PR'ları izler, farkları okur ve satır bazlı yorumlar gönderir. Deponun kök dizinindeki bir AGENTS.md dosyası gibi gelenekler, bir deponun artık insanlar kadar araçlar tarafından da okunması nedeniyle mevcuttur.

GitHub'ın bir VPS sahibi için gerçek işlevi

Sunucu dışı depolama ile başlayın. Dağıtım betikleriniz ve playbook dosyalarınız, yapılandırdıkları sunucunun dışında bir yerde bulunmalıdır. VPS'i temiz bir imajdan yeniden oluşturun, klonlayın ve çalıştırın. Bu depoyu gizli tutun ve sunucuya bir deploy key atayın: tüm hesabınız yerine tek bir depoya kayıtlı, salt okunur yetkiye sahip bir SSH anahtarı. Sızdırılmış salt okunur bir deploy key, yalnızca bir depoyu riske atar. Sızdırılmış bir hesap anahtarı ise yazma yetkiniz olan her şeyi riske atar.

sudo git clone git@github.com:yourname/vps-deploy.git /srv/vps-deploy
cd /srv/vps-deploy
git pull --ff-only

--ff-only, bir merge commit oluşturmayı reddeder. Yalnızca değişiklikleri alan bir sunucuda, bir birleştirme işlemi her zaman bir hatadır; bu nedenle bu bayrak, kafa karıştırıcı bir geçmişi fatal: Not possible to fast-forward, aborting. hatasına dönüştürür. Sunucuda değişmemesi gereken bir şey değişmiştir. Tekrar pull yapmadan önce bu durumu düzeltin.

root kullanıcısı olarak klonlayıp ardından Git'i başka bir kullanıcıyla çalıştırırsanız fatal: detected dubious ownership in repository at '/srv/vps-deploy' hatası alırsınız. Git, farklı bir kullanıcıya ait bir depoyu okumayı reddeder; çünkü kötü niyetli bir .git/config, Git'in komutlar çalıştırmasına neden olabilir. Bu sorunu safe.directory istisnası eklemek yerine chown ile sahiplik bilgilerini düzelterek çözün; çünkü istisna eklemek, sorunun kök nedenini ortadan kaldırmadan yalnızca güvenlik denetimini devre dışı bırakır.

GitHub Actions: derleme ve dağıtım işlem hatları

Actions, GitHub'ın CI/CD (sürekli entegrasyon ve sürekli dağıtım) sistemidir. .github/workflows/ dizini altında bir YAML dosyası commit ettiğinizde, belirttiğiniz olay gerçekleştiğinde GitHub bu dosyayı çalıştırır.

name: check
on:
  push:
    branches: [main]
jobs:
  shellcheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: sudo apt-get update && sudo apt-get install -y shellcheck
      - run: shellcheck *.sh

Bu dosya bir workflow (iş akışı) dosyasıdır. Bir job (iş), tek bir makine üzerinde çalışır. Bir step (adım), tek bir komut veya yayınlanmış bir aksiyondur. uses:, başka bir depodan bir aksiyonu içeri çeker ve @v7, onun ana sürümünü sabitler (Ağustos 2026 itibarıyla actions/checkout için güncel sürüm v7'dir). Her zaman bir sürüm sabitleyin; çünkü sabitlenmemiş bir aksiyon, okumadığınız kodların gizli anahtarlarınıza (secrets) erişerek çalışması anlamına gelir.

runs-on: ubuntu-latest, GitHub'dan yeni bir sanal makine talep eder ve iş bittiğinde bu makine silinir. Standart çalıştırıcılar (runners) herkese açık depolarda ücretsizdir; ücretsiz plan, Ağustos 2026 itibarıyla özel depolar için aylık 2.000 dakika kullanım hakkı içerir. Bu rakam üzerinden bir bütçe planlamadan önce güncel fiyatlandırma sayfasını kontrol edin.

Gizli anahtarlar (secrets), depo ayarlarında saklanır ve ${{ secrets.DEPLOY_KEY }} olarak okunur. Bir fork'tan gelen pull request ile tetiklenen iş akışları, salt okunur bir token alır ve bu gizli anahtarlara erişemez; aksi takdirde yabancı bir kullanıcı, tek amacı bu anahtarları yazdırmak olan bir PR açabilirdi.

Actions runner'ı kendi VPS'nizde çalıştırma

runs-on: self-hosted, işi doğrudan sahip olduğunuz bir makineye gönderir. Deponun runner ayarları sayfası size bir indirme satırı, depo web adresi ve bir saat geçerli olan bir kayıt token'ı sağlar. Bu son iki değeri REPO_URL ve RUNNER_TOKEN içine yerleştirin; kurulum üç komuttan ibarettir.

./config.sh --url "$REPO_URL" --token "$RUNNER_TOKEN"
sudo ./svc.sh install
sudo ./svc.sh start
./svc.sh status

svc.sh status, servisin aktif olduğunu bildirmeli ve son günlük satırlarını göstermelidir. Runner, GitHub'a giden bir HTTPS bağlantısı açarak iş bekler; bu nedenle gelen trafik için herhangi bir port açmanız gerekmez. svc.sh install, systemd birimini yazar; bu, insanların atladığı bir adımdır: bu adım olmadan runner, SSH oturumunuz kapandığında sonlanır ve sonraki tüm işler hiçbir açıklama olmaksızın kuyrukta bekler. VPS üzerinde tam self-hosted runner kurulumu, uzun ömürlü bir runner'ın ihtiyaç duyduğu sıkılaştırma ve temizlik işlemlerini adım adım açıklar.

Bunun avantajı, iş zaten makine üzerinde çalıştığı için dağıtımın artık internetten erişilebilir bir gelen SSH anahtarına ihtiyaç duymamasıdır. Ayrıca derleme önbelleği (build cache) çalıştırmalar arasında sıcak kalır ve dakika sayacı işlemez.

Bir uyarı isteğe bağlı değildir. GitHub'ın kendi dokümantasyonu, self-hosted runner'ların yalnızca özel depolar için kullanılmasını önerir; çünkü halka açık bir deponun çatalları (fork), bir pull request açarak runner'ınız üzerinde tehlikeli kodlar çalıştırabilir. Runner, o daldaki iş akışı dosyasında ne yazıyorsa onu yürütür. Kimin push yapabileceğini kontrol ettiğiniz özel bir depoda risk düşüktür. Halka açık bir depoda ise, herhangi bir self-hosted runner'ı yabancıların kod çalıştırabileceği bir makine olarak değerlendirin.

GitHub'a gerçekten ihtiyacınız var mı?

Hayır. Git bir standarttır, GitHub ise bir kolaylıktır. Forgejo ve Gitea, kendi sunucunuzda barındırabileceğiniz (self-hosted) yazılım geliştirme platformlarıdır; bu platformlar, Git barındırma hizmetine ek olarak issue ve pull request özelliklerini de sunar. Her ikisi de tek bir Go binary dosyası olarak dağıtılır ve küçük bir VPS üzerinde çalışabilir. Forgejo, 2022 yılında Gitea'dan çatallanmış (fork) bir projedir ve günümüzde Codeberg'e güç vermektedir. Bir depoyu taşımak tek bir komutla gerçekleştirilebilir, çünkü ağ protokolü aynıdır.

git remote -v
git remote set-url origin git@git.example.com:you/vps-deploy.git
git push origin main

Her commit taşınabilir, çünkü her clone zaten tüm geçmişi barındırır. Taşınmayan kısım ise GitHub'ın üzerine inşa ettiği katmandır: issue kayıtları ve pull request yazışmaları. CI süreçleri de doğrudan aktarılamaz. Forgejo, .forgejo/workflows/ içindeki YAML dosyalarını okuyan kendi Actions uygulamasına sahiptir. Dokümantasyonu, GitHub Actions ile Forgejo Actions'ın aynı olmadığını ve bazı şeylerin hemen çalışmayabileceğini belirterek sınırları konusunda açık bir dil kullanır. Ayrıca kendi runner yapısına ihtiyaç duyar. Bu adımı bir kopyalama değil, bir taşıma (port) süreci olarak planlayın.

Çoğu projenin GitHub'da kalmasının dürüst nedeni katkı sağlayıcılardır. Halka açık kod, insanların halihazırda hesabının bulunduğu bir yerde durmalıdır. Özel dağıtım (deploy) betikleriniz ise orada durmak zorunda değildir. Bunlar birbirinden ayrı iki karardır ve her biri için farklı yanıtlar vermeniz mümkündür.

Neler ilk aşamada bozulur ve hata mesajları ne anlama gelir

Bir push reddedildi. Şunu görüyorsunuz:

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:yourname/vps-deploy.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

Son pull işleminizden bu yana bir değişiklik yapılmış; bu genellikle web düzenleyicisinde yaptığınız bir düzenlemedir. Kendi commit'lerinizi onların üzerine yeniden oynatmak için git pull --rebase komutunu çalıştırın ve ardından tekrar push yapın. Paylaşılan bir branch üzerinde git push --force kullanmaktan kaçının, çünkü bu işlem sunucudaki diğer commit'leri o branch'ten siler.

fatal: refusing to merge unrelated histories. Yerel olarak git init komutunu çalıştırdınız ve GitHub'ın bir README dosyası ile depo oluşturmasına izin verdiniz. İki geçmişin ortak bir commit'i yok, bu yüzden Git tahmin yürütemez. En temiz çözüm, GitHub kopyasını yeni bir klasöre clone'lamak ve dosyalarınızı bu klasörün içine taşımaktır.

error: src refspec main does not match any. Belirttiğiniz branch burada mevcut değil. Genellikle depo henüz hiç commit içermiyordur veya branch adınız master şeklindedir. git branch --show-current bu sorunu çözer.

Bir gizli anahtar commit'e dahil edildi. Kimlik bilgisini hemen değiştirin. Push edildiği andan itibaren onu herkese açık kabul edin; çünkü fork'lar, yansımalar ve önbelleğe alınmış görünümler, silmenizin mümkün olmadığı kopyalar barındırır.

FAQ

GitHub ile Git aynı şey midir?

Hayır. Git, bir makineye kurduğunuz ve ağ bağlantısı ya da hesap gerektirmeden çalışan bir sürüm kontrol programıdır. GitHub ise Git depolarını barındıran, bunlara web arayüzü, hata takibi (issues), çekme istekleri (pull requests) ve CI özellikleri ekleyen ticari bir barındırma hizmetidir. Git 2005 yılında yayınlanmış, GitHub ise 2008 yılında bu altyapı üzerinde kurulmuştur. Git'i GitHub olmadan süresiz kullanabilirsiniz. Her GitHub özelliği, temelinde Git'e bağımlıdır.

VPS üzerinde Git kullanmak için GitHub hesabına ihtiyacım var mı?

Hayır. git init, git commit ve git log, herhangi bir uzak sunucu yapılandırması olmadan da çalışır; bu, /etc dosyalarındaki değişiklikleri izlemek veya betikleri dağıtmak için yeterlidir. Bir hesap, geçmişin sunucu dışında da korunmasını istediğinizde veya depoyu klonlayabilecek ikinci bir makineye ihtiyaç duyduğunuzda işe yarar. Forgejo ve Gitea gibi kendi sunucunuzda barındırdığınız yazılımlar aynı ihtiyacı karşılar; hatta başka bir makinedeki çıplak (bare) bir depoya işaret eden basit bir SSH uzak bağlantısı, hiçbir ek yazılım gerektirmeden çalışır.

Pull request nedir?

Pull request, bir dalın (branch) diğerine birleştirilmesi için yapılan ve beraberinde bir tartışma sayfası getiren bir istektir. Bir dalı gönderir (push), main üzerinde PR açarsınız; barındırma servisi değişiklikleri commit commit gösterir, böylece inceleyenler satır bazlı yorum yapabilir ve otomatik kontroller başarı veya başarısızlık raporu verebilir. Bu bir Git özelliği değil, GitHub özelliğidir; dolayısıyla Git'in kendi içinde bunun için bir komut yoktur. Diğer barındırma servisleri de aynı fikri uygular ve bazen buna merge request adını verirler.

Kendi VPS'imde GitHub Actions runner çalıştırmalı mıyım?

Özel (private) bir depo için genellikle evet. İş, zaten ödemesini yaptığınız donanım üzerinde çalışır, dakika kotası uygulanmaz, derleme önbelleği (build cache) sıcak kalır ve dağıtım için internete açık bir SSH anahtarına ihtiyaç duyulmaz; çünkü runner, GitHub'a dışa doğru bağlantı kurarak iş talep eder. Herkese açık (public) bir depo için GitHub bunu önermez: herhangi biri deponuzu çatallayabilir (fork) ve iş akışı sizin makinenizde çalışan bir pull request açabilir.

Depolarımı daha sonra GitHub'dan taşıyabilir miyim?

Kodları, evet, kolayca taşıyabilirsiniz. Her klon, tüm geçmişi barındırır; bu nedenle git remote set-url origin <new url> komutunu takiben yapılacak bir push işlemi, bir commit'in içerdiği her şeyi taşır. Geride kalanlar GitHub'ın sahipliğindeki katmandır: hata kayıtları, pull request tartışmaları ve Actions geçmişi sizin .git klasörünüzde değil, GitHub'ın veritabanında yaşar. Taşıma araçları, API üzerinden hata kayıtlarını kopyalayabilir; iş akışı dosyaları ise genellikle yeni barındırıcının CI sistemine göre düzenlenmelidir. Bunu göz önünde bulundurmak, gerçek dokümantasyonu hata tartışma başlıkları yerine deponun içinde tutmak için geçerli bir nedendir.