10 Genel Git Sorunları ve Nasıl Onarılır

Aslında bu makaleyi Ekim 2014'te Codementor için yazdım. Oldukça yeni git kullanıcılardan deneyimli geliştiricilere kadar herkes için bir şeyler olmalı.

1. Yerel dosya değişikliklerini atın

Bazen bir problemi hissetmenin en iyi yolu dalmak ve kodla uğraşmaktır. Maalesef, işlemde yapılan değişiklikler bazen optimalin altında kalmaktadır, bu durumda dosyayı orijinal durumuna döndürmek en hızlı ve en kolay çözüm olabilir:

git ödeme - Gemfile # belirtilen yolu sıfırla
git checkout - lib bin #, birden fazla argümanla da çalışır

Merak ediyorsanız, çift çizgi (-) komut satırı yardımcı programlarının komut seçeneklerinin sonunu göstermesi için yaygın bir yoldur.

2. Yerel taahhütleri geri al

Ne yazık ki, bazen yanlış yolda olduğumuzu anlamamız biraz zaman alıyor ve o zamana kadar bir veya daha fazla değişiklik yerel olarak yapılmış olabilir. Git sıfırlama işlemi kullanışlı olduğunda:

git reset HEAD ~ 2 # son iki taahhüdü geri al, değişiklikleri sakla
git reset - hard HEAD ~ 2 # son iki işlemi geri al, değişiklikleri at

--Hard seçeneğine dikkat edin! Çalışma ağacınızı ve dizini sıfırlar, böylece tüm değişiklikleriniz kaybedilmez.

3. Bir dosyayı dosya sisteminizden kaldırmadan gitten kaldırın

Git ekleme işlemi sırasında dikkatli değilseniz, işleme almak istemediğiniz dosyaları ekleyebilir. Bununla birlikte, git rm, hem çalışma alanınızdan hem de istediğiniz şekilde olmayabilir dosya sisteminizden kaldırır. Bu durumda, yalnızca aşamalı sürümü kaldırdığınızdan emin olun ve aynı hatayı ikinci kez yapmaktan kaçınmak için dosyayı .gitignore'a ekleyin:

git reset dosya ismi # veya git rm - önbellek dosya ismi
yankı dosya adı >> .gitignore #, yeniden eklemeyi önlemek için .gitignore'a ekle

4. Bir taahhüt mesajı düzenleme

Yazım hatası olur, ancak neyse ki taahhüt mesajlarında bunları düzeltmek çok kolaydır:

git commit --amend # mesajı başlatmak için $ EDITOR
git commit --amend -m "Yeni mesaj" # yeni mesajı doğrudan ayarla

Fakat bu git-amend'in sizin için yapabileceği bir şey değil. Bir dosya eklemeyi unuttun mu? Sadece ekleyin ve önceki taahhüdünüzü değiştirin!

git forgotten_file ekle git commit --amend

Lütfen unutmayın - değişiklik aslında öncekinin yerine geçen yeni bir taahhüt yaratacaktır, bu yüzden zaten merkezi bir havuza itilmiş olan komisyonları değiştirmek için kullanmayın. Başka hiçbir geliştiricinin önceki sürümü henüz kontrol etmediğinden ve kendi çalışmasına dayandığından kesinlikle eminseniz bu kuralın istisnası yapılabilir, bu durumda zorla basma (git push - force) yine de iyi olabilir. Ağaç geçmişi, yerel olarak değiştirildiği için --force seçeneği burada gereklidir; bu, hızlı ileri birleştirme mümkün olmadığından, itmenin uzak sunucu tarafından reddedileceği anlamına gelir.

5. bastırmadan önce yerel taahhütleri temizleyin

--End çok yararlı olsa da, yeniden değerlendirmek istediğiniz taahhüdün son değil ise yardımı olmaz. Bu durumda etkileşimli bir yeniden düzenleme kullanışlı olacaktır:

git rebase - etkileşimli
# bu dal için herhangi bir takip bilgisi belirtmediyseniz
# yukarı akış ve uzak şube bilgileri eklemeniz gerekir:
git rebase - etkileşimli orijinli dal

Bu, yapılandırılmış düzenleyicinizi açar ve size aşağıdaki menüyü sunar:

pick 8a20121 Ruby versiyonunu 2.1.3'e yükseltin
22dcc45 seç Fantezi bir kütüphane ekle
# Fcb7d7c..22dcc45 dosyasını fcb7d7c üzerine yeniden oluşturun
#
# Komutlar: # p, seç = kullanım taahhüdü
# r, reword = taahhüt kullan, ancak taahhüt mesajını düzenle
# e, edit = kullanım taahhüdü, ancak değişiklik yapmayı bırak
# s, squash = kullanım taahhüdü, ancak önceki taahhüde dönüştür
# f, fixup = "squash" gibi, ancak bu işlemin günlük iletisini at
# x, exec = Çalıştır komutu (satırın geri kalanı) kabuk kullanarak
#
# Bu satırlar yeniden sipariş edilebilir; yukarıdan aşağıya doğru idam edilirler.
#
# Eğer burada bir çizgi çıkarırsanız, KAYIT OLACAKTIR.
#
# Ancak, her şeyi kaldırırsanız, rebase iptal edilecektir.
#
# Boş taahhütlerin yorumlandığına dikkat edin

En üstte, yerel komutların bir listesini görecek ve ardından mevcut komutların bir açıklamasını göreceksiniz. Güncellemek istediğiniz taahhütleri seçin, seçiminizi tekrar özetlemek için değiştirin (veya kısa r için) ve mesajı düzenleyebileceğiniz yeni bir görünüme yönlendirilirsiniz.

Bununla birlikte, yukarıdaki listeden görülebileceği gibi, etkileşimli yeniden düzenlemeler basit taahhütlü mesaj düzenlemeden çok daha fazlasını sunar: listeden silerek taahhütleri tamamen kaldırabilir, ayrıca onları düzenleyebilir, yeniden sıralayabilir ve ezebilirsiniz. Squashing, birkaç işlemi bir araya getirmenize izin verir, bu özellik özellik dallarında uzaktan kumandaya göndermeden önce yapmak istediğim bir şeydir. Artık “unutulmuş dosya ekle” ve “Yazım hatası düzelt” e sonsuza dek kaydedilmedi!

6. Geri alma işlemi tamamlandı

Önceki ipuçlarında gösterilen düzeltmelere rağmen, hatalı komisyonlar bazen merkezi depoya girerler. Yine de bu, umutsuzluğa sebep olmaz, çünkü git, tekli veya çoklu taahhütleri geri almanın kolay bir yolunu sunar:

git revert c761f5c # belirtilen kimliğe olan taahhüdü geri döndürür
git revert HEAD ^ #, sonuncu ikinci sırayı geri alır
git geri dönüş geliştirmek ~ 4..develop ~ 2 # bir dizi komisyonu geri alır

Ek geri dönüş komisyonları oluşturmak istemezseniz, ancak çalışma ağacınıza yalnızca gerekli değişiklikleri uygularsanız, --no-commit / -n seçeneğini kullanabilirsiniz.

# son taahhüdünü geri al
git revert -n HEAD

Man 1 git-revert adresindeki manuel sayfa daha fazla seçenek listesi ve bazı ek örnekler sunar.

7. Tekrarlanan birleştirme çatışmalarından kaçının

Her geliştiricinin bildiği gibi, birleştirme çatışmalarını düzeltmek sıkıcı olabilir, ancak aynı çatışmayı tekrar tekrar (örneğin uzun süre çalışan özellik dallarında) çözmek tamamen can sıkıcıdır. Geçmişte bundan sıkıntı çektiğiniz takdirde, kullanılmayan yeniden kullanım için kaydedilen çözünürlük özelliğini öğrenmekten memnuniyet duyarsınız. Tüm projeler için etkinleştirmek üzere global yapılandırmanıza ekleyin:

git config --global rerere.enabled true

Alternatif olarak .git / rr-cache dizinini elle oluşturarak bunu proje bazında etkinleştirebilirsiniz.

Bu kesinlikle herkes için bir özellik değil, ancak ihtiyacı olan insanlar için gerçek zaman tasarrufu olabilir. Ekibinizin aynı anda çeşitli özellik dallarında çalıştığını hayal edin. Şimdi hepsini bir test edilebilir yayın öncesi dalında birleştirmek istiyorsunuz. Beklendiği gibi, çözeceğiniz birkaç birleştirme çakışması var. Ne yazık ki, şubelerden birinin henüz orada olmadığı ortaya çıktı, bu yüzden tekrar birleştirmeye karar veriyorsunuz. Şube nihayet hazır olduğunda birkaç gün (veya hafta) sonra tekrar birleştirirsiniz, ancak kaydedilen kararlar sayesinde, aynı birleştirme çatışmalarını tekrar çözmek zorunda kalmazsınız.

