git status komutu, çalışma dizininin ve hazırlama alanının durumunu görüntüler. Hangi değişikliklerin aşamalandırıldığını, hangilerinin yapılmadığını ve hangi dosyaların Git tarafından izlenmediğini görmenizi sağlar. Durum çıktısı, commit edilen proje geçmişiyle ilgili herhangi bir bilgi göstermez. Bunun için git log kullanmanız gerekiyor.
Git Tag : Etiketler, Git geçmişindeki belirli noktalara işaret eden referanslardır. git etiketi genellikle geçmişte işaretlenmiş bir sürüm sürümü için kullanılan bir noktayı yakalamak için kullanılır.
Git Blame : Git Blame üst düzey işlevi, bir dosyadaki belirli işlenmiş satırlara eklenmiş yazar meta verilerinin görüntülenmesidir. Bu, belirli bir kodun geçmişini keşfetmek ve kodun bir repoya ne, nasıl ve neden eklendiği hakkındaki soruları yanıtlamak için kullanılır.
Git Log : git log komutu, kaydedilmiş anlık görüntüleri görüntüler. Proje geçmişini listelemenizi, filtrelemenizi ve belirli değişiklikleri aramanızı sağlar.
git log komutu, kaydedilmiş anlık görüntüleri görüntüler. Proje geçmişini listelemenizi, filtrelemenizi ve belirli değişiklikleri aramanızı sağlar. Git durumu, çalışma dizinini ve hazırlama alanını incelemenize izin verirken, git log yalnızca commit edilen geçmiş üzerinde çalışır. Günlük çıktısı, commitleri basitçe filtrelemekten tamamen kullanıcı tanımlı bir biçimde görüntülemeye kadar çeşitli şekillerde özelleştirilebilir. Git günlüğünün en yaygın yapılandırmalarından bazıları aşağıda sunulmuştur.
Varsayılan biçimlendirmeyi kullanarak tüm commit geçmişini görüntüleyin. Çıktı birden fazla ekranı kaplıyorsa, kaydırmak için Boşluk tuşunu ve çıkmak için q tuşunu kullanabilirsiniz.
Commit sayısını sınırlayın. Örneğin, git log -n 3 yalnızca 3 işlem gösterecektir. Her commiti tek bir satıra yoğunlaştırın. Bu, proje geçmişine ilişkin üst düzey bir genel bakış elde etmek için kullanışlıdır.
Sıradan git günlüğü bilgilerinin yanı sıra, hangi dosyaların değiştirildiğini ve her birine eklenen veya silinen ilgili satır sayısını ekleyin.
Her bir commiti temsil eden yamayı görüntüleyin. Bu, proje geçmişiniz hakkında sahip olabileceğiniz en ayrıntılı görünüm olan her bir commitin tam farkını gösterir.
Belirli bir yazarın commitlerini arayın. Bağımsız değişken, düz bir dize veya normal bir ifade olabilir.
Düz bir dize veya normal bir ifade olabilen, ile eşleşen bir kesinleştirme mesajına sahip commitlerini arayın.
Yalnızca < beri > ve < bitiş > arasında gerçekleşen commitleri göster. Her iki argüman da bir commitleri kimliği, bir şube adı, HEAD veya başka herhangi bir revizyon referansı olabilir.
Yalnızca belirtilen dosyayı içeren commitleri görüntüleyin. Bu, belirli bir dosyanın geçmişini görmenin kolay bir yoludur.
Dikkate alınması gereken birkaç yararlı seçenek. --graph flag mesajlarının sol tarafında commit metin tabanlı bir grafiğini çizer. --decorate, gösterilen commitlerin dal adlarını veya etiketlerini ekler. --oneline, commit bilgilerini tek bir satırda göstererek, bir bakışta commitlere göz atmayı kolaylaştırır.
< tagname > öğesini, etiketin oluşturulduğu andaki repo durumuna semantik bir tanımlayıcı ile değiştirin. Yaygın bir model, git etiketi v1.4 gibi sürüm numaralarını kullanmaktır. Git, açıklamalı ve hafif etiketler olmak üzere iki farklı etiket türünü destekler. Önceki örnek, hafif bir etiket oluşturdu. Hafif etiketler ve Açıklamalı etiketler, repoladıkları eşlik eden meta veri miktarında farklılık gösterir. En iyi uygulama, Açıklamalı etiketleri genel ve Hafif etiketleri özel olarak kabul etmektir. Açıklamalı etiketler, etiketleyici adı, e-posta ve tarih gibi ekstra meta verileri repolar. Bu, genel yayın için önemli bir veridir. Hafif etiketler aslında bir commitin 'yer imleridir', bunlar yalnızca bir commitin adı ve işaretçisidir, ilgili commitin hızlı bağlantılar oluşturmak için kullanışlıdır.
Açıklamalı etiketler, Git veritabanında tam nesneler olarak repolanır. Yinelemek gerekirse, etiketleyici adı, e-posta ve tarih gibi ekstra meta verileri repolarlar. Commitlere ve commit mesajlarına benzer Açıklamalı etiketlerin bir etiketleme mesajı vardır. Ek olarak, güvenlik için açıklamalı etiketler GNU Privacy Guard (GPG) ile imzalanabilir ve doğrulanabilir. Git etiketleme için önerilen en iyi uygulamalar, ilişkili tüm meta verilere sahip olabilmeniz için açıklamalı etiketleri hafife tercih etmektir.
Bu komutu çalıştırmak, v1.4 ile tanımlanan yeni bir açıklamalı etiket oluşturacaktır. Komut daha sonra, daha fazla meta veri girişi istemek için yapılandırılmış varsayılan metin düzenleyiciyi açacaktır.
Bu komutun çalıştırılması önceki çalıştırmaya benzer, ancak komutun bu sürümüne -m seçeneği ve bir mesaj iletilir. Bu, hemen yeni bir etiket oluşturacak ve -m seçeneğiyle iletilen iletiyi kaydetmek için yerel metin düzenleyiciyi açmaktan vazgeçecek olan git commit -m'ye benzer bir kolaylık yöntemidir.
Bu komutu yürütmek, v1.4-lw olarak tanımlanan basit bir etiket oluşturur. Hafif etiketler -a, -s veya -m seçenekleri olmadan oluşturulur. Hafif etiketler, yeni bir etiket sağlama toplamı oluşturur ve bunu projenin reposunun .git/ dizininde saklar.
Repodaki ekitekleri sıralamak için bunu kullanın:
output bu şekilde olucaktır
Etiketlerin listesini iyileştirmek için -l seçeneği bir joker karakter ifadesiyle iletilebilir:
Bu önceki örnek, -l seçeneğini ve -rc önekiyle işaretlenmiş tüm etiketlerin bir listesini döndüren, geleneksel olarak sürüm adaylarını tanımlamak için kullanılan -rc'nin bir joker ifadesini kullanır.
Önceki etiketleme örnekleri, örtük commitler üzerindeki işlemleri göstermiştir. Varsayılan olarak git etiketi, HEAD'in başvurduğu committe bir etiket oluşturur. Alternatif olarak git etiketi, belirli bir commite ref olarak iletilebilir. Bu, HEAD varsayılanı yerine geçirilen commiti etiketleyecektir. Daha eski commitlerin bir listesini toplamak için git log komutunu yürütün.
Git log'u çalıştırmak, bir commit listesi çıkarır. Bu örnekte, yeni etiket için en çok commit edilen Birleştirme dalı 'özelliğini' seçeceğiz. Git'e geçmek için commit SHA karmasına başvurmamız gerekecek:
Yukarıdaki git etiketi çağrısını yürütmek, önceki git log örneğinde seçtiğimiz commit için v1.2 olarak tanımlanan yeni bir açıklamalı kesinleştirme oluşturacaktır.
Mevcut bir etiketle aynı tanımlayıcıya sahip bir etiket oluşturmaya çalışırsanız Git aşağıdaki gibi bir hata verir:
Ek olarak, daha eski bir commiti mevcut bir etiket tanımlayıcısıyla etiketlemeye çalışırsanız Git aynı hatayı atar. Mevcut bir etiketi güncellemeniz gerektiğinde -f FORCE seçeneği kullanılmalıdır.
Yukarıdaki komutu çalıştırmak, 15027957951b64cf874c3557a0f3547bd83b3ff6 taahhüdünü v1.4 etiket tanımlayıcısına eşler. v1.4 etiketi için mevcut tüm içeriği geçersiz kılar.
Etiketleri paylaşmak dalları itmeye benzer. Varsayılan olarak git Push, etiketleri göndermez. Etiketler açıkça git Push'a iletilmelidir.
Birden fazla etiketi aynı anda itmek için --tags seçeneğini git push komutuna iletin. Başka bir kullanıcı bir repoyu klonladığında veya çektiğinde, yeni etiketleri alacaktır.
Bir Reponun durumunu git checkout komutunu kullanarak bir etikette görüntüleyebilirsiniz.
Yukarıdaki komut v1.4 etiketini kontrol edecektir. Bu, repoyu ayrılmış bir HEAD durumuna getirir. Bu, yapılan değişikliklerin etiketi güncellemeyeceği anlamına gelir. Yeni bir müstakil commit oluşturacaklar. Bu yeni müstakil commit, herhangi bir şubenin parçası olmayacak ve yalnızca commitlerin SHA karması tarafından doğrudan erişilebilir olacaktır. Bu nedenle, ayrılmış bir HEAD durumunda değişiklik yaparken her zaman yeni bir dal oluşturmak en iyi uygulamadır.
Etiketleri silmek basit bir işlemdir. -d seçeneğinin ve bir etiket tanımlayıcının git etiketine iletilmesi, tanımlanan etiketi siler.
Bu örnekte, v1, v2, v3'ü gösteren etiketlerin bir listesini görüntülemek için git etiketi yürütülür, Ardından v1 etiketini silen git tag -d v1 yürütülür.
git blame komutu, kapsamlı kullanım seçeneklerine sahip çok yönlü bir sorun giderme yardımcı programıdır. Git blame üst düzey işlevi, bir dosyadaki belirli işlenmiş satırlara eklenmiş yazar meta verilerinin görüntülenmesidir. Bu, bir dosyanın geçmişinin belirli noktalarını incelemek ve satırı değiştiren son yazarın kim olduğu konusunda bağlam elde etmek için kullanılır. Bu, belirli bir kodun geçmişini keşfetmek ve kodun bir depoya ne, nasıl ve neden eklendiği hakkındaki soruları yanıtlamak için kullanılır.
Git blame genellikle bir GUI ekranıyla birlikte kullanılır. Bitbucket gibi çevrimiçi Git barındırma siteleri, blame için kullanıcı arabirimi sarmalayıcıları olan blame görünümleri sunar. Bu görüşlere, çekme istekleri ve commitler etrafındaki işbirlikçi tartışmalarda atıfta bulunulur. Ek olarak, Git entegrasyonuna sahip çoğu IDE'nin dinamik blame görünümleri de vardır.
git Blame göstermek için biraz geçmişe sahip bir havuza ihtiyacımız var. Açık kaynaklı git-blame-example projesini kullanacağız. Bu açık kaynak projesi, farklı yazarlardan birkaç commit içeren bir README.md dosyası içeren basit bir havuzdur. Git Blame kullanım örneğimizin ilk adımı, örnek depoyu git klonlamaktır.
Artık örnek kodun bir kopyasına sahip olduğumuza göre onu git blame ile keşfetmeye başlayabiliriz. Örnek deponun durumu git log kullanılarak incelenebilir. Commit geçmişi aşağıdaki gibi görünmelidir:
git blameyalnızca tek tek dosyalarda çalışır. Yararlı çıktılar için bir dosya yolu gereklidir. Git blame varsayılan olarak çalıştırılması, basitçe komutların yardım menüsünün çıktısını verecektir. Bu örnek için README.MD dosyası üzerinde işlem yapacağız. Proje için belge kaynağı olarak bir git deposunun kök dizinine bir BENİOKU dosyası eklemek yaygın bir açık kaynak yazılım uygulamasıdır.
Bu, README.md dosyasının ilk 13 satırının bir örneğidir.
-L seçeneği, çıktıyı istenen satır aralığıyla sınırlayacaktır. Burada çıktıyı 1'den 5'e kadar olan satırlarla sınırladık.
-e seçeneği, kullanıcı adı yerine yazarın e-posta adresini gösterir.
-w seçeneği, boşluk değişikliklerini yok sayar. Önceki bir yazar, sekmelerden boşluklara geçerek veya yeni satırlar ekleyerek bir dosyanın aralığını değiştirmişse, bu, ne yazık ki, bu değişiklikleri göstererek git suçu çıktısını gizler.
-M seçeneği, aynı dosya içinde taşınan veya kopyalanan satırları algılar. Bu, satırları taşıyan veya kopyalayan son yazar yerine satırların orijinal yazarını bildirir.
-C seçeneği, başka dosyalardan taşınan veya kopyalanan satırları algılar. Bu, satırları taşıyan veya kopyalayan son yazar yerine satırların orijinal yazarını bildirir.
git blame, bir satırı değiştiren son yazarı görüntülerken, çoğu zaman bir satırın orijinal olarak ne zaman eklendiğini bilmek isteyeceksiniz. Bu git blame kullanarak başarmak zahmetli olabilir. -w, -C ve -M seçeneklerinin bir kombinasyonunu gerektirir. git log komutunu kullanmak çok daha uygun olabilir.
Belirli bir kod parçasının eklendiği veya değiştirildiği tüm orijinal commitleri listelemek için git log'u -S seçeneğiyle çalıştırın. -S seçeneğini aradığınız kodla birlikte ekleyin. Örnek olarak kullanmak için yukarıdaki README çıktısındaki satırlardan birini alalım. README çıktısının 12. Satırından "CSS3D and WebGL renderers" metnini alalım.
Bu çıktı bize README'deki içeriğin 3 farklı yazar tarafından 3 kez eklendiğini veya değiştirildiğini gösterir. Orijinal olarak Mr.doob tarafından cb20237cc commitine eklenmiştir. Bu örnekte, git log'un başına --pretty-format seçeneği eklenmiştir. Bu seçenek, git log'un varsayılan çıktı biçimini git log biçimiyle eşleşen bir biçime dönüştürür.