Git hakkında SSS

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Bu makalede, Git hakkında azure depoları için özel olarak uyarlanmış sık sorulan soruların yanıtlarını bulabilirsiniz. Uzak dalları yönetmek, geçerli dalınızı tanımlamak veya daha az yaygın diğer Git görevlerini işlemek istediğinizde, bu kılavuz yararlı ipuçları ve çözümler sağlar. Git iş akışınızı geliştirmek ve yaygın sorunları çözmek için aşağıdaki bölümleri inceleyin.

Uzak bir dalı yerel depoma nasıl kolayca indirebilirim?

İlk olarak, yapılandırılmış bir origin deponuz olduğundan emin olun. kullanarak git clonedeponuzu klonladıysanız bu olmalıdır. Yerel olarak mevcut olmayan bir dalı kullanıma aldığınızda, Git aynı ada sahip bir uzak dal olup olmadığını denetler. Varsa, Git uzak dala başvuran bir yerel dal oluşturur. İşlemeleri indirmek ve dal geçmişini yerel olarak güncelleştirmek için kullanın git pull .

Hangi dalda çalıştığımı nasıl öğrenebilirim?

Yerel dalları göstermek ve kullanıma alınan dalları vurgulamak için bağımsız değişken olmadan komutunu çalıştırın git branch . Visual Studio'da, yerel Git deposunda depolanan bir projeyle çalışırken durum çubuğu da geçerli dalı görüntüler.

Git işlemelerini ne zaman yapmalıyım?

Mantıksal olarak farklı değişiklikler için ayrı işlemeler yapmak en iyi yöntemdir. İşlemeleri bir logbook'taki girdiler olarak düşünün. Not almaya değer bir değişiklik yaptığınızda, bunu bir işlemeye kaydedin. Popüler bir yaklaşım, sık sık yerel işlemelere izin vermek, ancak göndermeden önce yeniden dengeleme yoluyla bunları sıkıştırmaktır. Bu, işleme geçmişini kolaylaştırma esnekliği sağlar.

Her dal tam işleme geçmişini koruyorsa, bu *main* işleme geçmişinin zaman içinde takip etmesini zorlaştırmıyor mu?

Çok sayıda işlemesi ve katkıda bulunanı olan büyük projeler, konu dallarının genel projeden daha fazla geliştirilmesini yansıtan bir main dal geçmişine neden olabilir. Git, işlemeleri sıkıştırıp yeniden dengeleme yoluyla dallardaki işlemeleri daraltmanıza olanak tanır. İşlemelerin sıkıştırılması, dal geçmişini daha az ayrıntılı hale getirerek birleştirildikten sonra ana daldaki işleme geçmişini basitleştirir.

Bir dosyada belirli bir değişikliği kimin yaptığını nasıl öğrenebilirim?

Bir dosyada git blame belirli bir değişikliği kimin yaptığını bulmak için komutunu kullanın. Yerel deponuzdan, hangi ilgi alanı satırlarını belirterek parametresiyle -L çalıştırabilirsinizgit blame. Blame , satırı son güncelleştiren işlemeyi ve işlemeyi yapan kişinin adını gösteren biçimlendirilmiş çıkış oluşturur.

> git blame Example_repo -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Example User 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 22) line 22 of the code

Blame işleme geçmişini sizin için arar. Ayrıca, kimin ne zaman ve ne zaman değişiklik yaptığını belirlemek için web portalında bir dosyanın geçmişini de gözden geçirebilirsiniz. Deponuz ve dalınız için Kod Gezgini'ni açın ve ilgilendiğiniz dosyayı seçin. Azure Repos, geçerli dalda bu dosya için eksiksiz bir işleme geçmişi gösterir.

Bazı dosyalarda değişiklik yaptım ve şimdi farklı bir dala göz atamıyorum veya çalışmamı yeniden temel alamıyorum.

Git'te farklı bir dala kullanıma almak, dosya sisteminizdeki dosyaların durumunu etkiler. Git, dalınızın durumunu temsil eden dosyalarla çalıştığından emin olmak için işleme geçmişini kullanır. Kaydedilmemiş değişiklikleriniz varken dalları değiştirmeye çalışırsanız, kullanıma alma sırasında bu değişikliklerin üzerine yazılır. Git değişikliklerinizi yanlışlıkla kaybetmenizi istemediği için ödeme işleminin gerçekleşmesini engeller. İki seçeneğiniz vardır:

Çekme isteği şu iletiyle birleştirilemiyor: 'Otomatik olarak birleştirilemiyor: İç git nesnelerinden biri (blob, ağaç, işleme veya etiket) çok büyük ve bu da TF401022 özel duruma neden oldu. LFS'yi kullanmayı deneyebilir, birleştirmenizi veya büyük işlemenizi birkaç küçük işlemeye bölebilirsiniz.'

