Sürüm Kontrolü mülakat soruları

.gitignore, Git'in izlememesi gereken bağımlılık, derleme çıktısı, günlük ve gizli bilgi gibi dosya ve klasörlerin kalıplarını listeleyen düz metin dosyadır.

En yaygın neden, kuralı eklemeden önce dosyanın zaten izleniyor olmasıdır; çünkü .gitignore yalnızca izlenmeyen dosyaları etkiler. git rm --cached <file> çalıştırıp (klasör için -r ekleyin) commit edin, hangi kuralın (varsa) eşleştiğini görmek için git check-ignore -v <file> kullanın.

Evet. .gitignore dosyasını commit etmek, aynı yok sayma kurallarını ekipteki herkesle paylaşır. Kendi editörünüzün oluşturduğu dosyalar gibi kişisel kurallar için .git/info/exclude ya da git config --global core.excludesFile ile ayarlanan genel bir ignore dosyası kullanın.

Yalnızca sır hiç commit edilmediyse. Parola ya da API anahtarı içeren bir dosya bir kez bile push edildiyse depo geçmişinde kalır; bu yüzden açığa çıkan anahtarları iptal edip yenilerini oluşturun.

Git'te branch, bir özellik ya da düzeltme üzerinde, birleştirene kadar ana kodu etkilemeden çalışmanızı sağlayan bağımsız bir geliştirme hattıdır.

git switch, Git 2.23'te eklenen daha yeni bir komuttur ve yalnızca tek bir işi yapar: branch değiştirmek. git checkout da branch değiştirebilir ama dosyaları geri yükleme gibi başka işleri de üstlenir; birçok yeni başlayan bunu kafa karıştırıcı bulur.

Branch, aynı depo içindeki ayrı bir çalışma hattıdır. Fork ise bir deponun genellikle farklı bir hesap altındaki tam kopyasıdır ve çoğunlukla yazma erişiminiz olmayan projelere katkı vermek için kullanılır.

2020 civarında büyük Git barındırma platformları ve birçok proje, daha kapsayıcı bir dil kullanmak için varsayılan branch adını master'dan main'e çevirdi. Git'in kendisi ise init.defaultBranch ayarıyla istediğiniz varsayılan adı seçmenize izin verir.

Git'te cherry-pick, belirli bir commit'in değişikliklerini geldiği branch'in geri kalanını birleştirmeden, mevcut branch'inize yeni bir commit olarak kopyalar.

Merge, başka bir branch'teki her commit'i sizinkine getirir. Cherry-pick ise yalnızca seçtiğiniz belirli commit'leri kopyalar ve branch'inizde yeni commit'ler oluşturur.

Evet. git cherry-pick a1b2c3d e4f5a6b örneğindeki gibi birkaç hash yazabilir ya da A'dan sonraki her commit'i B dahil olmak üzere uygulayan git cherry-pick A..B gibi bir aralık kullanabilirsiniz.

Kendi başına değil, ancak bilinçli kullanılmalıdır. Aynı değişikliği birçok branch'e cherry-pick etmek commit'leri çoğaltır ve geçmişi ile gelecekteki merge'leri kafa karıştırıcı hale getirebilir; bu yüzden en iyi, acil düzeltme ve backport gibi hedefli durumlarda işe yarar.

Code review, kod değişikliklerinin birleştirilmeden önce başka geliştiricilerce incelenmesidir; hataları yakalar, kaliteyi artırır, bilgi paylaşımını sağlar.

Değişikliğin iddia ettiği işi yaptığını, uç durumları ve hataları ele aldığını, okunabilir olduğunu ve mevcut tasarıma uyduğunu kontrol edin. Ayrıca güvenlik sorunlarına, eksik testlere ve gereksiz karmaşıklığa bakın; stil ayrıntılarını ise otomatik biçimlendiricilere ve linter'lara bırakın.

Pull request, bir değişikliğin birleştirilmesini önermenin mekanizmasıdır. Code review ise o değişikliği inceleme faaliyetidir; genellikle bir pull request içinde gerçekleşir, ancak yüz yüze ya da pair programming ile de yapılabilir.