Man sayfası (man git-rerere), daha sonraki kullanım durumları ve komutları hakkında daha fazla bilgiye sahiptir (git rerere durumu, git rerere diff, vb.).

8. Birleşmeden sonra bir şeyleri kıran taahhüdü bulun

Büyük bir birleşme sonrasında hataya neden olan taahhüdün izini sürmek oldukça zaman alabilir. Neyse ki git git-bisect şeklinde harika bir ikili arama imkanı sunuyor. İlk önce başlangıç ​​kurulumunu yapmanız gerekir:

git bisect start # biseksiyon oturumunu başlatır
git bisect bad # mevcut düzeltmeyi kötü olarak işaretler
git bisect iyi revizyon # bilinen son iyi revizyonu işaretler

Bu işlemden sonra, bilinen “iyi” ve “kötü” sürümleri arasında otomatik olarak bir revizyon yapılacaktır. Şimdi özelliklerinizi tekrar çalıştırabilir ve taahhüdünüzü “iyi” veya “kötü” olarak işaretleyebilirsiniz.

git bisect iyi # veya git bisec kötü

Bu işlem, hatayı tanıtan taahhütleri alana kadar devam eder.

9. Git kancalarıyla sık yapılan hatalardan kaçının

Bazı hatalar tekrar tekrar oluyor, ancak git iş akışının belirli bir aşamasında belirli kontrolleri veya temizleme görevlerini yürüterek kaçınılması kolay olacaktır. Bu tam olarak kancaların tasarlandığı senaryodur. Yeni bir kanca oluşturmak için, .git / hooks'a çalıştırılabilir bir dosya ekleyin. Senaryonun adı el kitabında (man githooks) tam bir listesi bulunan mevcut kancalardan birine karşılık gelmelidir. Ayrıca, tüm projelerinizde kullanacağınız global kancaları, git'in yeni bir depo başlatırken kullanacağı bir şablon dizini oluşturarak tanımlayabilirsiniz (daha fazla bilgi için git git-init adamına bakın). ~ / .Gitconfig içindeki bir giriş ve bir örnek şablon dizini şöyle görünür:

[içinde]
    templatedir = ~ / .git_template
  
→ ağaç .git_template
  .git_template
  └── kancalar
      └── ön taahhüt

Yeni bir depo başlattığınızda, şablon dizindeki dosyalar projenizin .git dizinindeki ilgili konuma kopyalanır.

Ardından, her bir işlem mesajının “# 123” gibi bir bilet numarasına atıfta bulunmasını sağlayacak, biraz kesinleşmiş bir örnek bir msg kancası var.

#! / usr / bin / env yakut
message = File.read (ARGV [0])

Mesaj olmadıkça = ~ / \ s * # \ d + /
  koyar "[POLİTİKA] Mesajınız bir bilete referans vermedi."
  çıkış 1
son

10. Her şey başarısız olduğunda

Şimdiye kadar, git ile çalışırken genel hataların nasıl çözüleceğine dair oldukça geniş bir zemin oluşturduk. Birçoğunun yeterince kolay çözümü var, ancak birinin büyük silahları çıkarması ve tüm bir dalın tarihini yeniden yazması gereken zamanlar var. Bunun için yaygın bir kullanım örneği, halka açık bir depoya tahsis edilmiş hassas verilerin (örneğin, üretim sistemlerinin giriş bilgileri) kaldırılmasıdır:

git filtre dalı - kuvvet - dex filtresi \
  'git rm --cached --ignore-unmatch secrets.txt' \
  --prune-empty - etiket adı filtre kedisi - - tüm

Bu, secrets.txt dosyasını her daldan ve etiketten kaldıracaktır. Ayrıca, yukarıdaki işlem sonucunda boş kalacak olan taahhütleri de kaldıracaktır. Bunun, projenizin tüm geçmişini yeniden yazacağını ve bunun da dağıtılmış bir iş akışında çok rahatsız edici olabileceğini unutmayın. Ayrıca, söz konusu dosya kaldırılmış olmasına rağmen, içerdiği kimlik bilgileri yine de tehlikeye atılmalı!

GitHub, hassas verilerin kaldırılması konusunda çok iyi bir öğreticiye sahiptir ve git-filter-branch, çeşitli filtreler ve seçenekleri ile ilgili tüm ayrıntılara sahiptir.

Başlangıçta gist.github.com adresinde yayınlandı.