Arama Yap Mesaj Gönder
Biz Sizi Arayalım
+90
X
X

Wählen Sie Ihre Währung

Türk Lirası $ US Dollar Euro
X
X

Wählen Sie Ihre Währung

Türk Lirası $ US Dollar Euro

Bize Ulaşın

Konum Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Repository Görünürlüğü ve Yetkiler

GitHub Repository Private veya Public Nasıl Yapılır?

Public repository kaynak kodu herkese görünür; private repository yalnız yetkili hesaplara açıktır. Görünürlük bir lisans veya secret kasası değildir. Yazılım satış projelerinde erişim minimum yetkiyle verilmelidir.

private repopublic repocollaboratorvisibilityrepository roles
Git / GitHub Terminal
Repository visibility: Private
Change repository visibility
Manage access
Invite a collaborator
Danger Zone
01Repository ve aktif branch’i doğrulayın
02Remote URL ve GitHub hesabını kontrol edin
03Fetch, log ve status ile farkı inceleyin
04Push ve PR sonrası GitHub’da doğrulayın
01
Güvenli Git yaklaşımı

Private ve Public Repository nasıl analiz edilir?

Public repository kaynak kodu herkese görünür; private repository yalnız yetkili hesaplara açıktır. Görünürlük bir lisans veya secret kasası değildir. Yazılım satış projelerinde erişim minimum yetkiyle verilmelidir.

01

Repository durumunu belirleyin

`git status`, aktif branch, remote ve son commitleri görmeden reset veya force işlemi yapmayın.

02

Hesabı ve remote’u doğrulayın

HTTPS credential, SSH key, remote URL ve GitHub hesabının doğru olduğunu kontrol edin.

03

Tarihçeyi koruyun

Fetch, merge veya rebase öncesinde commit ya da backup branch ile geri dönüş noktası bırakın.

04

PR ve kurallara uyun

Protected branch, review, CI ve secret scanning kurallarını aşmak yerine feature branch akışını kullanın.

Private repo’ya secret commit etmeyin.

02
Canlı Git hata sözlüğü

Git ve GitHub terminal mesajları

01kritik

Private repo public yapıldı

Anlamı: İçerik görünür hâle gelmiş olabilir.

Muhtemel neden: Yanlış visibility değişikliği.

02kritik

Secret private repo’da commitli

Anlamı: Private erişim secret yönetimi değildir.

Muhtemel neden: Yanlış güvenlik varsayımı.

03uyari

Collaborator push yapamıyor

Anlamı: Rol veya branch policy yetersiz.

Muhtemel neden: Read/Triage veya protected branch.

04uyari

Public repo lisanssız

Anlamı: Kullanım hakkı belirsiz.

Muhtemel neden: LICENSE yok.

05uyari

Visibility change affects forks

Anlamı: Fork/network davranışı etkilenebilir.

Muhtemel neden: Public/private geçişi.

06uyari

Organization role too broad

Anlamı: Kullanıcı fazla yetkili.

Muhtemel neden: Admin/team rolü.

07uyari

Old collaborator still has access

Anlamı: Erişim kaldırılmamış.

Muhtemel neden: Offboarding eksik.

08bilgi

Collaborator can clone private repo

Anlamı: Yetkili kişi local kopya alabilir.

Muhtemel neden: Normal Git davranışı.

Bu ifadeyle eşleşen kayıt bulunamadı.

03
Kopyalanabilir kontroller

Git, GitHub CLI, SSH ve repository testleri

Repo görünürlüğü

gh repo view --json nameWithOwner,visibility,isPrivate,defaultBranchRef

Repository görünürlüğünü gösterir.

Collaborator listesi

gh api repos/OWNER/REPO/collaborators --paginate --jq '.[] | [.login,.permissions] | @tsv'

Kullanıcı ve izinleri listeler.

Branch protection

gh api repos/OWNER/REPO/branches/main/protection 2>/dev/null || true

Main koruma ayarını gösterir.

Secret isimleri

gh secret list

Secret değerlerini göstermeden isimleri listeler.

Remote URL

git remote -v

Local kopyanın bağlı repository’sini gösterir.

Secret taraması

git log -p --all | grep -Ei '(api[_-]?key|secret|token|password|BEGIN .*PRIVATE KEY)' | head -n 80

Geçmişte olası secret izlerini tarar.

