git add çalıştırdıktan sonra dosyayı yeniden değiştirirseniz, sonraki git commit dosyanın son halini otomatik almaz. Commit’e staging area içindeki sürüm girer. Aynı dosyanın hem staged hem unstaged değişiklik taşıması normaldir ve yanlış içeriği kaydetmemek için bu ayrımı görmek gerekir.
Ben Git çalışma akışını anlatırken önce değişikliğin nerede durduğunu kontrol etmeyi öneririm. Working tree, index, yerel commit ve remote arasındaki farkı gerçek komutlarla takip ettiğinizde, branch değiştirme ve pull sırasında verilen kararlar da daha anlaşılır olur.
Önce hangi repoda olduğunuzu kontrol edin
Working tree, üzerinde çalıştığınız dosyalardır. Staging area, diğer adıyla index, bir sonraki commit’e hazırladığınız içeriği tutar. Commit bu içeriği yerel geçmişe kaydeder, remote ise bağlantı kurduğunuz başka bir repodur.
Git kuruluysa boş bir klasörde git init -b main yeni repo başlatır. Var olan repo üzerinde çalışacaksanız git clone <repo-url> kullanırsınız. İkisini sırayla çalıştırmanız gerekmez. Clone, dosyaların yanında geçmişi ve genellikle origin adlı remote bağlantısını getirir.
|
1 2 3 4 |
git status git branch --show-current git remote -v |
Bu komutlar aktif branch’i ve uzak adresleri gösterir. Ekranda main görmeniz, sunucudaki main ile aynı commit’te olduğunuz anlamına gelmez. Yerel branch ile remote-tracking branch birbirinden ayrı referanslardır.
Örnekleri ayrı bir demo reposunda denemenizi öneririm. Commit oluşturabilmek için o repoda user.name ve user.email tanımlı olmalı. Çalışan projenizin ayarlarını değiştirmeden, git config --local ile yalnız demo reposunu yapılandırabilirsiniz.
Git add dosyanın hangi halini alır?
Bu yazı için hazırlanan demoda app.txt dosyasının ilk commit’inde version=1 var. PowerShell’de aşağıdaki sırayla dosyayı version=2 yapıp index’e alabilir, sonra çalışma dosyasını version=3 olarak değiştirebilirsiniz.
|
1 2 3 4 5 6 7 |
Set-Content app.txt 'version=2' git add app.txt Set-Content app.txt 'version=3' git status --short git diff git diff --cached |
Son değişiklikten sonra git status --short, dosya için MM gösterebilir. Short format belgesinde ilk sütun index’in HEAD’e göre durumunu, ikinci sütun working tree’nin index’e göre durumunu anlatır. İki sütunda da M olması, iki ayrı karşılaştırmada değişiklik bulunduğunu gösterir.
Görsel, izole demo reposunda alınan gerçek komut çıktısının okunabilir düzenlemesidir. Karşılaştırmaların tanımı git-diff belgesinde bulunuyor.
Parametresiz git diff, index’teki version=2 ile çalışma dosyasındaki version=3 farkını gösterir. git diff --cached ise son commit’teki version=1 ile index’teki version=2 arasını karşılaştırır. --staged da aynı iş için kullanılabilir.
Şimdi commit atarsanız version=2 kaydolur. version=3 değişikliği çalışma dosyasında kalır. git-add belgesinin anlattığı gibi, son değişikliği de dahil etmek istiyorsanız add komutunu yeniden çalıştırmanız gerekir.
Ben commit öncesinde git diff --cached okumayı özellikle öneririm. git add . kullandıysanız beklemediğiniz dosyalar da hazırlanmış olabilir. Küçük bir değişiklikte dosya adını açık yazmak veya git add -p ile parçaları seçmek incelemeyi kolaylaştırır.
Commit oluşturmak sunucuya göndermez
|
1 2 3 4 |
git commit -m "Update application version" git log --oneline -5 git status |
Commit yerel repoda oluşur ve bir kimlikle geçmişte yerini alır. git log --oneline bunun kısa gösterimidir. Çalışma dosyasında kalan unstaged değişiklikler commit oluşturulunca kaybolmaz.
Commit ve push ayrı işlemlerdir. Takımınızın sunucusuna göndermek için doğru remote ve branch seçilmeli. GitHub veya GitLab bu sunucuyu barındırabilir; Git ise sürüm kontrol aracının kendisi.
|
1 2 |
git push -u origin feature/api-timeout |
Bu komut, o isimdeki yerel branch’i origin üzerindeki branch’e gönderir ve upstream ilişkisini kurar. Önce branch’in gerçekten mevcut olduğunu kontrol edin. Upstream tanımlandıktan sonra çoğu günlük işlemde daha kısa komutlar kullanılabilir, ama hedefi anlamadan kısaltmak hata riskini artırır.
Branch ve merge hangi kaydı değiştirir?
git switch -c feature/api-timeout, bulunduğunuz commit’ten yeni branch oluşturur ve ona geçer. Branch, commit’e işaret eden referanstır. Bu branch’te commit oluşturdukça referans ilerler.
İşiniz bitince hedef branch’e geçip değişikliği orada birleştirirsiniz. Aşağıdaki örnek, yerel main branch’ine merge yapar; sunucuya ayrıca gönderim yapmaz.
|
1 2 3 |
git switch main git merge feature/api-timeout |
Ekip pull request kullanıyorsa birleştirme sunucuda, inceleme sonrasında yapılabilir. İki yaklaşımı aynı işte düşünmeden karıştırmayın. Branch değiştirirken kaydedilmemiş çalışma varsa önce git status okuyun; Git bazı geçişleri yapabilir, değişikliğinizin üzerine yazacak geçişleri ise reddeder.
Merge conflict oluştuğunda hangi dosyaların çakıştığını kontrol edin, içerik kararını verin, çözdüğünüz dosyaları add ile hazırlayın ve merge’i tamamlayın. Otomatik olarak bir tarafın tamamını seçmek, doğru çözüm olduğunun kanıtı değildir.
Fetch ile pull arasındaki karar
git fetch origin uzaktaki commit’leri ve referans bilgisini getirir. Normal kullanımda origin/main güncellenebilir, aktif yerel branch’inize kendiliğinden merge uygulanmaz. Önce karşılaştırabilirsiniz.
|
1 2 3 4 |
git fetch origin git log --oneline --graph --decorate --all -10 git status -sb |
git pull ise fetch sonrasında bütünleştirme adımı da çalıştırır. Resmi belgede merge ve rebase seçenekleri ayrı açıklanır. Ekip politikasına göre --no-rebase veya --rebase seçilir; sürüme ve ayara bağlı çıplak komut davranışını varsaymak istemiyorsanız tercihi açık yazın.
Ben başlangıçta git pull --ff-only kullanmayı öneririm. Yerel geçmiş uzak geçmişin gerisindeyse branch fast-forward ile ilerleyebilir. İki tarafta birbirinden bağımsız commit varsa komut hata vererek durur, merge commit oluşturmaz ve yerel commit’leri silmez.
Görseldeki ret, aynı satırda conflict bulunduğu anlamına gelmiyor; geçmişler ayrışmış durumda. Çıktı yerel demo reposunda üretildi, davranış git-pull belgesinden doğrulandı.
Bu durumda geçmişi inceleyip ekip politikasına uygun merge veya rebase kararı verin. Rebase commit kimliklerini değiştirebildiği için paylaşılmış geçmişte ayrıca dikkat ister. Hatanın üzerine force push uygulamak güvenli başlangıç yöntemi değildir.
Bir sonraki commit öncesindeki kontrol
- Doğru branch ve remote üzerinde olduğunuzu doğrulayın.
git diffile kalan çalışmayı,git diff --cachedile commit içeriğini ayrı okuyun.- Push öncesinde geçmişlerin ayrışıp ayrışmadığını kontrol edin.
Git’e giriş yazısından sonra yapacağınız en yararlı deneme, aynı dosyayı add öncesinde ve sonrasında değiştirip iki diff’i karşılaştırmak. Commit’e hangi sürümün girdiğini kendiniz göreceksiniz. Sorularınız olursa yorumlarda buluşalım.
