Bir zaman yolcusu kılavuzu Git

İçerik

• 01. Yakın geçmişi değiştirin
• $ git add article.md $ git commit -m ’değişiklik bölümünün ilk taslağı’ [master 8dbf5d5] 1. değişiklik bölümünün ilk taslağı değiştirildi, 47 ekleme (+) oluşturma modu 100644 article.md
• 02. Yakın geçmişi geri al
• 03. Düzenli bir geçmişe sahip olun
• 04. Yakın geçmişi temizleyin
• 05. Tüm tarihi yeniden yazın
• 06. Güç ve esneklik
• Bunu beğendin mi? Bunları oku!

Bilim adamları zamanda geri gitme hayalini yıkarken Git, geçmişin yanlışlarının düzeltilmesi gerektiğinde dördüncü boyut üzerinde kontrol sunuyor. Dağıtılmış sürüm kontrol sistemi, bir havuzun geçmişini temizlemek için taahhütlerin değiştirilmesine, atılmasına, yeniden düzenlenmesine ve değiştirilmesine izin verir.

Ancak deneyimli bir zaman yolcusunun uyarılarına dikkat edin. Git nedensellik yasasına uyar; Git deposundaki her kayıt, kendisinden önceki commit ile ayrılmaz bir şekilde bağlantılıdır. Bir commit'i değiştirmek, alternatif bir gerçeklik yaratarak, sonradan gelen tüm taahhütleri değiştirir. Geçmişi değiştirmek tehlikeli olabilir ve - ender durumlar haricinde - yalnızca, değiştirilen olaylara başka kimse tarafından gözlenmediyse yapılmalıdır. Zaten bir uzaktan kumandaya itilmiş olan dallar değiştirilmemelidir.

Git ile tarihi yeniden yazmanın yollarını keşfederken bana katılın.

01. Yakın geçmişi değiştirin

Her ne sebeple olursa olsun, insan beyni bir e-postadaki "Gönder" düğmesine bastıktan hemen sonra önemli bir şeyi hatırlamaya hazır görünüyor ve bir konuşma bittikten sonra her zaman doğru kelimeler aklına geliyor. Aynı şekilde, Git'te bir taahhütte bulunduktan hemen sonra bir hata yaptığımı sıklıkla fark ediyorum. Git geçmişini yeniden yazmanın en güvenli ve en yaygın biçimi, en son kaydetmeyi değiştirmektir.

Bu makale bir Git deposunda yazılmıştır. İlk taahhüt, havuzun amacını açıklayan bir BENİOKU oluşturmaktı.

$ git ekle.
$ git commit -am "BENİOKU Ekle"
[ana (kök işleme) 6261ead] BENİOKU Ekle
2 dosya değiştirildi, 12 ekleme (+)
100644 README.md modu oluşturma
mod 100644 article.md oluştur

Oops, taahhüt ettikten sonra, taahhüt ettiğimi fark ettim article.md, bunlar sadece bazı notlar ve girişin ilk birkaç cümlesiydi. Henüz o dosyayı işleme koyma niyetinde değildim, öyleyse onu geçmişten kaldıralım.

$ git rm --cached article.md
rm ’article.md’

- önbelleğe alınmış argüman git rm Git'e dosyanın kaldırılmasını hazırlamasını, ancak dosyayı dosya sisteminden gerçekten silmemesini söyler. Dosyayı da silmek istiyorsanız, bu argümanı dışarıda bırakın.

Ayrıca, başka bir commit oluşturacak olsaydık yapacağımız gibi başka değişiklikler de yapabiliriz, örneğin README.md ve onları sahnelemek git ekle. Önceki taahhüdü değiştirin. --amend bayrak git commit:

$ git commit --amend
[master 667f8c9] BENİOKU Ekle
1 dosya değiştirildi, 7 ekleme (+)
100644 README.md modu oluşturma

Git, önceki commit mesajının düzenlenmesine izin vermek için bir düzenleyici açar. Git günlüğü artık hala yalnızca bir kaydetme olduğunu ve bu kaydetmenin yalnızca README.md.

$ git log --oneline --stat
667f8c9 README Ekle
README.md | 7 +++++++
1 dosya değiştirildi, 7 ekleme (+)

İlerleme kaydedildiğine göre şimdi bu makaleyi teslim edelim.

$ git add article.md $ git commit -m ’değişiklik bölümünün ilk taslağı’ [master 8dbf5d5] 1. değişiklik bölümünün ilk taslağı değiştirildi, 47 ekleme (+) oluşturma modu 100644 article.md

02. Yakın geçmişi geri al