04
Doğru ve riskli komutlar

Git komut karşılaştırmaları

Public satış kodu

Riskli / Hatalı
Repository Public, .env commitli
Doğru Yaklaşım
Repository Private, `.env` ignore, sırlar GitHub Secrets içinde

Geniş yetki

Riskli / Hatalı
Müşteriye Admin
Doğru Yaklaşım
Müşteriye yalnız gerekli repo ve Read/Write rolü

Lisanssız public

Riskli / Hatalı
Public, LICENSE yok
Doğru Yaklaşım
Public + uygun LICENSE

Secret saklama

Riskli / Hatalı
config.php içinde production şifresi
Doğru Yaklaşım
config.example.php + ENV + GitHub Secrets
05
Platform ve iş akışı

Windows, VS Code, private repo ve ekip kullanımı

Windows / VS Code

Git for Windows, PowerShell, Git Bash ve VS Code Source Control birlikte kullanılabilir.

  • Doğru local klasör ve aktif branch’i doğrulayın.
  • Windows Credential Manager içindeki eski GitHub hesabını kontrol edin.
  • Commit öncesi Changes listesini ve gizli dosyaları inceleyin.

HTTPS / SSH / Çoklu Hesap

HTTPS credential manager; SSH ise uzun süreli ve çoklu hesaplı geliştirme ortamlarında kullanılabilir.

  • `gh auth status` veya `ssh -T` ile hesabı doğrulayın.
  • Private key’i paylaşmayın ve repository’ye eklemeyin.
  • Kişisel ve iş hesaplarını SSH config veya ayrı credential ile ayırın.

Private Proje / Ekip

Repository rolü, protected branch, Pull Request ve CI politikaları birlikte yönetilmelidir.

  • Main’e doğrudan push yerine feature branch kullanın.
  • Secret ve production config’i GitHub Secrets/ENV içinde tutun.
  • Collaborator ve team erişimini minimum yetkiyle verin.
Yanlış müdahaleler

Kesinlikle yapmayın

  • Private repo’ya secret commit etmeyin.
  • Müşteriye ana ürün repository’sinde gereksiz admin vermeyin.
  • Visibility etkilerini okumadan değiştirmeyin.
  • Public repository’yi lisans olmadan açık kaynak sanmayın.
İşlem sonrası kontrol

Çözümü doğrulayın

  • Görünürlük proje amacıyla uyumlu.
  • Roller minimum yetkili.
  • Secret Git geçmişinde değil.
  • Public proje lisanslı.
06
İç SEO içerik kümesi

İlgili GitHub ve Git çözümleri

07
Birincil kaynaklar

GitHub ve Git resmî belgeleri

08
Sık sorulan sorular

Private ve Public Repository hakkında merak edilenler

HTTPS mi SSH mı kullanılmalı?

Kolay başlangıç için HTTPS ve Git Credential Manager; otomasyon ve çoklu hesap için SSH uygundur.

GitHub parolası neden kabul edilmiyor?

Git işlemlerinde hesap parolası yerine PAT, credential manager, GitHub CLI veya SSH kullanılır.

Private repository tamamen güvenli mi?

Yalnız erişimi sınırlar; secret, parola, private key ve müşteri verileri yine commit edilmemelidir.

Force push ne zaman kullanılmalı?

Yalnız geçmişi bilinçli yeniden yazılan kişisel feature branch’te ve mümkünse `--force-with-lease` ile kullanılmalıdır.

PR açmak zorunlu mu?

Branch protection gerektiriyorsa zorunludur; tek kişilik projede de review ve güvenli main geçmişi sağlar.

Komutları doğrudan kopyalayabilir miyim?

OWNER, REPO, branch, URL ve dosya değerlerini projenize göre değiştirip önce `git status` ve `git remote -v` ile doğrulayın.

`.git` klasörünü silmek çözüm mü?

Genellikle hayır. `.git` klasörünü silmek commit geçmişini, branch ve remote bilgilerini kaybettirebilir.

EKA YAZILIM VE BİLİŞİM SİSTEMLERİ

GitHub repository, push ve Pull Request sorununu kod geçmişini kaybetmeden çözelim

Windows, VS Code, Git Bash, SSH, private repository, protected branch, merge conflict ve GitHub Actions sorunlarını güvenli Git akışıyla inceliyoruz.

Yazılım Desteği AlWhatsApp
Top