Git
Chapters ▾ 2nd Edition

2.2 Git Temelleri - Değişikliklerin Repoya Kaydedilmesi

Değişikliklerin Repoya Kaydedilmesi

Şu aşamada, yerel makinenizde bir Git reposuna ve önünüzde tüm dosyaları kullanıma hazır veya çalışmakta olan bir kopyasına sahip olmalısınız. Doğal olarak, proje kaydetmek istediğiniz duruma her ulaştığında değişiklik yapmaya ve bu değişikliklerin pozlarını (snapshot) reponuza kaydetmeye başlamak isteyeceksiniz.

Çalışma dizininizdeki her dosyanın iki durumdan birinde olabileceğini unutmayın: ``tracked`` (izlenen / takip edilen) veya ``untracked`` (izlenmeyen / takip edilmeyen). İzlenen dosyalar, son pozdaki dosyalardır: bunlar ``modified`` (değiştirilmiş), ``unmodified`` (değiştirilmemiş) veya ``staged`` (izleme alınmış; indekslenmiş) olabilirler. Kısacası izlenen dosyalar Git’in haberdar olduğu ve değişikliklerini takip ettiği dosyalardır.

İzlenmeyen dosyalar ise diğer her şeydir (çalışma dizininizdeki, son pozda olmayan ve izlemde olmayan dosyalardır). Bir repoyu ilk kez kopyaladığınızda, tüm dosyalarınız izlenecek ve ``unmodified`` (değiştirilmemiş) olarak işaretlenmiş olacaktır. Çünkü Git onları daha yeni teslim aldı ve siz henüz hiçbir değişiklik yapmadınız.

Siz dosyaları düzenlerken Git onları ``modified`` (değiştirilmiş) olarak görür, çünkü son Git işleminizden (commit, clone, vs) sonra bu dosyalarda değişiklik yaptınız. Çalışırken, bu değiştirilmiş dosyaları seçerek izleme alırsınız (katkılamak amacıyla indekslersiniz) ve ardından izleme alınmış tüm bu değişiklikleri katkı olarak işlersiniz. Ve bu döngü her değişiklikten sonra tekrarlanır.

Dosyalarınızın durumunun yaşam döngüsü.
Görsel 8. Dosyalarınızın durumunun yaşam döngüsü.

Dosyalarınızın Durumunu Denetleme

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:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

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 Dalları ü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:

$ echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
   (use "git add <file>..." to include in what will be committed)

    README

nothing added to commit but untracked files present (use "git add" to track)

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 Dosyaları İzleme

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:

$ git add README

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:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

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.

Değiştirilmiş Dosyaları İzleme Alma

Ş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:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

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:

$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

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:

$ vim CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

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 add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Özet-Durum Bilgisi

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:

$ git status -s
 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

İ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.

Dosyaları Yoksayma (Ignore)

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ı:

$ cat .gitignore
*.[oa]
*~

İ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:

  • Boş satırlar veya # ile başlayan satırlar dikkate alınmaz.

  • Standart glob desenleri işler. Yani yazdığınız kural çalışma ağacınızdaki tüm dosyalar için alt dizinleri de dahil olmak üzere geçerlidir.

  • Bu alt dizinlere inen yinelemeyi önlemek için dosya dizinine eğik çizgi (/) ile başlayabilirsiniz.

  • Kuralın geçerli olmasını istediğimiz belli bir dizini belirtmek için dosya dizinini eğik çizgiyle (/) sonlandırabilirsiniz.

  • Kuralın uygulanmasını istemediğiniz bir modeli ünlem işaretiyle (!) başlatarak reddedebilirsiniz.

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ı:

# .a uzantılı tüm dosyaları yoksay
*.a

# .a uzantılı tüm dosyaları yoksaysan da, lib.a dosyası bu kuralın istisnasıdır. lib.a dosyasındaki değişiklikleri izle
!lib.a

# Sadece bu dizindeki TODO dosyasını yoksay. Diğer dizinlerdeki TODO dosyalarını değil. (ör: subdir/TODO)
/TODO