Bazen bir işlemde o kadar çok hata olur ki, onu geri almak daha kolaydır. Belki yanlış şubeye kaydedilmiştir veya yanlışlıkla istenmeyen dosyaların bulunduğu bir dizin eklenmiştir.

$ git sıfırlama KAFA ^

Bu, Git'e önceki işlemeyi kaldırmasını, ancak bu yürütme tarafından sunulan değişiklikleri yerel olarak tutmasını söyler. git sıfırla güçlüdür ve yanlış kullanılırsa yıkıcı olabilir. Git-scm.com'da bunun hakkında daha fazla okumaya değer.

Günlük artık en son kaydetmenin gittiğini gösteriyor, ancak article.md hala değiştirildi.

$ git log --oneline
667f8c9 README Ekle

$ git durum -s
M article.md

Buradan, değişiklikler farklı bir şubeye işlenebilir, saklanabilir, atılabilir veya değiştirilebilir ve yeniden taahhüt edilebilir.

03. Düzenli bir geçmişe sahip olun

Git'i bir ekiple kullandıysanız, hiç şüphe yok ki bir itmenin reddedildiğini görmüşsünüzdür.

$ git itme kaynağı yöneticisi
[email protected]'a: bkeepers / git-history.git
! [reddedildi] ana -> ana (hızlı ileri sarma)
hata: '[email protected]: bkeepers / git-history.git' adresine bazı referanslar gönderilemedi
ipucu: Mevcut şubenizin ucu geride olduğu için güncellemeler reddedildi
ipucu: uzaktaki karşılığı. Uzaktan değişiklikleri birleştirin (ör. "Git pull")
ipucu: tekrar itmeden önce.
ipucu: Ayrıntılar için "git push --help" bölümündeki "Hızlı ilerlemelerle ilgili not" a bakın.

Bu mesaj büyük ve ürkütücü görünse de aslında oldukça faydalıdır. İpuçları bize, işimize başladığımızdan beri ekip üyelerimizden birinin değişiklikleri zorladığını ve bunları, genellikle koşarak elde etmemiz gerektiğini söylüyor. git çekme. İpucu ayrıca Git belgelerindeki "hızlı ileri alma" hakkındaki nota bakmanızı da önerir. Bu tavsiyeye katılıyorum.

Koşu git çekme uzak değişiklikleri getirecek ve bunları yerel değişikliklerimizle birleştiren yeni bir işlem oluşturacaktır. Birleştirme işleminde yanlış bir şey olmasa da, revizyon geçmişine gereksiz karmaşıklık ekler.

$ git log --decorate --graph --oneline
* aaf6c0c (HEAD, ana) Dalın ana kaynağını birleştir
|
| * 9f7e4de README'yi Güncelle
* | 00165a8 değişiklik bölümünün ilk taslağı
|/
* 667f8c9 (kaynak / sıfırlama) BENİOKU Ekle

Geçmişimizi daha net ve okunabilir kılan şey, değişikliklerimizi alıp bunları uzaktan değişikliklerin üzerine uygulamanın bir yoludur, örneğin:

$ git pull - rebase kaynak yöneticisi
İlk olarak, çalışmanızı üstüne geri sarmak için kafayı geri sarın ...
Uygulanıyor: README'yi güncelle

Bu, düzeltme geçmişinin, değişiklik bir ekip üyesi taahhüdünü verdikten sonra yapılmış gibi görünmesini sağlar.

$ git log --decorate --graph --oneline
* 8dbf5d5 değişiklik bölümünün ilk taslağı
* c408281 güncelleme BENİOKU
* 667f8c9 BENİOKU Ekle

Git geçmişimizin artık çok daha temiz ve taranması daha kolay olduğunu görebilirsiniz.

Bir depo birden fazla uzaktan kumandaya itilmediği sürece, çekerken yeniden sıralama neredeyse her zaman iyi bir fikirdir. Git'i otomatik olarak yeniden temel alacak şekilde yapılandırdım.

$ git config --global branch.autosetuprebase her zaman

Revizyon geçmişini düzenli tutmak yüzeysel görünebilir, ancak büyük bir projeyi yönetirken son derece yardımcı olur.

04. Yakın geçmişi temizleyin

Bazen birkaç yanlış adımdan sonra daha iyi bir yol olduğu net değildir. Git’in esnekliği, yol boyunca kontrol noktaları oluşturmayı kolaylaştırır ve işler ters giderse geri dönülebilecek bir nokta sunar.

Günlük gelişimimde mümkün olduğunca sık taahhüt ederim. Ne zaman kendi kendime düşünsem, "Tamam, bu yapıldı, şimdi ne olacak?", Taahhüt ederim. Bu, olayların sırasını doğru bir şekilde yansıtan bir revizyon geçmişine yol açarken, birçok küçük işlemin gürültüsü aslında büyük projelerin sürdürülebilirliğini engelleyebilir. Bu yüzden, değişikliklerimi ekibimle paylaşmaya hazır olduğumda, yayınlanmamış taahhütlerimi gözden geçirip temizliyorum.

