Git Geçmişini Güvenle Yeniden Yazmak: Bir Kılavuz

Bir geliştirici olarak her zaman Git ile çalışırsınız. Hiç şunu söylediğiniz bir noktaya geldiniz mi: "Ah, ben az önce ne yaptım?" Bu yazı size tarihi güvenle yeniden yazmanız için gereken araçları verecektir. Başlamadan Önce Notlar Ayrıca bu yazının içeriğini kapsayan canlı bir konuşma da yaptım. Bir videoyu tercih ediyorsanız (veya onu okurken izlemek istiyorsanız) — onu bulabilirsiniz . Burada Git hakkında bir kitap üzerinde çalışıyorum! İlk versiyonları okuyup geri bildirimde bulunmak ister misiniz? Bana bir e-posta gönder: gitting.things@gmail.com Git'teki Değişiklikleri Kaydetme Git'te bir şeylerin nasıl anlamadan önce Git'te değişiklikleri nasıl anlamalısınız. Zaten tüm terimleri biliyorsanız bu kısmı atlamaktan çekinmeyin. geri alınacağını kaydettiğimizi Git'i bir dosya sisteminin anlık görüntülerini zaman içinde kaydeden bir sistem olarak düşünmek çok faydalıdır. Git deposu göz önüne alındığında üç "durum" veya "ağaç" vardır: Genellikle kaynak kodumuz üzerinde çalışırken çalışırız. (veya ), dosya sistemimizde kendisiyle ilişkili bir sahip olan herhangi bir dizindir. çalışan bir dizinden Çalışan bir dizin (ectory) çalışan ağaç depoya Projemizin klasör ve dosyalarının yanı sıra adında bir dizin içerir. klasörünün içeriğini daha ayrıntılı olarak şurada anlattım: . .git .git önceki bir gönderi Bazı değişiklikler yaptıktan sonra bunları kaydetmek isteyebilirsiniz. Bir (kısacası: ), her biri projenin geçmiş bir tarihte, ister sizin makinenizde, ister bir başkasının makinesinde nasıl göründüğünün bir arşivi olan bir koleksiyonudur. deponuza depo repo çalışma ağacının commit Bir aynı zamanda kod dosyalarımızın dışında , dallar vb. gibi şeyleri de içerir. depo HEAD Arada veya var; bu iki terim birbirinin yerine kullanılabilir. Bir şubeyi aldığımızda Git, , en son teslim alınan tüm dosya içerikleriyle ve orijinal olarak teslim alındığında nasıl göründükleri ile doldurur. indeks hazırlama alanımız checkout dizini çalışma dizinimize kullandığımızda, durumuna göre oluşturulur. git commit taahhüt indeksin Yani veya bir sonraki taahhüt için oyun alanınızdır. ile çalışabilir ve istediğiniz her şeyi yapabilirsiniz, ona dosya ekleyebilir, içindekileri kaldırabilirsiniz ve ancak hazır olduğunuzda devam edip depoya bağlanabilirsiniz. indeks hazırlama alanı Index Uygulamalı hale gelme zamanı 🙌🏻 Yeni bir depo başlatmak için kullanın. adlı dosyaya bir miktar metin yazın: git init 1.txt Yukarıda açıklanan üç ağaç durumundan şimdi nerede? 1.txt Henüz dizine eklenmediğinden çalışma ağacında. , dizine eklemek için kullanın. Aşamalandırmak git add 1.txt Artık değişikliklerimizi depoya kaydetmek için kullanabiliriz. git commit Çalışma ağacının tamamını tanımlayan bir ağaca işaretçi içeren yeni bir taahhüt nesnesi oluşturdunuz. Bu durumda kök klasörde yalnızca olacaktır. Ağaca yönelik bir işaretçiye ek olarak taahhüt nesnesi, zaman damgaları ve yazar bilgileri gibi meta verileri içerir. 1.txt Git'teki nesneler (taahhütler ve ağaçlar gibi) hakkında daha fazla bilgi için, . önceki paylaşımıma göz at (Evet, “kontrol et”, kelime oyunu amaçlı 😇) Git ayrıca bize bu taahhüt nesnesinin SHA-1 değerini de söyler. Benim durumumda (biraz yer kazanmak için bunlar SHA-1 değerinin yalnızca ilk 7 karakteridir). c49f4ba Bu komutu makinenizde çalıştırırsanız, farklı bir yazar olduğunuz için farklı bir SHA-1 değeri elde edersiniz; ayrıca taahhüdü farklı bir zaman damgasında oluşturursunuz. Repoyu başlattığımızda Git yeni bir dal oluşturur (varsayılan olarak adında). Ve . Yani varsayılan olarak yalnızca dalınız var. Birden fazla şubeniz varsa ne olur? Git hangi dalın aktif dal olduğunu nasıl biliyor? main Git'teki bir dal yalnızca bir işleme yönelik adlandırılmış bir referanstır main Git'te adında, (genellikle) bir şubeye işaret eden ve daha sonra bir taahhüde işaret eden başka bir işaretçi vardır. Bu arada, Bazı öneklerle birlikte şubenin adını içerir. HEAD kaputun altında, HEAD sadece bir dosyadır. Depoya daha fazla değişiklik getirmenin zamanı geldi! Şimdi bir tane daha oluşturmak istiyorum. Şimdi yeni bir dosya oluşturalım ve onu daha önce olduğu gibi dizine ekleyelim: Şimdi kullanmanın zamanı geldi. Daha da önemlisi şey yapar: git commit git commit iki İlk olarak, bir taahhüt nesnesi oluşturur, böylece Git'in dahili nesne veritabanında karşılık gelen SHA-1 değerine sahip bir nesne bulunur. Bu yeni taahhüt nesnesi aynı zamanda üst taahhüte de işaret eder. Bu, komutunu yazdığınızda işaret ettiği taahhüttür. git commit HEAD İkincisi, aktif dalın işaretçisini hareket ettirir; bizim durumumuzda bu, olacaktır ve yeni oluşturulan taahhüt nesnesini işaret edecektir. git commit main Değişiklikleri Geri Alma Tarihi yeniden yazmak için, taahhüt ekleme sürecini geri alarak başlayalım. Bunun için süper güçlü bir araç olan komutunu tanıyacağız. git reset git reset --soft Yani daha önce attığınız son adım ; bu aslında iki anlama geliyordu: Git bir commit nesnesi yarattı ve aktif dal olarak taşıdı. Bu adımı geri almak için komutunu kullanın. git commit main git reset --soft HEAD~1 sözdizimi öğesinin ilk ebeveynini belirtir. Taahhüt grafiğinde birden fazla taahhütüm varsa, "Taahhüt 2"yi işaret ederek "Taahhüt 3" deyin, bu da "Taahhüt 1"i işaret eder. HEAD~1 HEAD Ve "Taahhüt 3"ü işaret ettiğini söyleyin. "Taahhüt 2"ye atıfta bulunmak için kullanabilirsiniz ve , "Taahhüt 1"e atıfta bulunur. HEAD HEAD~1 HEAD~2 Yani komuta geri dönelim: git reset --soft HEAD~1 Bu komut Git'ten işaret ettiği şeyi değiştirmesini ister. (Not: Aşağıdaki diyagramlarda “ işaret ettiği şey” için kullanıyorum). Örneğimizde öğesini işaret ediyor. Yani Git yalnızca işaretçisini olarak değiştirecek. Yani “Commit 1”i işaret edecektir. HEAD HEAD *HEAD HEAD main main HEAD~1 main Ancak bu komut indeksin veya çalışma ağacının durumunu . Yani kullanırsanız, çalıştırmadan önceki gibi aşamalı olduğunu göreceksiniz. etkilemedi git status git commit 2.txt başlayacak, ve ardından "Commit 1"e gidecektir. Bunun, "Commit 2"ye artık geçmişimizden erişilemeyeceği anlamına geldiğine dikkat edin. git log? HEAD main Bu, "Taahhüt 2"nin taahhüt nesnesinin silindiği anlamına mı geliyor? 🤔 Hayır silinmiyor. Hala Git'in dahili nesne veritabanında bulunuyor. Şimdi kullanarak mevcut geçmişi aktarırsanız Git, uzak sunucuya "Taahhüt 2" göndermez, ancak taahhüt nesnesi deponun yerel kopyasında hala mevcuttur. git push Şimdi tekrar taahhütte bulunun ve bu yeni nesneyi orijinal "Taahhüt 2"den ayırmak için "Taahhüt 2.1" taahhüt mesajını kullanın: “Taahhüt 2” ve “Taahhüt 2.1” neden farklıdır? Aynı taahhüt mesajını kullansak bile ve şunu işaret etseler bile ( ve oluşan kök klasörün), farklı zamanlarda oluşturuldukları için hala farklı zaman damgalarına sahiptirler. aynı ağaç nesnesi 1.txt 2.txt Yukarıdaki çizimde Git'in dahili nesne veritabanında hala var olduğunu hatırlatmak için “Commit 2”yi tuttum. Hem "Commit 2" hem de "Commit 2.1" artık "Commit 1"i işaret ediyor, ancak yalnızca "Commit 2.1"e adresinden ulaşılabilir. HEAD Git Sıfırlama --Karışık Daha da geriye gitmenin ve daha fazlasını geri almanın zamanı geldi. Bu sefer kullanın (not: , için varsayılan anahtardır). git reset --mixed HEAD~1 --mixed git reset Bu komut ile aynı şekilde başlar. Bu, dal olan şu anda işaret ettiği şeyin işaretçisini alır ve onu örneğimizde - "Commit 1" olarak ayarlar. git reset --soft HEAD~1 main HEAD HEAD~1 Daha sonra Git daha da ileri giderek dizinde yaptığımız değişiklikleri etkili bir şekilde geri alır. Yani, dizini mevcut ile eşleşecek şekilde değiştirmek, ilk adımda ayarladıktan sonra yeni eşleşecek şekilde değiştirmek. HEAD HEAD çalıştırırsak, bu ("Taahhüt 1") olarak ayarlanacağı ve ardından Git'in dizini "Taahhüt 1" durumuyla eşleştireceği anlamına gelir - bu durumda, bu, artık dizinin bir parçası olmayacağı anlamına gelir. git reset --mixed HEAD~1 HEAD HEAD~1 2.txt Orijinal “Commit 2” durumuyla yeni bir taahhüt oluşturmanın zamanı geldi. Bu sefer dosyasını oluşturmadan önce yeniden hazırlamamız gerekiyor: 2.txt Git Sıfırlama --Zor Devam edin, daha fazlasını geri alın! Devam edin ve çalıştırın git reset --hard HEAD~1 Git yine aşamasıyla başlar ve ( ) işaret ettiği şeyi ("Commit 1") olarak ayarlar. --soft HEAD main HEAD~1 Şimdiye kadar, çok iyi. Daha sonra aşamasına geçerek dizini ile eşleştirin. Yani Git, aşamalandırmasını geri alır. --mixed HEAD 2.txt Git'in daha da ileri giderek çalışma dizinini dizin aşamasıyla eşleştirdiği adımının zamanı geldi. Bu durumda, da çalışma dizininden kaldırılması anlamına gelir. --hard 2.txt (**Not: Bu özel durumda, dosya dolayısıyla dosya sisteminden silinmez; anlamak için gerçekten önemli değildir). izlenmez, git reset Git'te bir değişiklik yapmak için üç adımınız var. Çalışma dizinini, dizini veya hazırlama alanını değiştirirsiniz ve ardından bu değişikliklerle yeni bir anlık görüntü kaydedersiniz. Bu değişiklikleri için: geri almak kullanırsak commit adımını geri alırız. git reset --soft kullanırsak, hazırlama adımını da geri alırız. git reset --mixed kullanırsak çalışma dizinindeki değişiklikleri geri alırız. git reset --hard Gerçek Hayat Senaryoları! Senaryo #1 Yani gerçek hayattaki bir senaryoda, hepimizin Git'i sevdiği gibi, bir dosyaya ( ) "Git'i seviyorum" yazın. Devam edin, sahneleyin ve bunu da gerçekleştirin: love.txt Ah, ah! Aslında bunu yapmanı istemedim. Aslında senden yapmanı istediğim şey, bunu taahhüt etmeden önce bu dosyaya birkaç aşk sözü daha yazmandı. Ne yapabilirsin? Bunun üstesinden gelmenin bir yolu, kullanmak, hem işleme hem de hazırlama eylemlerini etkili bir şekilde geri almak olacaktır: git reset --mixed HEAD~1 Yani nokta yine "Taahhüt 1"dir ve artık dizinin bir parçası değildir. Ancak dosya çalışma dizininde kalır. Artık devam edip daha fazla içerik ekleyebilirsiniz: main love.txt Devam edin, sahneleyin ve dosyanızı kaydedin: Aferin 👏🏻 "Taahhüt 2.4"ün "Taahhüt 1"i işaret eden bu net ve güzel geçmişine sahipsiniz. Artık araç kutumuzda yeni bir aracımız var, 💪🏻 git reset Bu araç süper, süper kullanışlıdır ve onunla neredeyse her şeyi başarabilirsiniz. Her zaman kullanımı en uygun araç olmayabilir, ancak dikkatli kullanırsanız neredeyse her türlü tarihin yeniden yazılması senaryosunu çözebilir. Yeni başlayanlar için, Git'te geri almak istediğiniz hemen hemen her zaman için yalnızca kullanmanızı öneririm. Kendinizi rahat hissettiğinizde diğer araçlara geçme zamanı gelmiştir. git reset Senaryo #2 Başka bir durumu ele alalım. adında yeni bir dosya oluşturun; sahneleyin ve taahhüt edin: new.txt Hata. Aslında bu bir hata. Siz üzerindeydiniz ve ben sizden bu taahhüdü bir özellik dalında oluşturmanızı istedim. Kötüyüm 😇 main Bu yazıdan almanızı istediğim en önemli iki araç var. . Bunlardan ilki ve çok daha önemlisi, mevcut durumu ve içinde olmak istediğiniz durumu . İkincisi git reset beyaz tahtaya yansıtmaktır Bu senaryo için mevcut durum ve istenen durum şöyle görünür: Üç değişiklik fark edeceksiniz: nokta mevcut durumda "Commit 3"ü (mavi olanı), ancak istenen durumda "Commit 2.4"ü işaret eder. main dalı mevcut durumda mevcut değil ancak mevcut ve istenilen durumda “Commit 3”e işaret ediyor. feature mevcut durumdaki ve istenen durumdaki işaret eder. HEAD main feature Bunu çizebilirseniz ve kullanmayı biliyorsanız bu durumdan kesinlikle kurtulabilirsiniz. git reset Tekrar ediyorum, nefes almak ve bunu dışarı çıkarmaktır. en önemli şey Yukarıdaki çizime bakıldığında mevcut durumdan istenilen duruma nasıl geçilir? Elbette birkaç farklı yolu var ama her senaryo için yalnızca bir seçenek sunacağım. Diğer seçeneklerle de oynamaktan çekinmeyin. kullanarak başlayabilirsiniz. Bu, önceki taahhüt olan "Taahhüt 2.4"e işaret etmesini sağlayacaktır: git reset --soft HEAD~1 main Mevcut-istenen diyagramına tekrar baktığınızda yeni bir dallanmaya ihtiyacınız olduğunu görebilirsiniz, değil mi? Bunun için veya (aynı şeyi yapan) kullanabilirsiniz: git switch -c feature git checkout -b feature Bu komut aynı zamanda yeni dalı işaret edecek şekilde günceller. HEAD kullandığınız için dizini değiştirmediniz, dolayısıyla şu anda tam olarak taahhüt etmek istediğiniz duruma sahip - ne kadar kullanışlı! Sadece dalını taahhüt edebilirsiniz: git reset --soft feature Ve istediğiniz duruma ulaştınız 🎉 Senaryo #3 Bilginizi ek vakalara uygulamaya hazır mısınız? dosyasına bazı değişiklikler ekleyin ve ayrıca adında yeni bir dosya oluşturun. Onları sahneleyin ve taahhüt edin: love.txt cool.txt Ah, aslında her değişiklikte bir tane olmak üzere iki ayrı taahhüt oluşturmanı istedim 🤦🏻 Bunu kendiniz denemek ister misiniz? İşleme ve hazırlama adımlarını geri alabilirsiniz: Bu komutun ardından dizin artık bu iki değişikliği içermez ancak her ikisi de hâlâ dosya sisteminizdedir. Yani şimdi, yalnızca dosyasını hazırlarsanız, bunu ayrı olarak işleyebilir ve ardından aynısını için yapabilirsiniz: love.txt cool.txt Güzel 😎 Senaryo #4 Biraz metin içeren yeni bir dosya ( ) oluşturun ve dosyasına biraz metin ekleyin. Her iki değişikliği de gerçekleştirin ve taahhüt edin: new_file.txt love.txt Eyvah 🙈🙈 Bu sefer başka bir şubede olmasını istedim, bir şube değil, daha ziyade mevcut bir şube. yeni Ne yapabilirsin? Sana bir ipucu vereceğim. Cevap gerçekten kısa ve gerçekten kolaydır. İlk önce ne yapacağız? Hayır . Çiziyoruz. Yapılacak ilk şey bu, çünkü bu her şeyi çok daha kolay hale getirecek. Yani şu anki durumu bu: reset Peki istenilen durum? Mevcut durumdan istenilen duruma nasıl ulaşırsınız, en kolayı ne olur? Bunun bir yolu, daha önce yaptığınız gibi kullanmak olabilir, ancak denemenizi istediğim başka bir yol daha var. git reset Öncelikle şubeyi işaret edecek şekilde hareket ettirin: HEAD existing Sezgisel olarak yapmak istediğiniz şey, mavi taahhütte yapılan değişiklikleri almak ve bu değişiklikleri ("kopyala-yapıştır") şubenin üzerine uygulamaktır. Ve Git'in tam da bunun için bir aracı var. existing Git'ten bu taahhüt ile ana taahhüdü arasında yapılan değişiklikleri almasını istemek ve bu değişiklikleri yalnızca aktif dalda uygulamak kullanabilirsiniz. Bu komut, belirtilen revizyonda yapılan değişiklikleri alır ve bunları aktif işleme uygular. git cherry-pick Ayrıca yeni bir taahhüt nesnesi oluşturur ve aktif dalı bu yeni nesneyi işaret edecek şekilde günceller. Yukarıdaki örnekte, oluşturulan taahhüdün SHA-1 tanımlayıcısını belirttim, ancak aynı zamanda, değişikliklerini uyguladığımız taahhüt işaret ettiği taahhüt olduğundan, de kullanabilirsiniz. main git cherry-pick main Ancak bu değişikliklerin dalda olmasını istemiyoruz. değişiklikleri yalnızca şubeye uyguladı. Bunları menüden nasıl kaldırabilirsiniz? main git cherry-pick existing main Bunun bir yolu geri ve ardından kullanmak olacaktır: main switch git reset --hard HEAD~1 Sen yaptın! 💪🏻 aslında belirtilen taahhüt ile üst öğesi arasındaki farkı hesapladığını ve ardından bunları aktif işleme uyguladığını unutmayın. Bu, bazen bir çelişki yaşayabileceğiniz için Git'in bu değişiklikleri uygulayamayacağı anlamına gelir, ancak bu başka bir yazının konusu. git cherry-pick Ayrıca Git'ten yalnızca bir şubenin referans verdiği taahhütleri değil, herhangi bir taahhütte yapılan değişiklikleri isteyebileceğinizi unutmayın. cherry-pick Yeni bir araç edindik, bu nedenle ve de elimizde bulunduruyoruz. git reset git cherry-pick Senaryo #5 Tamam, başka bir gün, başka bir repo, başka bir sorun. Bir taahhüt oluşturun: Ve uzak sunucuya : push Ah, ah 😓… Az önce bir şey fark ettim. Orada bir yazım hatası var. tezt yazdım. Hay aksi. Peki şimdi büyük sorun ne? ed'e , bu da başka birisinin bu değişiklikleri zaten olabileceği anlamına geliyor. This is more tezt This is more text push pull Eğer bu değişiklikleri kullanarak geçersiz kılarsam, şimdiye kadar yaptığımız gibi, farklı geçmişlerimiz olacak ve kıyamet kopabilir. Reponun kendi kopyasını, kadar istediğiniz kadar yeniden yazabilirsiniz. git reset push Değişikliği bir kez , eğer tarihi yeniden yazacaksanız, bu değişiklikleri başka kimsenin getirmediğinden olmanız gerekir. push emin Alternatif olarak adlı başka bir aracı kullanabilirsiniz. Bu komut, sağladığınız taahhüdü alır ve tıpkı gibi, üst taahhüdünden Farkı hesaplar, ancak bu sefer ters değişiklikleri hesaplar. git revert git cherry-pick Dolayısıyla, belirtilen işleme bir satır eklediyseniz, bunun tersi satırı siler ve bunun tersi de geçerlidir. yeni bir taahhüt nesnesi yarattı; bu, onun geçmişe bir ek olduğu anlamına gelir. kullanarak geçmişi yeniden yazmadınız. Geçmişteki hatanızı kabul ettiniz ve bu taahhüt, bir hata yaptığınızın ve şimdi onu düzelttiğinizin kabulüdür. git revert git revert Bazıları bunun daha olgun bir yol olduğunu söyleyebilir. Bazıları, önceki taahhüdü yeniden yazmak için kullandığınızda alacağınız kadar temiz bir geçmiş olmadığını söyleyebilir. Ancak bu, tarihin yeniden yazılmasını önlemenin bir yoludur. git reset Artık yazım hatasını düzeltebilir ve tekrar işlem yapabilirsiniz: Araç kutunuz artık yeni ve parlak bir araçla dolu, : revert Senaryo #6 Biraz iş yapın, biraz kod yazın ve onu dosyasına ekleyin. Bu değişikliği gerçekleştirin ve taahhüt edin: love.txt Makinemde de aynısını yaptım ve klavyemdeki ok tuşunu kullanarak önceki komutlara geri döndüm ve ardından tuşuna bastım ve… Vay be. Up Enter Hay aksi. Az önce kullandım mı? 😨 git reset --hard ne oldu? Git işaretçiyi konumuna taşıdı, bu nedenle tüm çalışmalarımla birlikte son işleme mevcut geçmişten ulaşılamıyor. Git ayrıca hazırlama alanındaki tüm değişiklikleri kaldırdı ve ardından çalışma dizinini hazırlama alanının durumuyla eşleştirdi. Aslında HEAD~1 değerli Yani, her şey işimin gittiği bu durumla eşleşiyor. Çılgınlık zamanı. Çıldırıyorum. Ama gerçekten korkmak için bir neden var mı? Pek değil… Biz rahat insanlarız. Biz ne yaptık? Peki, sezgisel olarak taahhüt bitti mi? Hayır neden olmasın? Hala Git'in dahili veritabanında mevcut. gerçekten Bunun nerede olduğunu bilseydim, bu taahhüdü tanımlayan SHA-1 değerini bilirdim ve onu geri yükleyebilirdik. Hatta geri alma işlemini geri alabilir ve bu işleme geri . reset Yani burada gerçekten ihtiyacım olan tek şey "silinmiş" taahhüdün SHA-1'idir. Peki soru şu; onu nasıl bulacağım? faydalı olur mu? git log Aslında değil. gider, bu da işaret eder, bu da aradığımız taahhüdün ana taahhüdünü gösterir. Daha sonra , değerli çalışmamla ilgili taahhüdü içermeyen ana zincir boyunca geriye doğru iz sürecektir. git log HEAD main git log Neyse ki Git'i yaratan çok akıllı insanlar bizim için bir yedekleme planı da oluşturdular ve buna deniyor. reflog Git ile çalışırken, kullanarak yapabileceğiniz öğesinin yanı sıra veya gibi diğer komutları da değiştirdiğinizde Git, dosyasına bir giriş ekler. git reset HEAD git switch git checkout reflog Taahhüdümüzü bulduk! ile başlayandır. 0fb929e Onunla aynı zamanda "takma adı" ile de bağlantı kurabiliriz. Git'in, öğesinin ilk ebeveynine ulaşmak için kullanması ve öğesinin ikinci ebeveynine başvurmak için kullanması gibi, Git, öğesinin ilk reflog ebeveynine atıfta bulunmak için öğesini kullanır, önceki adımda işaret ettiği yer. HEAD@{1} HEAD HEAD~1 HEAD HEAD~2 HEAD HEAD@{1} HEAD Ayrıca bize değerini göstermesini de isteyebiliriz: git rev-parse görüntülemenin başka bir yolu da kullanmaktır; bu, gerçekten dikkate almasını ister: reflog git log -g git log reflog Yukarıda gibi işaret ettiğini, yani "Commit 2"yi işaret ettiğini görüyoruz. Ancak bu girişin ebeveyni "Taahhüt 3" e işaret ediyor. reflog HEAD main reflog Yani "Taahhüt 3"e geri dönmek için (veya "Taahhüt 3"ün SHA-1 değerini) kullanabilirsiniz: git reset --hard HEAD@{1} Ve şimdi, yaparsak: git log Günü kurtardık! 🎉👏🏻 Bu komutu tekrar kullanırsam ne olur? Ve çalıştırdınız mı? Git, son önce işaret ettiği yere ayarlayacak, yani "Taahhüt 2" anlamına gelecektir. Bütün gün devam edebiliriz: git commit --reset HEAD@{1} HEAD HEAD reset Şimdi araç kutumuza baktığımızda Git'te işlerin ters gittiği birçok durumu çözmenize yardımcı olabilecek araçlarla dolu olduğunu görüyoruz: Bu araçlarla artık Git'in nasıl çalıştığını daha iyi anlayacaksınız. Geçmişi özel olarak yeniden yazmanıza izin verecek daha fazla araç var, ), ancak bu yazıda zaten çok şey öğrendiniz. Gelecek yazılarda de değineceğim. git rebase git rebase Bu araç kutusunda listelenen beş araçtan bile daha önemli olan en önemli araç, mevcut durum ile arzu edilen durumu beyaz tahtaya yansıtmaktır. Bana güvenin, bu her durumu daha az göz korkutucu hale getirecek ve çözümü daha net hale getirecek. Git Hakkında Daha Fazla Bilgi Edinin Ayrıca bu yazının içeriğini kapsayan canlı bir konuşma da yaptım. Bir videoyu tercih ediyorsanız (veya onu okurken izlemek istiyorsanız) — onu bulabilirsiniz . Burada Genel olarak, Git'in ve içindekilerin birçok yönünü kapsar; hoş geldiniz (kelime oyunu amaçlandı 😇) YouTube kanalım buna bir bak yazar hakkında CTO'su ve Kurucu Ortağıdır. geliştiricilerin ve ekiplerinin kod tabanları hakkındaki bilgileri güncel dahili belgelerle yönetmelerine yardımcı olan bir geliştirme aracıdır. Ömer, Check Point Security Academy'nin kurucusudur ve yetenekli profesyonelleri teknoloji alanında kariyer geliştirmeleri için eğiten bir eğitim kuruluşu olan ITC'de Siber Güvenlik Lideri olarak görev yapmıştır. Ömer Rosenbaum Yüzmek Ömer, Tel Aviv Üniversitesi'nden Dilbilim alanında yüksek lisans derecesine sahiptir ve . Kısa YouTube Kanalı İlk kez yayınlandı burada

Git Geçmişini Güvenle Yeniden Yazmak: Bir Kılavuz

Çok uzun; Okumak

@omerosenbaum

İLGİLİ ÖYKÜLER