2.2 Git Basics - Değişikliklerin Repoya Kaydedilmesi

Hangi dosyanın hangi durumda olduğunu görmek için git status komutu kullanırız. Bu komutu bir projeyi kopyaladıktan hemen sonra çalıştırırsanız şöyle bir şey görmelisiniz:

Bu, temiz bir çalışma dizininiz olduğu anlamına gelir. Bir başka deyişle, izlenen dosyalarınızın hiçbirinde henüz bir değişiklik yoktur. Ayrıca, Git izlenmeyen dosyaları görmez; aksi halde onlar da burada listelenirdi. Son olarak bu komut size hangi projenin hangi dalında (branch) olduğunuzu söyler ve sunucuda kopyaladığınız daldan ayrılmadığınızı bildirir. Şimdilik bu dal her zaman varsayılan olan ``master``, yani "ana dal"dır. Bunda endişelenmenizi gerektirecek bir durum yoktur. Git Branching ünitesinde dalları (branch) ve işaretçileri (reference) ayrıntılı olarak göreceksiniz.

Diyelim ki projenize yeni bir dosya, mesela basit bir README (BENİ OKU) dosyası eklediniz. Dosya daha önce mevcut değilse ve git status komutunu çalıştırırsanız izlenmeyen dosyanızı şu şekilde görürsünüz:

Yeni README dosyanızın izlenmediğini görebilirsiniz, çünkü git status komutuyla alacağınız durum çıktısında Untracked files (izlenmeyen dosyalar) başlığı altındadır. "İzlenmeyen" temel olarak Git’in önceki pozda sahip olmadığınız bir dosyayı gördüğü anlamına gelir. Siz bunu yapmasını açıkça söyleyene kadar, Git bunu pozlarınıza dahil etmeyecektir. Böyle yapmasının sebebi, sizi yanlışlıkla oluşturulan "ikili" (binary) dosyaların veya eklemek istemediğiniz diğer dosyaların gereksiz kalabalığından ve kafa karışıklığından korumak istemesidir. README 'yi katkılarınıza dahil etmek istiyorsanız, o halde dosyayı izlemeye başlayalım.

Yeni bir dosyayı izlemeye başlamak için git add komutu kullanılır. README dosyasını izlemeye başlamak için şu komutu çalıştırın:

Durum komutunuzu (git status) tekrar çalıştırırsanız, README dosyanızın artık takip edildiğini (tracked) ve kaydedilmek üzere izleme alındığını görebilirsiniz:

Changes to be committed başlığı altında yer aldığından izleme alındığını anlayabilirsiniz. Bu noktada bir katkı işlerseniz, dosyanın git add çalıştırdığınız andaki sürümü, katkı geçmişinize yeni bir katkı olarak kaydedilecektir. Daha önce git init komutunu çalıştırdığınızda, hemen ardından git add <files> komutunu çalıştırdınız. Bunun amacı dizininizdeki dosyaları izlemeye başlamaktı. git add komutu, bir dosya veya dizin için bir yol adı alır. Eğer bu bir dizinse, ilgili dizin ve alt dizinlerindeki tüm dosyaları izleme ekler.

Şimdi izlenmekte (tracked) olan bir dosyayı değiştirelim. Eğer izlenmnekte olan CONTRIBUTING.md adlı dosyayı değiştirir ve ardından git status komutunu tekrar çalıştırırsanız, şöyle bir sonuç elde edersiniz:

CONTRIBUTING.md dosyası, Changes not staged for commit adlı bir bölümün altında görünür. Bu, izlenen bir dosyanın çalışma dizininde değiştirildiği, ancak henüz izleme alınmadığı anlamına gelir. İzleme almak için git add komutunu çalıştırmalısınız. git add çok amaçlı bir komuttur: yeni dosyaları takibe başlamak, dosyaları izleme almak (katkı için indekslemek) ve birleştirme sonucunda çakışan dosyaları (merge conflict) çözümlenmiş olarak işaretlemek gibi diğer şeyler için de kullanırsınız. Bunu, "bu dosyayı projeye ekle" yerine "bu içeriği bir sonraki işleme ekle" olarak düşünmek daha faydalı olabilir. Şimdi CONTRIBUTING.md dosyasını izleme almak için git add komutunu çalıştıralım ve ardından git status komutunu bir kez daha koşalım:

Her iki dosya da izlemdedir ve bir sonraki işleminize aktarılacaktır. Bu noktada, varsayalım ki CONTRIBUTING.md dosyasında yapmak istediğiniz küçük bir değişikliği hatırladınız. Dosyayı tekrar açar ve bu değişikliği yaparsınız, artık değişikliğinizi katkı olarak işlemeye hazırsınız. Hadi git status komutunu bir kez daha çalıştıralım:

Bu da ne! Artık CONTRIBUTING.md hem staged hem de unstaged olarak listelenmiş. Peki neden böyle oldu!? Git’in bir dosyayı tam olarak git add komutunu çalıştırdığınız anda olduğu gibi izleme aldığını görüyorsunuz. Eğer şimdi git commit komutunu çalıştırırsanız, CONTRIBUTING.md nin çalışma dizininizde göründüğü şekliyle değil de git add komutunu en son çalıştırdığınız andaki sürümü kayıt işlemine girecektir. git add çalıştırdıktan sonra bir dosyayı değiştirirseniz, dosyanın en son sürümünü izleme almak için tekrar git add çalıştırmanız gerekir:

git status çıktısı oldukça kapsamlı ve aynı zamanda da uzundur. Git’te ayrıca bir özet-durum bayrağı bulunur, böylece değişikliklerinizi daha derli toplu bir şekilde görebilirsiniz. Eğer git status -s veya git status --short komutunu çalıştırırsanız, çok daha basitleştirilmiş bir çıktı elde edersiniz:

İzlenmeyen yeni dosyaların yanında ??, aşama alanına eklenen yeni dosyaların yanında A (added), değiştirilen dosyaların yanında ise M (modified) bulunur. Çıktıda iki sütun vardır: soldaki sütun izlem (stage) durumunu, sağdaki sütun ise çalışma ağacının (working tree) durumunu gösterir. Örneğin bu çıktıda, README dosyası çalışma dizininde değiştirilmiş ancak henüz izleme alınmamıştır. lib/simplegit.rb dosyası ise değiştirilmiş ve izleme alınmıştır. Rakefile değiştirildi (modified), izleme alındı (staged) ve tekrar değiştirildi (changed). Dolayısıyla üzerinde hem "staged" hem de "unstaged" değişiklikler var.

Sıklıkla Git’in otomatik olarak eklemesini veya izlemesini istemediğiniz bazı dosyalara sahip olursunuz. Bunlar genellikle kayıt dosyaları gibi derleme sisteminiz tarafından otomatik olarak oluşturulan dosyalardır. Bu gibi durumlarda, bunlarla eşleşecek şekilde .gitignore adlı bir dosya listeleme modeli oluşturabilirsiniz. Örnek bir .gitignore dosyası:

İlk satır Git’e, çalıştırdığınız kodun bir yan çıktısı olabileceği için, uzantısı .o (object) veya .a (archive) ile biten tüm dosyaları yoksaymasını söyler. İkinci satır Git’e, adları tilde (~) ile biten tüm dosyaları yok saymasını söyler; bu, Emacs gibi birçok metin düzenleyicisi tarafından geçici dosyaları işaretlemek için kullanılır. Ayrıca otomatik olarak oluşturulan log (kayıt), tmp (geçici) veya pid (işlem kimliği) vb dizinleri de ekleyebilirsiniz. Başlamadan önce yeni reponuz için bir .gitignore dosyası oluşturmak iyi bir fikirdir. Böylece Git reponuzda görmek istemediğiniz dosyaları yanlışlıkla katkı olarak işlemezsiniz.

.gitignore dosyasını yazarken göz önünde bulundurmanız gereken kurallar şunlardır:

Glob desenleri, "shell"in kullandığı "RegEx" ifadelerine benzer: Yıldız işareti (*) sıfır veya daha fazla karakterle eşleşir, [abc] parantez içindeki herhangi bir karakterle eşleşir (bu örnekte a, b veya c), Soru işareti (?) tek bir karakterle eşleşir, Ve kısa çizgiyle ([0-9]) ayrılmış karakterleri çevreleyen parantezler bu aralıkta yer alan herhangi bir karakterle (bu örnekte 0’dan 9’a kadar rakamlarla) eşleşir, İç içe geçmiş dizinleri eşleştirmek için iki yıldız işareti de kullanabilirsiniz; a/**/z ifadesi, a/z, a/b/z, a/b/c/z, vb. ile eşleşir.

İşte size örnek bir .gitignore dosyası:

git status komutu sizin için yeterince bilgi içermiyorsa (sadece hangi dosyaların değiştirildiğini değil, tam olarak neyi değiştirdiğinizi de bilmek istiyorsanız), bunun yerine git diff komutunu kullanabilirsiniz. git diff komutunu daha sonra ayrıntılı olarak ele alacağız, ancak muhtemelen onu en çok şu iki soruya cevap bulmak için kullanacaksınız: 1. Neyi değiştirdiniz ama henüz izleme almadınız? 2. Neyi izleme aldınız fakat henüz katkı olarak işlemediniz? Her ne kadar git status bu soruları genel olarak dosya adlarını listeleyerek cevaplasa da git diff size; eklenen ve kaldırılan satırları, değiştirilen her bir kod parçasıyla birlikte, detaylıca gösterir.

Diyelim ki README dosyasını tekrar değiştirip izleme alıyorsunuz ve ardından CONTRIBUTING.md dosyasını izleme almadan düzenliyorsunuz. git status komutunuzu çalıştırırsanız bir kez daha şöyle bir şey görürsünüz:

Neyi değiştirdiğinizi ancak henüz izleme almadığınızı görmek için herhangi bir bayrak (parametre) kullanmadan ‘git diff’ yazın:

Bu komut, çalışma dizininizdeki güncel kodu, izlem alanınızdaki kodla karşılaştırır. Sonuç size, henüz gerçekleştirmediğiniz değişiklikleri görme imkanı tanır.

Eğer bir sonraki katkı işleminizde nelerin kaydedileceğini görmek istiyorsanız git diff --staged komutunu kullanabilirsiniz. Bu komut, izlemdeki değişikliklerinizi, en son katkı olarak işlediğiniz kodla karşılaştırır:

git diff komutunun son katkı işleminizden bu yana yapılan tüm değişiklikleri göstermediğini, yalnızca henüz izleme alınmamış değişiklikleri gösterdiğini aklınızdan çıkarmayın. Eğer tüm değişikliklerinizi izleme aldıysanız, git diff size hiçbir çıktı vermeyecektir.

Bir başka örnek olarak, CONTRIBUTING.md dosyasını izleme alır ve ardından yeniden düzenlerseniz, dosyadaki izleme alınmış ve alınmammış değişiklikleri görmek için git diff komutunu kullanabilirsiniz. Ortamımız şöyle görünüyorsa:

Artık neyin izleme alınmamış olduğunu görmek için 'git diff komutunu kullanabilirsiniz:

veya şu ana kadar neleri izleme aldığınızı görmek için git diff --cached (--staged ve --cached eşanlamlıdır) komutunu kullanabilirsiniz:

Harici Araçlarda .Git Diff

Artık izlem alanınız istediğiniz şekilde ayarlandığına göre değişikliklerinizi katkı olarak işleyebilirsiniz. "unstaged" olarak işaretli olan dosyalarınızın (oluşturduğunuz veya değiştirdiğiniz fakat hiç git add komutuyla izleme almadığınız dosyalar) bu işlemle katkı geçmişine kaydedilmeyeceğini aklınızdan çıkarmayın. Bu dosyalar diskinizde "modified" (değiştirilmiş) işaretli olarak kalacaklar. Bu durumda, eğer bir kez daha git status komutunu çalıştırırsanız ve her şeyin "staged" işaretli olduğunu görürseniz, artık değişikliklerinizi katkı olarak işlemeye hazırsınız demektir. Değişikliklerinizi işlemenin en basit yolu git commit komutunu çalıştırmaktır:

Bunu yaptığınızda seçili derleyiciniz başlatılır. (Bu sizin shell’inizin EDITOR ortam değişkeni tarafından ayarlanmıştır. (Genellikle "vim" veya "emacs"tır, ancak Başlangıç ünitesinde gördüğünüz gibi git config --global core.editor komutunu kullanarak bunu istediğiniz şekilde yapılandırabilirsiniz.).

Ekranda aşağıdaki metni göreceksiniz (bu örnek bir Vim ekranıdır):

Varsayılan katkı mesajının, yorumlanan git status komutunun en son çıktısını ve üstte bir boş satırı içerdiğini görebilirsiniz. Bu yorumları kaldırabilir ve katkı mesajınızı yazabilir veya neyi katkı olarak işlediğinizi hatırlamanıza yardımcı olması için orada bırakabilirsiniz. (Neyi değiştirdiğinizi daha da açık bir şekilde hatırlatmak için, git commit komutuna -v bayrağı ekleyebilirsiniz. Böylece yaptığınız değişikliği (diff) derleyicinize eklemiş olursunuz ve tam olarak hangi değişiklikleri yaptığınızı görebilirsiniz.) Derleyicinizden çıktığınızda, Git bu mesajla birlikte (yorumlar ve değişiklikler çıkarılmış olarak) katkı kaydınızı oluşturur.

Alternatif olarak, -m (message) bayrağı kullanarak katkı mesajınızı commit komutuyla aynı satırda yazabilirsiniz:

Tebrikler, artık ilk katkınızı işlediniz! Bu katkı kaydının size kendisi hakkında bazı çıkarımlar verdiğini görebilirsiniz; değişiklikleri hangi dala (master) kaydettiğiniz, kaydın hangi SHA-1 (Secure Hash Algorithm 1) koduna (Gelecekte, geçmiş bir katkıya geri dönmek istediğinizde tam olarak hangi katkıya dönmek istediğinizi belirtebilmeniz içih her bir katkınızın kendine özel bir SHA-1 kodu bulunur. Bu bir nevi katkınızın kimlik numarası gibidir.) sahip olduğu (463dc4f), kaç dosyanın değiştirildiği, eklenen ve silinen satırlarla ilgili istatistikler vb bulunmaktadır.

Katkı kayıtlarınızın izleme yüklediğiniz kodun pozu (anlık görüntüsü) olduğunu unutmayın. İzleme almadığınız her şey dosya ve kod hala orada değiştirilmiş bir halde duruyor. Bunları katkı geçmişinize eklemek için başka bir katkı işleminde bulunabilirsiniz. Aslında her katkı işlediğinizde, projenizin daha sonra geri dönebileceğiniz veya karşılaştırabileceğiniz bir pozunu kaydetmiş oluyorsunuz.

İzlem alanı katkılarınızın tam olarak istediğiniz şekilde işlenmesi için oldukça faydalı olsa da bazen iş akışınız içerisinde beklenenden daha karmaşık olabilir. İzlem alanını atlamak istiyorsanız, Git bunun için basit bir kısayol sağlar. git commit komutuna -a (add) seçeneğinin eklenmesi, Git’in zaten izlenen her dosyayı katkıda bulunmadan önce otomatik olarak izleme almasını sağlar ve git add kısmını atlamanıza olanak tanır:

Bu durumda katkı işlemeden önce CONTRIBUTING.md dosyasında git add komutunu çalıştırmanız gerekmediğine dikkat edin. Bunun nedeni -a bayrağının değiştirilen tüm dosyaları içermesidir. Bunu yapmakta herhangi bir sorun yoktur ancak dikkatli olun; bazen bu bayrak istenmeyen değişiklikleri de katkılarınıza eklemenize neden olur.

Git’ten bir dosyayı kaldırmak için, onu izlemden kaldırmanız ve ardından bu değişikliği kaydetmeniz (commit) gerekir. git rm komutu seçtiğiniz dosyayı hem izlem alanından hem de çalışma dizininizden kaldırır. Böylece bir dahaki sefere onu izlenmeyen bir dosya olarak görmezsiniz. Eğer dosyayı silmek yerine sadece takipten çıkarmak istiyorsanız dosya yolunu ve adını .gitignore dosyasına kaydetmelisiniz.

Dosyayı sadece çalışma dizininizden kaldırırsanız, dosyanızı git status çıktınızın Changes not staged for commit (yani unstaged) alanında görebilirsiniz:

Daha sonra, eğer git rm komutunu çalıştırırsanız, dosyanın kaldırılması işlemini izlem alanına almış olursunuz:

Bir sonraki katkı işleminizde dosya kaybolacak ve artık izlenmeyecektir. Dosyayı değiştirdiyseniz veya izleme zaten eklediyseniz, Git’i kaldırma işlemine zorlamak için -f (forced) seçeneğini kullanmalısınız. Bu, henüz poz olarak kaydedilmemiş ve Git’ten kurtarılamayan verilerin yanlışlıkla kaldırılmasını önleyen bir güvenlik özelliğidir.

Yapmak isteyebileceğiniz başka bir yararlı şey, dosyayı çalışma ağacınızda tutmak ancak izlemden kaldırmaktır. Başka bir deyişle, dosyayı sabit diskinizde tutmak ancak Git’in artık onu izlememesini sağlamak isteyebilirsiniz. Eğer .gitignore dosyanıza bir şey eklemeyi unuttuysanız ve onu yanlışlıkla izleme aldıysanız (mesela büyük bir "log" dosyası veya işlenmiş .a dosyaları gibi) bu özellik oldukça işinize yarayacaktır. Bunu yapmak için --cached seçeneğini kullanın:

Dosyaları, dizinleri ve dosya glob kalıplarını git rm komutuna aktarabilirsiniz. Bu, aşağıdaki gibi şeyler yapabileceğiniz anlamına gelir:

* işaretinin önündeki ters eğik çizgiye (\) dikkat edin. Bu özellikle gereklidir; çünkü Git, "shell"inizin dosya adı genişletmesine ek olarak, kendi dosya adı genişletmesini de yapar. Bu komut, log/ dizinindeki .log uzantısına sahip tüm dosyaları kaldırır. Veya şöyle bir şey de yapabilirsiniz:

Bu komut, adları ~ ile biten tüm dosyaları kaldırır.

Diğer birçok VCS sisteminin aksine Git, dosya hareketlerini açıkça izlemez. Bir dosyayı yeniden adlandırırsanız, Git’te dosyayı yeniden adlandırdığınızı bildiren hiçbir meta veri depolanmaz. Ancak Git bu sorunu olaydan sonra çözme konusunda oldukça akıllıdır. Dosya hareketini tespit etme konusunu birazdan ele alacağız.

Bu nedenle Git’in bir mv komutuna sahip olması biraz kafa karıştırıcıdır. Git’te bir dosyayı yeniden adlandırmak istiyorsanız şöyle bir komut çalıştırabilirsiniz:

Bu komut gayet iyi bir şekilde çalışıyor. Aslında, böyle bir şeyi çalıştırıp duruma bakarsanız Git’in bunu yeniden adlandırılmış bir dosya olarak değerlendirdiğini görürsünüz:

Ancak bu, şunun gibi bir şeyi çalıştırmaya eşdeğerdir:

Git bunun dolaylı olarak bir yeniden adlandırma olduğunu anlar, dolayısıyla bir dosyayı bu şekilde veya mv komutuyla yeniden adlandırmanız önemli değildir. Tek dikkate değer fark, git mv komutunun üç yerine tek bir komut olmasıdır ki bu da bize kolaylık sağlar. Daha da önemlisi, bir dosyayı yeniden adlandırmak için istediğiniz herhangi bir aracı kullanabilir ve ardından add/rm ile adresleyerek dosyayı katkı olarak işlemeye uygun hale getirebiliriz.