Etkileşimli bir yeniden temel, taahhütlerin düzenlenmesine, birlikte ezilmesine veya bir şubenin yakın geçmişinden tamamen kaldırılmasına olanak tanır.

Bu makaledeki ilerlememi gözden geçirirken, birkaç utanç verici yazım hatası keşfettim. Depo henüz kimseyle paylaşılmadığından, orijinal kaydetmedeki yazım hatalarını düzelterek izlerimi kapattım. Orijinal hatamı korudum, böylece deponun yazım hataları dalını kontrol ederek takip edebilirsiniz.

İlk olarak, yazım hatalarını düzeltmek için iki yeni işlem oluşturdum.

$ git log --oneline
7445019 Değişikliğin yazım hatalarını düzeltme
b0377f9 Başlıktaki yazım hatasını düzeltin
b1cdd72 çekmenin ilk taslağı --rebase
2fbe35b sıfırlamanın ilk taslağı
7bb9109 Değişiklik bölümünün ilk taslağı
667f8c9 README Ekle

Düzeltilmesi gereken taahhüdü not edin. Her iki yazım hatası da commitdendi 7bb9109, değişiklik bölümünün ilk taslağı. Geri ödemeyi aşağıdakilerden önce revizyondan başlatın:

$ git rebase -i 7bb9109 ^

Git, editörü, işlemlerin listesi ve çok yararlı bir mesajla açacaktır.

7bb9109 değişiklik bölümünün ilk taslağını seç
sıfırlamanın ilk taslağını 2fbe35b seç
b1cdd72'yi çekmenin ilk taslağını seç --rebase
b0377f9'u seçin Başlıkta yazım hatasını düzeltin
7445019'u seç Değişikliğin yazım hatalarını düzelt

# 667f8c9..7445019'u 667f8c9'a yeniden döşeyin
#
# Komutlar:
# p, pick = kaydetmeyi kullan
# r, reword = kaydetme kullan, ancak kaydetme mesajını düzenle
# e, edit = commit kullanın, ancak düzeltmek için durun
# s, squash = kaydetme kullan, ancak önceki kaydetme ile birleştir
# f, fixup = "squash" gibi, ancak bu kaydetmenin günlük mesajını atın
# x, exec = kabuk kullanarak komut çalıştır (satırın geri kalanı)
#
# Bu satırlar yeniden sıralanabilir; yukarıdan aşağıya doğru yürütülürler.
#
# Burada bir satırı kaldırırsanız KOMİTE KAYBOLACAKTIR.
#
# Ancak, her şeyi kaldırırsanız, yeniden destek iptal edilecektir.
#
# Boş kaydetmelerin yorumlandığını unutmayın

Notta açıklandığı gibi, taahhütler sıralarını değiştirmek için yeniden düzenlenebilir veya toplamak diğer komutlardan birine değiştirilebilir.

7bb9109 değişiklik bölümünün ilk taslağını seç
fixup b0377f9 Başlıkta yazım hatasını düzeltin
fixup 7445019 Değişikliğin yanlış yazımını düzeltin
sıfırlamanın ilk taslağını 2fbe35b seç
b1cdd72'yi çekmenin ilk taslağını seç --rebase

İki yazım hatası düzeltmesini, tanıtıldıkları işlemin hemen sonrasına taşıdım ve seçimi şu şekilde değiştirdim: tamir etmek onları orijinal commit ile birleştirmek için. Düzenleyiciyi kaydedip kapattıktan sonra Git değişiklikleri uygulayacaktır:

[ayrıldı BAŞLIK 00165a8] değişiklik bölümünün ilk taslağı
1 dosya değiştirildi, 47 ekleme (+)
mod 100644 article.md oluştur
Refs / head / master başarıyla yeniden düzenlendi ve güncellendi.

Günlük, yazım hatası düzeltme işlemlerinin artık gittiğini gösteriyor. Düzeltmeler orijinal taahhütlere uygulandı ve yazımın kötü olduğuna dair bir kanıt yok (bu dalda).

$ git log --oneline
4787614 Çekmenin ilk taslağı --rebase
ee719e9 ilk sıfırlama taslağı
00165a8 değişiklik bölümünün ilk taslağı
667f8c9 README Ekle

