Git'te nasıl sıfırlanır, geri yüklenir ve önceki duruma nasıl geri dönülür
Git ile çalışmanın az bilinen (ve farkında olmayan) yönlerinden biri, önceki konumunuza nasıl kolayca geri dönebileceğinizdir - yani, depodaki büyük değişiklikleri bile kolayca nasıl geri alacağınız. Bu makalede, nasıl sıfırlayacağınızı, geri yükleyeceğinizi ve bir önceki duruma nasıl tamamen geri döneceğinizi anlamanıza yardımcı olacağız.Bu sadece birkaç basit ve zarif Git komutu gerektirir.
Sıfırla
Git'in reset komutu ile başlıyoruz. Aslında, bunu bir "geri alma" olarak düşünebilmelisiniz - yerel ortamınızı bir önceki işleme döndürür. Buradaki "yerel ortam" terimi, yerel deponuza, hazırlık alanınıza ve çalışma dizininize karşılık gelir.
Önce Şekil 1'e bir göz atın. Burada Git'teki bir dizi işlemi temsil eden bir diyagramımız var. Git'te dal, yalnızca belirli bir işleme işaret eden adlandırılmış bir taşınabilir işaretleyicidir. Burada ana dalımız, zincirdeki kaydetmeye bir göstericidir.
Şekil 1: Depo, hazırlık alanı ve çalışma dizini içeren yerel ortam
Ana şubemizin ne olduğuna bakarsanız, şimdiye kadar oluşturduğumuz commit zincirine bakabilirsiniz.
$ git log --oneline
b764644 Üç satırlı dosya
7c709f0 İki satırlı dosya
9ef9173 Tek satırlı dosya
Bir önceki işleme geri dönmek istersek ne olur? Çok basit - sadece dal işaretçisini hareket ettirmemiz gerekiyor. Git, bunu bizim için yapmak için reset komutunu sağlar. Örneğin, ana veriyi geçerli gönderime sıfırlarsak ve iki gönderim konumunu geri alırsak aşağıdaki yöntemlerden birini kullanabiliriz:
$ git sıfırlama 9ef9173
(9ef9173'ün commit SHA1 değerini kullanın)
veya:
$ git sıfırlama akımı ~ 2
("Geçerli" etiketinden önce, -2'nin göreli değerini kullanın)
Şekil 2, operasyonun sonucunu göstermektedir. Bundan sonra, mevcut dalda (master) bir git log komutu çalıştırırsak, sadece bir commit göreceğiz.
$ git log --oneline
9ef9173 Tek satırlı dosya
Şekil 2: Sıfırlamadan sonra
Git reset komutu ayrıca yerel ortamın diğer bölümlerini tatmin edici bir gönderimle güncellemek için bazı seçenekler içerir. Bu seçenekler şunları içerir: depodaki işaretli gönderimi kalıcı olarak sıfırlar, çalışma dizinini gönderilen içerikle doldurur ve hazırlama alanını sıfırlar; yalnızca depodaki imleci sıfırlar; ve karışık (varsayılan değer) işaretçiyi sıfırlar Ve evreleme alanı.
Bu seçenekler belirli durumlarda çok kullanışlıdır, örneğin git reset --hard < sha1 | referans > Bu komut, yerel olarak taahhüt edilmeyen tüm değişikliklerin üzerine yazacaktır. Aslında, geçici depolama alanını sıfırlar (temizler) ve sıfırladığınız gönderilmiş içerikle çalışma alanındaki içeriğin üzerine yazar. Zor seçeneği kullanmadan önce, gerçekten yapmak istediğiniz şeyin bu olduğundan emin olun, çünkü bu komut taahhüt edilmeyen değişikliklerin üzerine yazacaktır.
onarmak
Git revert komutunun gerçek sonucu sıfırlamaya benzer, ancak yöntemi farklıdır. Sıfırlama komutu (varsayılan), değişikliği "geri almak" için dal işaretçisini zincirde geri taşımaktır ve geri döndürme komutu, değişikliği "iptal etmek" için zincire yeni bir işlem eklemektir. Bu etkiyi çok kolay görmek için Şekil 1'e tekrar bakın. Zincirdeki her kayıt için dosyaya bir satır eklersek, bunun bir yolu reset kullanarak bu kaydı sürüme sadece iki satırla döndürmektir, örneğin: git reset HEAD ~ 1.
Diğer bir yöntem, üçüncü satırı silmek için yeni bir kaydetme eklemektir, böylece son son iki satırlı bir sürüm haline gelir - asıl etki de bu değişikliği iptal etmektir. Yukarıdaki amaca ulaşmak için bir git revert komutu kullanın, örneğin:
$ git HEAD'i geri döndür
Yeni bir kaydetme eklediğinden, Git aşağıdaki commit bilgisini isteyecektir:
"Üç satırlı dosya" yı geri döndür
Bu, b764644bad524b804577684bf74e7bca3117f554 işlemini geri döndürür.
# Lütfen değişiklikleriniz için kaydetme mesajını girin. Satırlar başlıyor
'#' ile # yok sayılır ve boş bir mesaj kaydetmeyi iptal eder.
# Şube yöneticisinde
# Yapılması gereken değişiklikler:
# değiştirildi: dosya1.txt
#
Şekil 3 (aşağıda), geri döndürme işleminin sonucunu göstermektedir.
Şimdi bir git log komutu çalıştırırsak, önceki commit'den önce yeni bir commit göreceğiz.
$ git log --oneline
11b7712 "Üç satırlı dosyayı" geri döndür
b764644 Üç satırlı dosya
7c709f0 İki satırlı dosya
9ef9173 Tek satırlı dosya
İşte bu dosyanın çalışma dizinindeki mevcut içeriği:
$ kedi < dosya adı >
Satır 1
Hat 2
Şekil 3 Geri döndürme işleminden sonra
Kurtarma veya sıfırlama nasıl seçilir?
Neden sıfırlama işlemini geri döndürmeyi seçmelisiniz? Kaydetme zincirinizi uzak bir depoya ittiyseniz (diğer insanlar zaten kodunuzu çekip çalışmaya başlayabilir), değişiklikleri almaları için geri döndürme işlemi çok kolay bir yoldur. Bunun nedeni, Git iş akışının dalın sonuna çok iyi işlemlemeler ekleyebilmesidir, ancak biri dal işaretçisini sıfırladığında, bir grup kaydetme artık görünür olmayacaktır, bu da zor olabilir.
Git ile bu şekilde çalıştığımızda, temel kurallarımızdan biri şudur: yerel deponuzda bu yolu, gönderilmemiş kodu değiştirmek için kullanmak mümkündür. Kaydetme uzak depoya gönderildiyse ve diğer kişiler onu çalışmak için zaten kullanıyor olabilirse, kaydetme geçmişini yeniden yazan bu değişikliklerden kaçınılmalıdır.
Kısacası, diğer insanların halihazırda kullanmakta olduğu bir taahhüt zincirinin geçmişini geri almak, iptal etmek veya yeniden yazmak istiyorsanız, meslektaşlarınız yaptıkları değişiklikleri orijinal zincirle birleştirmeye çalıştıklarında, daha fazlasını yapmaları gerekebilir. iş. Başkaları tarafından gönderilen ve kullanılan kodda değişiklik yapmanız gerekiyorsa, değişiklikleri yapmadan önce onlarla iletişim kurmalı ve önce değişikliklerini birleştirmelerini istemelisiniz. Ardından, bu izinsiz giriş işleminin birleştirilecek içeriği kalmadıktan sonra, bir kopyasını çekerler.
Sıfırlama işlemini yaptıktan sonra, orijinal tamamlama zincirinin hala o konumda olduğunu fark etmiş olabilirsiniz. İşaretçiyi hareket ettirdik ve sonra sıfırlama kodu önceki işleme geri döndü, ancak herhangi bir kaydetmeyi silmedi. Başka bir deyişle, işaret ettiğimiz orijinal kesinlemeyi bildiğimiz sürece, dalın orijinal zincirinin başına dönerek işaretçiyi önceki konuma "geri yükleyebiliriz":
git sıfırla < sha1 of commit >
Kaydetme değiştirildiğinde, Git'te yaptığımız diğer birçok işlemde de benzer şeyler olur. Yeni kaydetme oluşturulur ve ilgili işaretçi yeni bir zincire taşınır, ancak eski tamamlama zinciri hala mevcuttur.
Yeniden tabanla
Şimdi bir şube geri ödemesine bakıyoruz. İki dalımız olduğunu varsayalım: ana ve özellik ve tamamlama zinciri aşağıdaki Şekil 4'te gösteriliyor. Ustanın taahhüt zinciri C4- > C2- > C1- > C0'ın commit zinciri ve özelliği C5- > C3- > C2- > C1- > C0.
Şekil 4: Ana ve özellik dallarının kaydetme zinciri
Şubedeki commit kayıtlarına bakarsak aşağıdaki gibi görünmeleri gerekir. (Anlama kolaylığı için, C gönderim bilgisi anlamına gelir)
$ git log --oneline yöneticisi
6a92e7a C4
259bf36 C2
f33ae68 C1
5043e79 C0
$ git log --oneline özelliği
79768b8 C5
000f9ae C3
259bf36 C2
f33ae68 C1
5043e79 C0
İnsanlara Git'te yeniden tabanı "tarihin birleşmesi" olarak düşünebileceğinizi söylüyorum. Esasen Git, bir daldaki her farklı kaydı başka bir dala "yeniden oynatmaya" çalışır.
Bu nedenle, bir özellik dalını ana makineye yeniden düzenlemek ve C4 ile birleştirmek (örneğin, özellik zincirine eklemek) için temel Git komutlarını kullanabiliriz. İşlem komutları aşağıdaki gibidir:
$ git ödeme özelliği
$ git rebase yöneticisi
İlk olarak, çalışmanızı üstüne geri sarmak için kafayı geri sarın ...
Uygulanıyor: C3
Uygulama: C5
Tamamlandıktan sonra, gönderim zincirimiz aşağıdaki Şekil 5'e benzeyecektir.
Şekil 5: Rebase komutu tamamlandıktan sonra commit zinciri
Ardından, gönderim geçmişine bakalım, aşağıdaki gibi görünmelidir.
$ git log --oneline yöneticisi
6a92e7a C4
259bf36 C2
f33ae68 C1
5043e79 C0
$ git log --oneline özelliği
c4533a5 C5
64f2047 C3
6a92e7a C4
259bf36 C2
f33ae68 C1
5043e79 C0
C3 've C5', ana daldaki kesinleştirme zincirinin "en üstünde" olduğunu ve değişiklikler nedeniyle yeni işlemlerin yaratıldığını unutmayın. Ama aynı zamanda "orijinal" C3 ve C5'in, geri tepmeden sonra hala orada olduğuna dikkat edilmelidir - sadece onlara işaret eden başka bir dal olmadığı için.
Bu geri ödemeyi yaparsak ve daha sonra istediğimiz sonucun bu olmadığını belirlersek ve geri almayı umarsak, aşağıdaki örneği yapabiliriz:
$ git sıfırlama 79768b8
Bu basit değişiklik nedeniyle, şubemiz artık geri ödeme işleminden önceki ile aynı konuma yeniden yönlendirilecek - tam olarak geri alma işlemine eşdeğer (Şekil 6).
Şekil 6: Yeniden taban işlemi geri alındıktan sonra
Ya önceki bir operasyonun işaret ettiği bir şubede neyin sunulduğunu hatırlayamazsanız? Neyse ki Git komutları yine de size yardımcı olabilir. Bu şekilde, çoğu işlem için işaretçileri değiştirebilirsiniz ve Git orijinal kaydetmenizi hatırlayacaktır. Aslında, .git depo dizinindedir, ORIG_HEAD adında özel bir dosya olarak kaydedin. Değiştirilmeden önce bu yol, referansların çoğunu içeren bir dosyaydı. Bu dosyayı tararsak, içeriğini görebiliriz.
$ cat .git / ORIG_HEAD
79768b891f47ce06f13456a7e222536ee47ad2fe
Reset komutunu daha önce de belirtildiği gibi kullanabiliriz, orijinal zincire geri döner. O zaman tarihi aşağıdaki gibi olacak:
$ git log --oneline özelliği
79768b8 C5
000f9ae C3
259bf36 C2
f33ae68 C1
5043e79 C0
Reflog, bu bilgileri almak için başka bir yerdir. reflog, yerel deponuzdaki ilgili anahtarların veya değişikliklerin ayrıntılı bir açıklama listesidir. İçeriğini görüntülemek için git reflog komutunu kullanabilirsiniz:
$ git reflog
79768b8 HEAD @ {0}: sıfırlama: 79768b'ye geçme
c4533a5 HEAD @ {1}: yeniden ödeme tamamlandı: referanslara / kafalara / özelliğe geri dönülüyor
c4533a5 HEAD @ {2}: yeniden taban: C5
64f2047 HEAD @ {3}: yeniden taban: C3
6a92e7a HEAD @ {4}: rebase: ödeme yöneticisi
79768b8 HEAD @ {5}: ödeme: özellikten özelliğe geçiş
79768b8 HEAD @ {6}: tamamlama: C5
000f9ae HEAD @ {7}: ödeme: ana bilgisayardan özelliğe geçiş
6a92e7a HEAD @ {8}: commit: C4
259bf36 HEAD @ {9}: ödeme: özellikten ustaya geçiş
000f9ae HEAD @ {10}: tamamlama: C3
259bf36 HEAD @ {11}: kullanıma alma: ana bilgisayardan özelliğe geçiş
259bf36 HEAD @ {12}: tamamlama: C2
f33ae68 HEAD @ {13}: commit: C1
5043e79 HEAD @ {14}: commit (başlangıç): C0
Günlükte listelenen ilgili adlandırma biçimini kullanabilir ve her şeyi sıfırlamayı görürsünüz:
$ git sıfırlama HEAD @ {1}
Git'in "değiştirme" zinciri oluştuğunda orijinal kesinleştirme zincirini nasıl izlediğinin temel ilkesini anladıktan sonra, Git'te bazı değişiklikler yapmak artık o kadar da korkunç olmayacak. Bu, güçlü Git'in temel yeteneklerinden biridir: herhangi bir şeyi çok hızlı ve kolay bir şekilde deneyebilmek ve başarısız olursa geri alabilmek.