Bu sorun, büyük ikili dosyalarda birleştirme çakışmaları ile ilgilidir. Dosyalar için geçerli sınır 100 MB'tır. Geçici çözüm, hedefi yerel olarak kaynakla birleştirerek, çakışmaları çözerek ve değişiklikleri göndererek birleştirme çakışmalarını yerel olarak çözmektir.

Git LFS (Büyük Dosya Depolama), yalnızca çakışmaları önlemek için değil, aynı zamanda kopyalama ve gönderme sürelerini etkileyen genel depo boyutunu yönetmek için de büyük ikili dosyaları depolamak için önerilir.

Biraz iş yaptım ama başka bir şeye geçmem gerekiyor. Değişiklikleri işlemeden daha sonra çalışmamı nasıl kaydedebilirim?

Değişikliklerinizi işlemeden kaydetmek istiyorsanız Git stashkullanın. Stash, dalınızdaki geçerli hazırlanmış ve kalıcı olmayan değişiklikleri kaydeder ve dalınızı son işlemenin durumuna döndürür. Daha sonra başka bir dala geçebilir, işinizi yapabilir ve daha sonra değişikliklerinizi geri yüklemek için komutunu çalıştırabilirsiniz stash apply .

git stash
Saved working directory and index state WIP on feature1: be26067 updated endpoint docs
HEAD is now at be26067

[git stash apply] komutunu çalıştırdığınızda, en son zulalanan değişiklikler geçerli dalınıza uygulanır. Çakışma varsa, [stash] çakışmayan dosyalar için değişiklikleri geri yükler ve çakışan dosyalarda çakışma işaretçileri oluşturur. Bu durumda değişiklikleri el ile birleştirmeniz gerekir.

Zulayı bitirdikten sonra [git stash drop] ile silin. Bu komut, son zulalanmış değişiklik kümesini kaldırır.

Birden çok zulanız olabilir, ancak bunları yönetmek için açıkça uygulamanız ve bırakmanız gereken el ile düzenleme gerekir. Git Stash belgelerinden daha fazla bilgi edinin.

Git komut satırı araçları için varsayılan düzenleyiciyi nasıl değiştirebilirim?

Varsayılan olarak, komut satırı Git işleme iletilerini isterken, yeniden temeller gerçekleştirirken ve tamamlanması için ek bilgi gerektiren diğer işleri yaparken bir komut satırı düzenleyicisi kullanır. Varsayılan düzenleyici kullanılarak git configyapılandırılır:

> git config core.editor _path_to_editor_ _options_to_editor_

Windows için Git, not defterini düzenleyici olarak ayarlamayı kolaylaştırır:

> git config core.editor notepad

Bu komut, Windows Not Defteri'ni Git bilgilerini gerektiği gibi düzenleyip Metni Git'ten Not Defteri'ne doğru şekilde geçirecek şekilde yapılandırıyor. Ayrıca şunları da belirtebilirsiniz:

> git config format.commitMessageColumns 72 

İşleme iletilerindeki metin sütunlarını tercih edilen 72'de tutmak için ve satırda bu karakter sınırına ulaştıktan sonra satır kaydırma.

İşlemelerimde görüntülenen kullanıcı adını ve e-postayı nasıl değiştirebilirim?

Git her işlemenin içine bir kullanıcı adı ve e-posta adresi bilgileri yerleştirir ve Azure Repos bu bilgileri işlemeleri görüntülerken ve çekme istekleriyle çalışırken kullanır. Komut satırında çalışıyorsanız, komutunu kullanarak git config görüntülenen ad ve e-posta bilgilerini güncelleştirebilirsiniz:

> git config --global user.email "example-user@example-site.com"
> git config --global user.name "Example User"

seçeneği, --global bu sistemdeki tüm Git depoları için işlemelere dahil edilen e-postayı ve adı ayarlar. Tek bir deponun ayarlarını değiştirmek istiyorsanız Git deposunun bulunduğu dizine geçmelisiniz ve yukarıdaki komutları bayrağı olmadan --global çalıştırmanız gerekir.

Visual Studio'dan ad ve e-posta ayarlarını da değiştirebilirsiniz. Git menüsünden Ayarlar Seçenekler iletişim kutusunda Git Genel Ayarları'nı veya Git Deposu Ayarları>Genel'i seçin.

Visual Studio 2019 sürüm 16.8 ve sonraki sürümleri, Takım Gezgini Git kullanıcı arabirimini korurken bir Git sürüm denetimi deneyimi sağlar. Takım Gezgini'ni kullanmak için, menü çubuğundan Araçlar>Seçenekler>Önizleme Özellikleri>Yeni Git kullanıcı deneyimi'nin işaretini kaldırın. Git özelliklerini her iki arabirimden de birbirinin yerine kullanabilirsiniz.

Ekip Gezgini'nde Ayarlar'ı seçin ve Git'in altında Genel Ayarlar veya Depo Ayarları bağlantısını seçin.