Bu yeniden ödeme başka herhangi bir etkileşim olmadan çalıştı, ancak bazen bir yeniden ödeme, birleştirme çakışmaları için manuel düzeltmeler gerektirebilir. Böyle bir şey olursa korkmayın. Sadece mesajları okuyun. Git genellikle sizi zor durumda bırakmanıza yardımcı olur.

05. Tüm tarihi yeniden yazın

Şimdiye kadar incelediğimiz tüm Git komutları, son taahhütleri değiştirmek için kullanışlıdır, ancak bazen hassas veya çok büyük dosyaları kaldırmak veya bir projenin yönetimini kolaylaştırmak için daha aşırı önlemler gereklidir.

git filtre dalı bir dizi işleme için revizyon geçmişini yeniden yazabilen özel filtrelerle dolu bir eli destekler.

İlk meşru kullanımım git filtre dalı sunucunun ve istemcinin aynı depoda olduğu büyük bir projedeydi. Takıma daha fazla insan eklendikçe ve yenilikçiler ile boyun sakalları arasındaki gerilim yükseldikçe, iki deponun daha uygun olacağı ortaya çıktı.

Basit bir çözüm, depoyu iki kez klonlamak, gereksiz dosyaları silmek ve kalan dosyaları taşımak olabilirdi. Ancak bu, gereksiz yer kaplayan yinelenen geçmişlere sahip iki depo bırakır. Bunun yerine, depoyu iki kez klonladık ve --subdirectory-filter yalnızca uygulamanın ilgili bölümlerindeki değişiklikleri içeren iki yeni depo oluşturmak için.

$ git rebase -i 7bb9109 ^

Pek çok kişi, kişisel projeler ve iş projeleri için farklı e-posta adresleri kullanır ve bu da, yanlış e-posta adresini kullanarak bir arşive kolayca kaydolmaya neden olabilir. -env-filtresi yazar bilgileri veya taahhüt tarihi gibi bir kayıtla ilgili temel meta verileri değiştirebilir.

$ git filter-branch --env-filter ’
eğer [$ GIT_AUTHOR_EMAIL = kiş[email protected]];
sonra [email protected];
fi; dışa aktar GIT_AUTHOR_EMAIL ’
Yeniden yaz f853027b7979756bab7146d3bb34d8829b81a884 (8/8)
Ref 'refs / heads / master' yeniden yazıldı

Farz edin ki, bir projenin başlarında birisinin son derece büyük varlıklar işlediğini ve şimdi depoyu klonlayan herkesin bu varlıkların indirilmesini beklemesi gerektiğini varsayalım. Veya belki de içinde depolanan bazı hassas verilerin bulunduğu bir projeyi açık kaynak olarak kullanıyorsunuzdur.

$ git filter-branch --index-filter ’git rm -r --cached --ignore-unmatch docs / designs’
--prune-empty --tag-name-filter cat - --all

Aşağıdaki değişikliklerin tümü, bir arşivin tam geçmişini yeniden yazacak ve onu temelde yeni bir havuz haline getirecektir. Başlangıçta kullanılan aynı uzaktan kumandaya basmak reddedilecektir.

$ git itme
! [reddedildi] ana -> ana (hızlı ileri sarma)

Git'i tüm değişiklikleri mevcut bir uzaktan kumandaya zorlamak mümkündür, ancak bunun projede çalışan diğer herkes için olumsuz etkileri olabileceğini unutmayın.

$ git push --force --all --tags

06. Güç ve esneklik

Git’in güçlü özellikleri, aşırı esnekliği ve çoğu zaman sezgisel olmayan komut satırı bunaltıcı görünebilir, ancak öğrenmek ve denemek için zaman ayırmak, değerli bir yatırımdır. Şüpheye düştüğünde geç --Yardım Daha fazlasını öğrenmek için herhangi bir Git komutuna. Revizyon geçmişinin nasıl ve ne zaman yeniden yazılacağını anlamak, size projeleriniz üzerinde tam kontrol sağlar ve onları yönetmeyi kolaylaştırır.

Resim, Creative Commons Licensing altında JohnGoode'un izniyle kullanılmıştır

Brandon Keepers, GitHub'da çoğunlukla Speaker Deck üzerinde çalışan bir yapımcı ve kırıcıdır. Yüzü bilgisayar ekranıyla loş bir şekilde aydınlatılmadığında, onu elinde bir kitapla, raketbol ya da basketbol oynarken, köpeğiyle koşarken ya da karısıyla güzel yemek ve içeceklerin tadını çıkarırken bulabilirsiniz.

Bunu beğendin mi? Bunları oku!

• Bir uygulama nasıl oluşturulur: bu harika eğitimleri deneyin
• Ücretsiz grafik tasarım yazılımı şu anda size sunuluyor!
• Mükemmel Wordpress öğretici seçimi