Yapay zeka araçları yaygın hataların, stil sorunlarının ve güvenlik risklerinin çoğunu hızlıca yakalayabilir ve giderek daha çok ilk inceleyici olarak kullanılıyor. Ancak bir ekibin hedeflerini, ürün bağlamını ya da tasarım ödünleşimlerini henüz güvenilir biçimde anlamıyorlar; bu yüzden çoğu ekip birleştirmeden önce hâlâ insan onayı şart koşuyor.

Commit, Git'te projenin dosyalarının; benzersiz bir kimlik, yazar, zaman damgası ve değişikliği anlatan bir mesajla kaydedilmiş anlık görüntüsüdür.

Zaten paylaşılmış bir commit'i geri almak için, o commit'in tersini uygulayan yeni bir commit oluşturan git revert <hash> komutunu kullanın. En son yerel commit'inizi, değişiklikleri dosyalarınızda tutarak geri almak için git reset --soft HEAD~1 kullanın.

İyi bir commit mesajı, 'Add password reset email' gibi emir kipiyle yazılmış, yaklaşık 50 karakterlik kısa bir özet satırıyla başlar. Daha fazla bağlam gerekiyorsa bir boş satır bırakılır ve değişikliğin neden yapıldığını anlatan daha uzun bir açıklama eklenir.

git commit, yerel deponuza bir anlık görüntü kaydeder. git push ise yerel commit'lerinizi uzak bir depoya yükler; böylece başkaları da görebilir.

Conventional Commits, feat: add search gibi yapılandırılmış commit mesajları için bir şartnamedir; araçlar değişiklik günlüğü üretip sürümü otomatik seçer.

Şartname feat ve fix'i zorunlu tutar. Angular kuralından alınan yaygın ek türler docs, style, refactor, perf, test, build, ci, chore ve revert'tür.

Bir fix commit'i bir patch sürümüne, bir feat commit'i bir minor sürüme, kırıcı değişiklik olarak işaretlenmiş her commit de bir major sürüme karşılık gelir; böylece araçlar bir sonraki sürümü geçmişten hesaplayabilir.

Biçime uymayan mesajları reddetmek için commitlint'i, örneğin Husky ile, bir commit-msg Git hook'unda ve CI'da kullanın. Squash merge iş akışlarında bunun yerine pull request başlığı da kontrol edilebilir.

Detached HEAD, bir branch yerine belirli bir commit'i checkout ettiğiniz ve yaptığınız yeni commit'lerin hiçbir branch'e ait olmadığı bir Git durumudur.

Tutmak istediğiniz bir commit yapmadıysanız git switch main ile bir branch'e geri dönün. Commit yaptıysanız, önce onları bir branch'e koymak için git switch -c <new-branch> çalıştırın, ardından o branch'i her zamanki gibi merge edin ya da push edin.

Ayrıkken yapılan commit'ler risk altındadır, çünkü onları gösteren bir branch yoktur. Başka yere geçtikten sonra Git'in çöp toplaması onları silebilmeden önce bir süre, varsayılan olarak 30 gün boyunca git reflog ile bulunabilirler; bu yüzden tutmak istiyorsanız bir branch oluşturun.

Tag, hareket etmemesi gereken sabit bir işaretçidir; bu yüzden Git, yeni commit'lerin onu bir branch gibi ilerletmesine izin veremez. Bunun yerine HEAD'i doğrudan etiketlenmiş commit'e yönlendirir ve siz bir branch oluşturana kadar yeni commit'ler bağlantısız kalır.

Fast-forward merge, hedef branch'te diğer branch ayrıldığından beri yeni commit yoksa olur; Git merge commit'i oluşturmaz, işaretçiyi yalnızca ileri taşır.

Birleştirilen branch'te diğer branch'te olmayan commit yoksa, yani geçmiş ayrışmamışsa. Git o zaman varsayılan olarak merge commit'i oluşturmak yerine işaretçiyi ileri taşır.

Fast-forward mümkün olsa bile Git'i bir merge commit'i oluşturmaya zorlar; böylece özelliğin commit'leri geçmişte tek bir merge altında gruplu kalır.

Bu bir ekip tercihidir. Fast-forward'lar ve rebase'ler okunması ve bisect yapılması kolay, temiz ve doğrusal bir geçmiş verir. Merge commit'leri ise özelliklerin ne zaman ve nasıl entegre edildiğini korur. Birçok ekip küçük değişiklikleri squash ya da rebase eder, büyük özellikler için merge commit'leri kullanır.