Repository oluşturma, rebase ve gizli bilgiler

Bu makalede, Git'in temel iş akışını öğrendikten sonra karşınıza çıkacak üç konuyu ele alacağız: repository oluşturma (git init ile veya IDE'den), rebase ile merge arasındaki fark ve Git geçmişine yanlışlıkla giren gizli bilgileri doğru şekilde temizleme. Bu üçü Claude Code ile çalışırken de işinize yarar. Claude bu işlemleri komutlarla yapar; arka planda ne olduğunu anlamanız önemlidir.

Örnekler ve arayüz görüntüleri JetBrains IDE'lerine aittir; eylemlerin adları ve konumları kullandığınız sürümde farklı olabilir. Alıştırmalar için ayrı bir eğitim repository'si kullanın. İş projesinde ise o projenin branch, commit ve değişiklik gönderme kurallarına uyun.

Repository oluşturma - git init ve IDE'den

Projeniz zaten GitHub'daysa onu clone edebilirsiniz. Başka bir durum: kodun bulunduğu yerel bir klasörünüz var. git init bu klasörde Git'in kendi iç verilerini oluşturur, ancak ilk commit'i oluşturmaz. Aşağıdaki örnekte README.md ve .gitignore dosyalarının önceden oluşturulup kontrol edildiği varsayılıyor; gereken diğer dosyaları ayrıca ekleyin.

git init
git status
# README ve ignore kurallarını kontrol ettikten sonra
git add README.md .gitignore
git diff --cached
git commit -m "Initial commit"

IDE'de yerel bir repository oluşturmak için Git repository'si oluşturma veya version control'ü etkinleştirme seçeneğini kullanın. Share Project on GitHub ayrı bir iş akışıdır: uzak bir repository de oluşturur ve değişiklikleri göndermeyi önerir. Göndermeden önce seçilen dosyaları, geçmişi ve görünürlük ayarını kontrol edin.

Public veya private

Repository oluştururken görünürlük ayarını seçersiniz:

• public - repository internette herkese görünür; kodu herkes inceleyebilir. Portföy ve open source için uygundur;
• private - yalnızca siz ve davet ettiğiniz kişiler erişebilir. Gösterilmemesi gereken iş ve eğitim kodları için varsayılan tercih budur.

Görünürlük kalıcı değildir: daha sonra GitHub'daki repository ayarlarından değiştirebilirsiniz.

rebase ve merge arasındaki fark

Hem merge hem de rebase, bir branch'teki çalışmayı diğerine taşımaya yarar. Ancak bunu farklı şekillerde yaparlar; projenin geçmişinin nasıl görüneceği de buna bağlıdır.

merge geçmişleri birleştirir. Geçmişler ayrıştıysa genellikle iki ebeveyni olan bir merge commit'i oluşturulur. Geçerli branch diğerinin atasıysa Git yeni bir commit oluşturmadan fast-forward yapabilir. Aşağıdaki diyagramda ayrışmış branch'ler gösteriliyor.

merge her iki çizgiyi de korur ve bir merge commit'i ekler; böylece geçmişte ayrı bir feature branch'i olduğu açıkça görülür.

rebase, commit'lerinizi sanki çalışmaya hedef branch'in güncel ucundan başlamışsınız gibi taşır. Geçmiş tek bir düz çizgi hâline gelir. Bunun bir bedeli var: rebase commit'lerinizi yeniden yazar; eskilerin yerine farklı hash'lere sahip yenileri gelir.

rebase sonrasında C ve D commit'leri E'nin üzerine eklenmiş gibi görünür: geçmiş doğrusal olur, ancak bunlar farklı hash'lere sahip yeni commit'lerdir (C2, D2).

Hangisini seçmeli?

• merge - gerçek geçmişi korumak önemliyse ve branch ortak kullanılıyorsa. Varsayılan olarak daha güvenli seçimdir;
• rebase - pull request öncesinde kendi kişisel branch'inizi düzenlemek için; doğrusal geçmişi okumak daha kolaydır.

Repository'den gizli bilgileri temizleme

Dosyayı yeni bir commit ile silmek, önceki commit'lerdeki gizli bilgiyi ortadan kaldırmaz. Bir parola ya da token başkalarının erişimine açıldıysa önce onu sağlayan hizmette iptal edin veya yenileyin. Geçmişi temizlemek, önceden alınmış kopyaları geri almaz.

GitHub, temizlik için git-filter-repo kullanan bir yöntem açıklıyor. Kullanılacak komutlar, dosyanın tamamen mi silindiğine yoksa yalnızca gizli metnin mi değiştirildiğine, bu metnin nerelerde geçtiğine ve geçmişin nereye gönderildiğine göre değişir. Yeni bir kopya alma, sonucu kontrol etme, uzak referansları güncelleme ve ekip arkadaşlarının yapması gerekenler de dahil olmak üzere hassas verileri kaldırmaya yönelik resmi yönergeleri izleyin.

Yerel kopyayı temizlemek sunucuyu değiştirmez. Yeniden yazılmış geçmişi force push ile göndermek ayrıca üzerinde anlaşılması gereken bir işlemdir; burada tüm branch'ler için geçerli tek bir komut çalıştırmayın. Başkalarının clone ve fork kopyaları sizin kontrolünüzde değildir; erişilebilir GitHub bağlantıları ve cache'ler için aynı yönergede Support'a başvurma koşulları açıklanıyor.

Tekrar yaşanma olasılığını azaltmak için:

• gizli değerleri kod dışında, örneğin ortam değişkenlerinde saklayın;
• .env gibi yerel dosyaları Git tarafından izlenmeden önce .gitignore'a ekleyin;
• commit'ten önce seçilen dosyaları ve git diff --cached çıktısını kontrol edin;
• repository'de secret scanning ve push protection özellikleri varsa ek kontrol olarak etkinleştirin; bunlar olası tüm gizli bilgileri bulamaz.

Claude Code ile birlikte nasıl çalışır?

Claude Code repository'nizle çalışırken bu üç konu da karşınıza çıkar. Şunlara dikkat edin:

• repository'yi başlatabilir (git init) ve ilk commit'i hazırlayabilir; GitHub'da oluştururken public ya da private seçimini siz yaparsınız;
• proje kurallarına göre bir birleştirme yöntemi önerir; çalıştırmadan önce merge ve rebase'in sonuçlarını kontrol edin;
• commit'e hangi dosyaların girdiğini görür, ancak oraya gizli bilgi sızmamasının nihai sorumluluğu sizdedir.

Önceki makale: Git'te değişiklikleri geri alma ve kurtarma