# build dizinindeki ve onun alt dizinlerindeki tüm dosyaları yoksay
build/

# doc/notes.txt dosyasını yoksay ama doc/server/arch.txt dosyasını değil
doc/*.txt

# doc/ klasörü ve alt klasörlerinde yer alan tüm .pdf dosyalarını yoksay
doc/**/*.pdf
İpucu

Eğer projeniz için bir başlangıç noktasına ihtiyaç duyuyorsanız GitHub, https://github.com/github/gitignore adresinde pekçok farklı proje ve dilde ``.gitignore`` dosya örneklerinin kapsamlı bir listesini tutmaktadır.

Not

Basit projelerde, bir proje kök dizininde, tüm alt dizinler için geçerli olmak üzere tek bir ".gitignore" dosyası bulunur. Yine de alt dizinlerde ek .gitignore dosyalarının bulunması da mümkündür. Bu iç içe geçmiş .gitignore dosyalarındaki kurallar yalnızca bulundukları dizinin alt klasörlerinde bulunan dosyalar için geçerlidir. (Örneğin Linux çekirdeği kaynak reposunda 206 adet .gitignore dosyası bulunmaktadır.)

Birden fazla ".gitignore" dosyası bulunduğu durumlar bu kitabın kapsamı dışındadır. Bu konuda daha detaylı bilgiye konsol ekranınıza man gitignore komutu yazarak ulaşabilirsiniz.

İzleme Alınmış (Staged) ve Alınmamış (Unstaged) Değişiklikleri Görme

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:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

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:

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
 Please include a nice description of your changes when you submit your PR;
 if we have to read the whole diff to figure out why you're contributing
 in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR
 that highlights your work in progress (and note in the PR title that it's

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 --staged
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+My Project

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:

$ git add CONTRIBUTING.md
$ echo '# test line' >> CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

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

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 643e24f..87f08c8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -119,3 +119,4 @@ at the
 ## Starter Projects

 See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md).
+# test line

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:

$ git diff --cached
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
 Please include a nice description of your changes when you submit your PR;
 if we have to read the whole diff to figure out why you're contributing
 in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR
 that highlights your work in progress (and note in the PR title that it's
Not
Harici Araçlarda .Git Diff

Kitabın geri kalanında git diff komutunu çeşitli şekillerde kullanmaya devam edeceğiz. Çalışma ortamı ve repodaki kodlar arasındaki farkları görmek için konsol ekranı yerine görsel veya harici bir arayüz programını tercih ederseniz, bu farklılıklara bakmanın başka yolları da vardır. Eğer git diff yerine git difftool komutu çalıştırırsanız, bu farklardan herhangi birini "emerge", "vimdiff" ve daha birçok farklı yazılımda (ticari yazılımlar dahil) görüntüleyebilirsiniz. Sisteminizde hangilerinin mevcut olduğunu görmek için git difftool --tool-help komutunu çalıştırabilirsiniz.

Değişiklikleri Katkı Olarak İşlemek

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:

$ git commit

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):

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
#	new file:   README
#	modified:   CONTRIBUTING.md
#
~
~
~
".git/COMMIT_EDITMSG" 9L, 283C

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:

$ git commit -m "Story 182: Fix benchmarks for speed"
[master 463dc4f] Story 182: Fix benchmarks for speed
 2 files changed, 2 insertions(+)
 create mode 100644 README

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ını Atlamak

İ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:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -a -m 'added new benchmarks'
[master 83e38c7] added new benchmarks
 1 file changed, 5 insertions(+), 0 deletions(-)

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.

Dosyaları Silmek

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:

$ rm PROJECTS.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    PROJECTS.md

no changes added to commit (use "git add" and/or "git commit -a")

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

$ git rm PROJECTS.md
rm 'PROJECTS.md'
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    PROJECTS.md

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:

$ git rm --cached README

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

$ git rm log/\*.log

* 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:

$ git rm \*~

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

Dosyaları Taşıma

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:

$ git mv file_from file_to

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:

$ git mv README.md README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

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

$ mv README.md README
$ git rm README.md
$ git add README

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.

scroll-to-top