Git'te veya diğer sürüm kontrol sistemlerinde çalışırken, "kaydetme" kavramı, bir kelime işlemcide veya diğer geleneksel dosya düzenleme uygulamalarında kaydetmekten daha incelikli bir süreçtir. "Kaydetme"nin geleneksel yazılım ifadesi Git'teki "commit" terimiyle eşanlamlıdır. Bir commit, "kaydet"in Git eşdeğeridir. Geleneksel kaydetme, mevcut bir dosyanın üzerine yazmak veya yeni bir dosya yazmak için kullanılan bir dosya sistemi işlemi olarak düşünülmelidir. Alternatif olarak, Git commit, bir dosya ve dizin koleksiyonu üzerinde hareket eden bir işlemdir.
Git ve SVN'deki değişiklikleri kaydetmek de farklı bir işlemdir. SVN commitleri veya 'check-in'ler', merkezi bir sunucuya uzaktan itme yapan işlemlerdir. Bu, bir SVN commitinin proje değişikliklerini tamamen 'kaydetmek' için İnternet erişimine ihtiyaç duyduğu anlamına gelir. Git commitleri yerel olarak yakalanıp oluşturulabilir, ardından git push -u Origin main komutu kullanılarak gerektiğinde uzak bir sunucuya gönderilebilir. İki yöntem arasındaki fark, mimari tasarımlar arasındaki temel farktır. Git, dağıtılmış bir uygulama modelidir, SVN ise merkezi bir modeldir. Dağıtılmış uygulamalar, merkezi bir sunucu gibi tek bir arıza noktasına sahip olmadıkları için genellikle daha sağlamdır.
Git'in "the stash" adı verilen ek bir kaydetme mekanizması vardır. stash, commit edilmeye hazır olmayan değişiklikler için geçici bir depolama alanıdır. stash, üç ağaçtan ilki olan çalışma dizini üzerinde çalışır ve geniş kullanım seçeneklerine sahiptir.
Bir Git Repository'si, belirli dosya veya dizinleri yok sayacak şekilde yapılandırılabilir. Bu, Git'in yok sayılan herhangi bir içerikteki değişiklikleri kaydetmesini engelleyecektir. Git, yok sayma listesini yöneten birden çok yapılandırma yöntemine sahiptir.
git add komutu, çalışma dizinindeki bir değişikliği hazırlama alanına ekler. Git'e, bir sonraki işlemde belirli bir dosyaya yönelik güncellemeleri dahil etmek istediğinizi söyler. Bununla birlikte, git add, depoyu gerçekten önemli bir şekilde etkilemez; siz git commit'i çalıştırana kadar değişiklikler gerçekten kaydedilmez.
git add ve git commit komutları, temel Git iş akışını oluşturur. Bunlar, ekiplerinin işbirliği modelinden bağımsız olarak her Git kullanıcısının anlaması gereken iki komuttur. Bir projenin sürümlerini repository geçmişine kaydetmenin araçlarıdır.
Bir proje geliştirmek, temel düzenleme/stage/commit modeli etrafında döner. İlk olarak, dosyalarınızı çalışma dizininde düzenlersiniz. Projenin mevcut durumunun bir kopyasını kaydetmeye hazır olduğunuzda, değişiklikleri git add ile aşamalandırırsınız. Aşamalı anlık görüntüden memnun kaldıktan sonra, bunu git commit ile proje geçmişine kaydedersiniz. Git reset komutu, bir işleme veya aşamalı anlık görüntüyü geri almak için kullanılır.
git add ve git commit'e ek olarak, eksiksiz bir işbirliğine dayalı Git iş akışı için üçüncü bir git push komutu gereklidir. git push, taahhüt edilen değişiklikleri işbirliği için uzak havuzlara göndermek için kullanılır. Bu, diğer ekip üyelerinin bir dizi kaydedilmiş değişikliğe erişmesini sağlar.
Git add komutu, depoya bir dosya ekleyen svn add ile karıştırılmamalıdır. Bunun yerine git add, değişikliklerin daha soyut düzeyinde çalışır. Bu, bir dosyayı her değiştirdiğinizde git add'in çağrılması gerektiği, oysa svn add'in her dosya için yalnızca bir kez çağrılması gerektiği anlamına gelir. Kulağa gereksiz gelebilir, ancak bu iş akışı, bir projeyi düzenli tutmayı çok daha kolaylaştırır.
git add komutunun birincil işlevi, çalışma dizinindeki bekleyen değişiklikleri git hazırlama alanına ilerletmektir. Aşama alanı, Git'in daha benzersiz özelliklerinden biridir ve bir SVN (hatta bir Mercurial) geçmişinden geliyorsanız, kafanızı etrafına sarmak biraz zaman alabilir. Bunu çalışma dizini ile proje geçmişi arasında bir arabellek olarak düşünmek yardımcı olur. Hazırlama alanı, çalışma dizini ve işlem geçmişi ile birlikte Git'in "üç ağacından" biri olarak kabul edilir.
Stage, son işlemeden bu yana yaptığınız tüm değişiklikleri işlemek yerine, ilgili değişiklikleri proje geçmişine fiilen işlemeden önce yüksek oranda odaklanmış anlık görüntüler halinde gruplandırmanıza olanak tanır. Bu, ilgisiz dosyalarda her türlü düzenlemeyi yapabileceğiniz, ardından geri dönüp sahneye ilgili değişiklikleri ekleyerek bunları mantıksal taahhütlere ayırabileceğiniz ve bunları parça parça işleyebileceğiniz anlamına gelir. Herhangi bir revizyon kontrol sisteminde olduğu gibi, atomik taahhütler oluşturmak önemlidir, böylece projenin geri kalanı üzerinde minimum etki ile hataları takip etmek ve değişiklikleri geri almak kolaydır.
Bir sonraki commit için
Bir sonraki commit için
Bir sonraki işleme eklemek için bir dosyanın bölümlerini seçmenize izin veren etkileşimli bir hazırlık oturumu başlatın. Bu size bir yığın değişiklik sunacak ve sizden bir komut isteyecektir. Parçayı hazırlamak için y'yi, parçayı yoksaymak için n'yi, daha küçük parçalara bölmek için s'yi, parçayı el ile düzenlemek için e'yi ve çıkmak için q'yu kullanın.
git commit komutu, projenin o anda aşamalı değişikliklerinin anlık görüntüsünü yakalar. Kaydedilmiş anlık görüntüler, bir projenin "güvenli" sürümleri olarak düşünülebilir; siz açıkça istemediğiniz sürece Git bunları asla değiştirmez. Git commit yürütülmesinden önce git add komutu, projede bir commit depolanacak değişiklikleri desteklemek veya 'stage' için kullanılır. Bu iki komut git commit ve git add en sık kullanılanlardan ikisidir.
Aynı adı paylaşsalar da git commit, svn commit gibi değildir. Bu paylaşılan terim, svn geçmişi olan Git'e yeni başlayanlar için bir kafa karışıklığı olabilir ve farkı vurgulamak önemlidir. Git commit ile svn commit karşılaştırmak, merkezi bir uygulama modeliyle (svn) dağıtılmış bir uygulama modeliyle (Git) karşılaştırmaktır. SVN'de bir commit, değişiklikleri yerel SVN istemcisinden uzak, merkezi, paylaşılan bir SVN deposuna iter. Git'te depolar dağıtılır, Anlık Görüntüler yerel depoya kaydedilir ve bu, diğer Git depolarıyla kesinlikle etkileşim gerektirmez. Git commitleri daha sonra isteğe bağlı uzak repository ye gönderilebilir.
Üst düzeyde, Git bir zaman çizelgesi yönetimi aracı olarak düşünülebilir. Commit, bir Git proje zaman çizelgesinin temel yapı taşı birimleridir. Commit, bir Git projesinin zaman çizelgesi boyunca anlık görüntüler veya kilometre taşları olarak düşünülebilir. Commit, bir projenin o andaki durumunu yakalamak için git commit komutuyla oluşturulur. Git Anlık Yedekleri her zaman yerel depoya kaydedilir. Bu, çalışan kopyanın merkezi depoya kaydedildiği SVN'den temel olarak farklıdır. Aksine Git, siz hazır olana kadar sizi merkezi depoyla etkileşim kurmaya zorlamaz. Hazırlama alanı, çalışma dizini ile proje geçmişi arasında bir tampon olduğu gibi, her geliştiricinin yerel deposu da katkıları ile merkezi depo arasında bir tampondur.
Bu, Git kullanıcıları için temel geliştirme modelini değiştirir. Git geliştiricileri, bir değişiklik yapmak ve bunu doğrudan merkezi depoya commit etmek yerine yerel depolarında commit biriktirme fırsatına sahip olur. Bunun SVN tarzı işbirliğine göre birçok avantajı vardır: bir özelliği atomik commit ayırmayı, ilgili commitleri birlikte gruplandırmayı ve merkezi depoda yayınlamadan önce yerel geçmişi temizlemeyi kolaylaştırır. Ayrıca, geliştiricilerin yalıtılmış bir ortamda çalışmasına olanak tanır ve entegrasyonu diğer kullanıcılarla birleşmek için uygun bir noktaya gelene kadar erteler. Tecrit ve ertelenmiş entegrasyon bireysel olarak faydalı olsa da, sık sık ve küçük birimler halinde entegrasyon bir ekibin yararınadır.
SVN ve Git arasındaki pratik farklılıkların yanı sıra, temel uygulamaları da tamamen farklı tasarım felsefelerini takip eder. SVN bir dosyanın farklılıklarını takip ederken, Git'in sürüm kontrol modeli anlık görüntülere dayalıdır. Örneğin, bir SVN taahhüdü, depoya eklenen orijinal dosyaya kıyasla bir farktan oluşur. Öte yandan Git, her dosyanın tüm içeriğini her işlemde kaydeder.
Bu, birçok Git işlemini SVN'den çok daha hızlı hale getirir, çünkü bir dosyanın belirli bir sürümünün farklarından "birleştirilmesi" gerekmez; her dosyanın tam revizyonu Git'in dahili veritabanından hemen edinilebilir. Git'in anlık görüntü modeli, dallanma ve birleştirme araçlarından işbirliği iş akışlarına kadar her şeyi etkileyerek sürüm kontrol modelinin neredeyse her yönü üzerinde geniş kapsamlı bir etkiye sahiptir.
Aşamalı anlık görüntüyü commit edin. Bu, sizden bir commit mesajı isteyen bir metin düzenleyici başlatacaktır. Bir mesaj girdikten sonra, dosyayı kaydedin ve gerçek commit oluşturmak için düzenleyiciyi kapatın.
Çalışma dizinindeki tüm değişikliklerin bir anlık görüntüsünü kaydedin. Bu, yalnızca izlenen dosyalarda yapılan değişiklikleri içerir (tarihlerinin bir noktasında git add ile eklenmiş olanlar).
Geçirilen bir kesinleştirme mesajıyla hemen bir kesinleştirme oluşturan bir kısayol komutu. Varsayılan olarak, git commit, yerel olarak yapılandırılmış metin düzenleyiciyi açar ve bir kesinleştirme mesajının girilmesini ister. -m seçeneğinin iletilmesi, bir satır içi mesaj lehine metin düzenleyici isteminden vazgeçecektir.
-a ve -m seçeneklerini birleştiren uzman bir kullanıcı kısayol komutu. Bu birleşim, hemen tüm aşamalı değişiklikler için bir commit oluşturur ve bir satır içi commit mesajı alır.
Bu seçenek, commit komutuna başka bir işlevsellik düzeyi ekler. Bu seçeneğin iletilmesi, son commiti değiştirecektir. Yeni bir commit oluşturmak yerine, aşamalı değişiklikler önceki commite eklenecektir. Bu komut, sistemin yapılandırılmış metin düzenleyicisini açacak ve önceden belirtilen kesinleştirme mesajını değiştirmenizi isteyecektir.
Diffing, iki input data setini alan ve aralarındaki değişiklikleri veren bir fonksiyondur. git diff, yürütüldüğünde Git veri kaynaklarında bir diff işlevi çalıştıran çok kullanımlı bir Git komutudur. Bu veri kaynakları, commitler, dallar, dosyalar ve daha fazlası olabilir. Bu belge, git diff ve farklı iş akışı modellerinin ortak çağrılarını tartışacaktır. Git diff komutu, bir Git deposunun mevcut durumunu analiz etmek için genellikle git status ve git log ile birlikte kullanılır.
Aşağıdaki örnekler basit bir repoda yürütülecektir. Repo aşağıdaki komutlarla oluşturulur:
Bu noktada git diff'i çalıştırırsak çıktı olmaz. Repoda diff'e herhangi bir değişiklik olmadığı için bu beklenen bir davranıştır. Repo oluşturulduktan ve diff_test.txt dosyasını ekledikten sonra, diff çıktısıyla denemeye başlamak için dosyanın içeriğini değiştirebiliriz.
Bu komutu çalıştırmak diff_test.txt dosyasının içeriğini değiştirir. Değiştirildikten sonra, bir farkı görebilir ve çıktıyı analiz edebiliriz. Şimdi git diff'i çalıştırmak aşağıdaki çıktıyı üretecektir:
Şimdi fark çıktısının daha ayrıntılı bir dökümünü inceleyelim:
Bu satır, farkın giriş kaynaklarını görüntüler. a/diff_test.txt ve b/diff_test.txt dosyalarının diff'e geçtiğini görebiliriz.
Bu satır, bazı dahili Git meta verilerini görüntüler. Büyük olasılıkla bu bilgilere ihtiyacınız olmayacak. Bu çıktıdaki sayılar, Git nesne sürümü karma tanımlayıcılarına karşılık gelir.
Bu satırlar, her bir diff giriş kaynağına semboller atayan bir göstergedir. Bu durumda, a/diff_test.txt dosyasındaki değişiklikler --- ile işaretlenir ve b/diff_test.txt dosyasındaki değişiklikler +++ simgesiyle işaretlenir.
Kalan diff çıktısı, diff 'parçaların' bir listesidir. Bir diff, yalnızca dosyanın değişen bölümlerini görüntüler. Mevcut örneğimizde, basit bir senaryo üzerinde çalıştığımız için sadece bir parçamız var. Parçaların kendi ayrıntılı çıktı semantiği vardır.
İlk satır yığın başlığıdır. Her öbeğin başına @@ sembolleri içine alınmış bir başlık eklenir. Başlığın içeriği, dosyada yapılan değişikliklerin bir özetidir. Basitleştirilmiş örneğimizde, -1 +1 yani birinci satırda değişiklikler oldu. Daha gerçekçi bir farkta, şöyle bir başlık görürsünüz:
Bu başlık örneğinde 34. satırdan başlayarak 6 satır çıkarılmıştır. Ayrıca 34. satırdan başlayarak 8 satır eklenmiştir. Fark öbeğinin kalan içeriği son değişiklikleri görüntüler. Değiştirilen her satırın başına, değişikliklerin hangi diff girişi versiyonundan geldiğini gösteren bir + veya - sembolü eklenir. Daha önce tartıştığımız gibi -, a/diff_test.txt dosyasındaki değişiklikleri ve + işareti, b/diff_test.txt dosyasındaki değişiklikleri gösterir.
git diff'in ayrıca değişiklikleri çok daha iyi ayrıntı düzeyiyle vurgulamak için özel bir modu vardır: -‐color-words. Bu mod, eklenen ve kaldırılan satırları boşluklara göre tokenize eder ve ardından bunları farklılaştırır.
Git kaynağını klonlarsanız, contrib adında bir alt dizin bulacaksınız. Git ile ilgili bir dizi araç ve henüz git çekirdeğine terfi ettirilmemiş diğer ilginç parçalar ve parçalar içerir. Bunlardan biri, diff-highlight adlı bir Perl betiğidir. Diff-highlight, diff çıktısının eşleşen satırlarını eşleştirir ve değişen alt sözcük parçalarını vurgular.
Şimdiye kadar gösterdiğimiz metin dosyası yardımcı programlarına ek olarak, git diff ikili dosyalar üzerinde çalıştırılabilir. Ne yazık ki, varsayılan çıktı pek yardımcı olmuyor.
Git, farkı gerçekleştirmeden önce ikili dosyalarınızın içeriğini metne dönüştürmek için bir kabuk komutu belirtmenize izin veren bir özelliğe sahiptir. Yine de biraz kurulum gerektiriyor. Öncelikle, belirli bir ikili dosya türünü metne nasıl dönüştüreceğinizi açıklayan bir textconv filtresi belirlemeniz gerekir. PDF'lerimi insanlar tarafından okunabilir HTML'ye dönüştürmek için pdftohtml (homebrew aracılığıyla kullanılabilir) adlı basit bir yardımcı program kullanıyoruz. Bunu, .git/config dosyanızı düzenleyerek tek bir havuz için veya ~ /.gitconfig dosyasını düzenleyerek genel olarak ayarlayabilirsiniz.
O zaman tek yapmanız gereken bir veya daha fazla dosya modelini pdfconv filtremizle ilişkilendirmek. Bunu, repository'nizinin kökünde bir .gitattributes dosyası oluşturarak yapabilirsiniz.
Yapılandırıldıktan sonra, git diff önce ikili dosyayı yapılandırılmış dönüştürücü betiği aracılığıyla çalıştıracak ve dönüştürücü çıktısını diff'leyecektir. Aynı teknik, her türlü ikili dosyadan faydalı farklar elde etmek için uygulanabilir, örneğin: zip'ler, kavanozlar ve diğer arşivler: pdf2html yerine unzip -l (veya benzeri) kullanmak, size bu dosyalar arasında eklenmiş veya kaldırılmış yolları gösterecektir. görüntüleri kaydeder: exiv2, görüntü boyutları gibi meta veri değişikliklerini göstermek için kullanılabilir belgeler: .odf, .doc ve diğer belge biçimlerini düz metne dönüştürmek için dönüştürme araçları mevcuttur. Bir tutamda, dizeler genellikle resmi bir dönüştürücünün bulunmadığı ikili dosyalar için çalışır.
git diff komutuna açık bir dosya yolu seçeneği iletilebilir. git diff'e bir dosya yolu iletildiğinde, diff işlemi belirtilen dosya kapsamına alınır. Aşağıdaki örnekler bu kullanımı göstermektedir.
Bu örnek, çağrıldığında ./path/to/file kapsamına alınmıştır, çalışma dizinindeki belirli değişiklikleri dizine karşı karşılaştırır ve henüz hazırlanmamış değişiklikleri gösterir. Varsayılan olarak git diff, HEAD ile karşılaştırmayı yürütür. Yukarıdaki örnekte HEAD öğesinin atlanması git diff ./path/to/file aynı etkiye sahiptir.
--cached seçeneğiyle git diff çağrıldığında, diff aşamalı değişiklikleri yerel depoyla karşılaştırır. --cached seçeneği --staged ile eşanlamlıdır.
Bir dosya yolu olmadan git diff'i çağırmak, deponun tamamındaki değişiklikleri karşılaştırır. Yukarıdaki, dosyaya özgü örnekler, ./path/to/file bağımsız değişkeni olmadan çağrılabilir ve yerel depodaki tüm dosyalarda aynı çıktı sonuçlarına sahip olabilir.
Varsayılan olarak git diff, son işlemeden bu yana kaydedilmemiş değişiklikleri size gösterecektir.
git diff, Git refs'lerini diff'e iletebilir. Bazı örnek referanslar, HEAD, etiketler ve dal adlarıdır. Git'teki her taahhüdün, GIT LOG'u çalıştırdığınızda alabileceğiniz bir taahhüt kimliği vardır. Bu taahhüt kimliğini git diff'e de iletebilirsiniz.
Dallar, diğer tüm ref girdileri gibi git diff ile karşılaştırılır.
Bu örnek, nokta operatörünü tanıtır. Bu örnekteki iki nokta, fark girişinin her iki dalın uçları olduğunu gösterir. Noktalar atlanırsa ve dallar arasında bir boşluk kullanılırsa aynı etki olur. Ek olarak, üç nokta operatörü vardır:
Üç nokta operatörü, ilk giriş parametresi dal 1'i değiştirerek farkı başlatır. Dal 1'i, iki fark girişi arasındaki paylaşılan ortak ata commitin bir ref'ine, Dal 1'in ve diğer-özellik-dalının ortak atasına değiştirir. Son parametre giriş parametresi, diğer özellik dalının ucu olarak değişmeden kalır.
Dallar arasında belirli bir dosyayı karşılaştırmak için, dosyanın yolunu üçüncü bağımsız değişken olarak git diff'e iletin.
git stash, başka bir şey üzerinde çalışabilmeniz için çalışma kopyanızda yaptığınız değişiklikleri geçici olarak rafa kaldırır (veya saklar) ve daha sonra geri gelip bunları yeniden uygulayabilirsiniz. Saklama, hızlı bir şekilde içerik değiştirmeniz ve başka bir şey üzerinde çalışmanız gerekiyorsa kullanışlıdır, ancak bir kod değişikliğinin ortasındasınız ve işlemeye tam olarak hazır değilsiniz.
git stash komutu, commit edilmemiş değişikliklerinizi (hem aşamalı hem de hazırlıksız) alır, daha sonra kullanmak üzere saklar ve ardından çalışan kopyanızdan geri döndürür. Örneğin:
Bu noktada değişiklik yapmakta, yeni commitler oluşturmakta, stashlar arasında geçiş yapmakta ve diğer Git işlemlerini gerçekleştirmekte özgürsünüz; sonra geri gelin ve hazır olduğunuzda stashınızı yeniden uygulayın. Stashın Git reponuz için yerel olduğunu unutmayın; Bastığınızda depolar sunucuya aktarılmaz.
Önceden saklanan değişiklikleri git stash pop ile yeniden uygulayabilirsiniz:
Stashınızı açar, değişiklikleri Stash tan kaldırır ve onları çalışan kopyanıza yeniden uygular. Alternatif olarak, değişiklikleri çalışan kopyanıza yeniden uygulayabilir ve bunları git stash Apply ile Stashınızda tutabilirsiniz:
Aynı saklanmış değişiklikleri birden fazla dal'a uygulamak istiyorsanız bu kullanışlıdır. Artık saklamanın temellerini bildiğinize göre, git stash ile ilgili bilmeniz gereken bir uyarı var: varsayılan olarak Git, izlenmeyen veya göz ardı edilen dosyalarda yapılan değişiklikleri saklamaz.
Varsayılan olarak, git stash'ı çalıştırmak şunları saklayacaktır: dizininize eklenen değişiklikler (aşamalı değişiklikler) şu anda Git tarafından izlenen dosyalarda yapılan değişiklikler (aşamalı olmayan değişiklikler) Ama saklanmayacak: çalışma kopyanızda henüz hazırlanmamış yeni dosyalar göz ardı edilen dosyalar Öyleyse, yukarıdaki örneğimize üçüncü bir dosya eklersek, ancak onu hazırlamazsak (yani git add'i çalıştırmıyoruz), git stash onu saklamaz.
-u seçeneğinin (veya --include-untracked) eklenmesi, git stash'a izlenmeyen dosyalarınızı da saklamasını söyler:
Git stash'ı çalıştırırken -a seçeneğini (veya --all) ileterek yok sayılan dosyalara da değişiklikler ekleyebilirsiniz.
Tek bir Stash ile sınırlı değilsiniz. Birden çok depo oluşturmak için git stash'ı birkaç kez çalıştırabilir ve ardından bunları görüntülemek için git stash list'i kullanabilirsiniz. Varsayılan olarak, Stashlar, şubenin üstünde basitçe bir "WIP" (devam eden çalışma) olarak tanımlanır ve Stashı nereden oluşturduğunuzu commit eder. Bir süre sonra her stashın ne içerdiğini hatırlamak zor olabilir:
Biraz daha bağlam sağlamak için, git stash save "message" kullanarak stashlarınıza bir açıklama eklemek iyi bir uygulamadır:
Varsayılan olarak git stash pop, en son oluşturulan stash'ı yeniden uygular: stash@{0} Tanımlayıcısını son bağımsız değişken olarak ileterek hangi stash'ın yeniden uygulanacağını seçebilirsiniz, örneğin:
Bir Stash'ın özetini git stash show ile görüntüleyebilirsiniz:
Veya bir stashın tam farkını görüntülemek için -p seçeneğini (veya --patch) iletin:
Ayrıca, yalnızca tek bir dosyayı, bir dosya koleksiyonunu veya dosyaların içindeki bireysel değişiklikleri saklamayı da seçebilirsiniz. -p seçeneğini (veya --patch) git stash'a iletirseniz, çalışma kopyanızdaki değiştirilen her "parça"yı yineleyecek ve saklamak isteyip istemediğinizi soracaktır:
Git, çalışma kopyanızdaki her dosyayı üç şeyden biri olarak görür: izlenen - önceden hazırlanmış veya işlenmiş bir dosya; izlenmemiş - hazırlanmamış veya işlenmemiş bir dosya; veya yoksayıldı - Git'in açıkça yok sayması söylendiği bir dosya.
Yoksayılan dosyalar genellikle, depo kaynağınızdan türetilebilen veya başka bir şekilde işlenmemesi gereken derleme yapıları ve makine tarafından oluşturulan dosyalardır. Bazı yaygın örnekler şunlardır: /node_modules veya /packages içerikleri gibi bağımlılık önbellekleri .o, .pyc ve .class dosyaları gibi derlenmiş kod /bin, /out veya /target gibi çıktı dizinleri oluşturun .log, .lock veya .tmp gibi çalışma zamanında oluşturulan dosyalar .DS_Store veya Thumbs.db gibi gizli sistem dosyaları .idea/workspace.xml gibi kişisel IDE yapılandırma dosyaları
yok sayılan dosyalar, havuzunuzun kök dizininde teslim edilen .gitignore adlı özel bir dosyada izlenir. Açık bir git yoksay komutu yoktur: bunun yerine, yoksaymak istediğiniz yeni dosyalarınız olduğunda .gitignore dosyası elle düzenlenmeli ve işlenmelidir. .gitignore dosyaları, göz ardı edilip edilmeyeceklerini belirlemek için deponuzdaki dosya adlarıyla eşleşen kalıplar içerir.
Atlassian sitesinde verilen tabloda .gitignore için verilen kalıpları inceleyebilirsiniz.