Sanırım buradaki temel sorununuz git'in ne yaptığını ve neden yaptığını yanlış yorumlamanız ve / veya yanlış anlamanızdır.
Başka bir depoyu klonladığınızda git, "orada" olanın bir kopyasını oluşturur. Aynı zamanda gibi "kendi" şube etiketleri alır masterve "tam adı" bu etiketle bir kopyasını yapar senin git ağacından (normalde) 'dir remotes/origin/master(ama senin durumunda, içinde remotes/upstream/master). Çoğu zaman remotes/parçayı da atlarsınız , böylece orijinal kopyaya olarak bakabilirsiniz upstream/master.
Şimdi bazı dosyalarda bazı değişiklikler yapar ve taahhüt ederseniz, bu değişiklikleri yapan tek kişi sizsiniz. Bu arada, diğer insanlar, diğer klonları yapmak ve bu klonları değiştirmek için orijinal depoyu (sizin klonunuzu yaptığınız) kullanabilir. Elbette, değişiklikleri olan sadece onlar. Sonunda, bir kişinin orijinal sahibine geri gönderdiği değişiklikler olabilir ("push" veya yamalar veya her neyse).
git pullİçin komut çoğunlukla sadece steno edilir git fetchizledi git merge. Bu önemlidir çünkü bu iki işlemin gerçekte ne yaptığını anlamanız gerektiği anlamına gelir.
git fetchKomutu klonlanmış (veya başka türlü alınamayacak bir yer olarak kurdunuz) ve "yeni şeyler başkasının eklenen veya değiştirilen veya kaldırılan" bulduğunuz yerde dönmek söylüyor. Bu değişiklikler kopyalanır ve daha önce onlardan aldığınız kopyaya uygulanır . Onlar edilir değil sadece onların için, kendi çalışmalarına başvurmuştur.
git mergeKomut daha karmaşık ve ters nereye mesafesindedir. Biraz basitleştirilmiş olarak yaptığı şey, "kopyanızda değiştirdikleriniz" ile "başka birinden aldığınız ve böylece başkasının-çalışmasının-kopyasına-eklediğiniz değişiklikler" ile karşılaştırmaktır. Değişiklikleriniz ve değişiklikleri birbiriyle mergeçelişmiyor gibi görünüyorsa, işlem onları bir araya getirir ve size gelişiminizi ve gelişiminizi birbirine bağlayan bir "birleştirme taahhüdü" verir (yine de, sahip olmadığınız çok yaygın "kolay" bir durum vardır. değişir ve bir "ileri sar" alırsınız).
Şu anda karşılaştığınız durum, değişiklikler yaptığınız ve bunları yaptığınız bir durumdur - aslında dokuz kez, dolayısıyla "önde 9" ve hiçbir değişiklik yapmamışlardır . Yani, görev fetchbilinciyle hiçbir şey mergegetirmez ve sonra onların değişim eksikliklerini alır ve hiçbir şey yapmaz.
İstediğiniz şey, kodun "kendi" sürümüne bakmak, hatta belki "sıfırlamak".
Yalnızca bakmak istiyorsanız, o sürüme göz atabilirsiniz:
git checkout upstream/master
Bu, git'e geçerli dizini tam adı gerçekte olan şubeye taşımak istediğinizi söyler remotes/upstream/master. Kodlarını, en son koştuğunuz git fetchve en son kodlarını aldığınız andan itibaren göreceksiniz .
Tüm değişikliklerinizden vazgeçmek istiyorsanız , yapmanız gereken şey git'in etiketinizin hangi revizyonu masteradlandırması gerektiği konusundaki fikrini değiştirmektir . Şu anda en son yaptığınız işin adını veriyor. O şubeye geri dönersen:
git checkout master
Sonra git resetsanki komut, siz "etiketini taşımak" sağlayacaktır. Geriye kalan tek sorun (yaptığınız her şeyi terk etmeye gerçekten hazır olduğunuzu varsayarsak) etiketin nereye işaret etmesi gerektiğini bulmaktır.
git log7cfcb29kalıcı (asla değişmeyen) isimler olan sayısal isimleri bulmana izin verir ve bunları isimlendirmenin çok saçma sayıda başka yolu vardır, ama bu durumda sadece ismi istiyorsun upstream/master.
Etiketi taşımak için, kendi değişikliklerinizi silin (yaptığınız herhangi bir değişiklik aslında bir süredir kurtarılabilir, ancak bundan sonra çok daha zordur, bu yüzden çok emin olun):
git reset --hard upstream/master
--hardVerilen taahhüt kontrol o zaman, ne yaptığını silip şimdiki şube etiketini getirin ve git'e söyler.
Bir sürü işi gerçekten istemek git reset --hardve yok etmek çok yaygın değildir . Daha güvenli bir yöntem (sonuçta bir kısmının değerli olduğuna karar verirseniz, bu çalışmayı kurtarmayı çok daha kolay hale getirir) mevcut şubenizi yeniden adlandırmaktır:
git branch -m master bunchofhacks
ve sonra master"izler" adında yeni bir yerel şube oluşturun (bu terimi insanların kafasını karıştırdığını düşündüğüm için gerçekten sevmiyorum ama bu git terimi :-)) başlangıç (veya yukarı akış) master:
git branch -t master upstream/master
daha sonra şunlarla başlayabilirsiniz:
git checkout master
Son üç komutun yaptığı şey (yalnızca iki komut yapmak için kısayollar vardır), mevcut etikete yapıştırılan adı değiştirmek, ardından yeni bir etiket oluşturmak ve sonra ona geçiş yapmaktır:
bir şey yapmadan önce:
C0 - "remotes/upstream/master"
\
\- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 --- C8 --- C9 "master"
sonra git branch -m:
C0 - "remotes/upstream/master"
\
\- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 --- C8 --- C9 "bunchofhacks"
sonra git branch -t master upstream/master:
C0 - "remotes/upstream/master", "master"
\
\- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 --- C8 --- C9 "bunchofhacks"
İşte C0, .tap'ınızı ilk yaptığınızda aldığınız en son commit (eksiksiz bir kaynak ağacı) git clone. C1 - C9 arası taahhütlerinizdir.
Olursa git checkout bunchofhacksve sonra git reset --hard HEAD^^, bunun son resmi şu şekilde değiştireceğini unutmayın:
C0 - "remotes/upstream/master", "master"
\
\- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 - "bunchofhacks"
\
\- C8 --- C9
Bunun nedeni, HEAD^^revizyonu geçerli dalın başından itibaren ikinci olarak adlandırması (sıfırlamadan hemen önce olacaktır bunchofhacks) ve reset --hardardından etiketi hareket ettirmesidir. C8 ve C9 işlemleri artık çoğunlukla görünmezdir (reflog gibi şeyleri ve git fsckonları bulmak için kullanabilirsiniz, ancak artık önemsiz değil). Etiketleriniz, istediğiniz gibi hareket etmeniz için sizindir. fetchKomut ile başlayan olanlar ilgilenir remotes/. "Sizinkini" "onların" ile eşleştirmek gelenekseldir (bu yüzden onlar da remotes/origin/mauvesizinki isminizi kullanırsanız mauve), ancak "onlardan" aldığınız taahhütleri adlandırmak / görmek istediğinizde "onların" adını yazabilirsiniz. ("Tek işlemenin" tüm kaynak ağacı olduğunu unutmayın. Tek bir işlemden belirli bir dosya seçebilirsiniz, git showörneğin,