Uzak dosyaların üzerine yazmak için “git push” u zorlayın


767

Yerel dosyalarımı zorlamak ve birleştirme çakışmalarıyla uğraşmak zorunda kalmadan onları uzak bir repoya taşımak istiyorum. Yerel sürümümün uzak sürümden öncelikli olmasını istiyorum.

Git ile bunu nasıl yapabilirim?


106
git push origin --forcesizin için çalışmaz?

3

Yalnızca .git dosyalarını veya ilişkili çalışma kopyasını geçersiz kılmak isteyip istemediğiniz belirsizdir. Git deposu ise, cevap git cevaptır. Uzaktan çalışan kopyayı güncellemek istiyorsanız, bir alma sonrası kancası kullanmanız gerekir
Pierre-Olivier Vares

@Benim nedense benim için çalışıyor ... OP ile ne olduğunu merak ediyorum

Muhtemel bir neden, zorla itme çalışmıyor, uzak repoda açıkça devre dışı bırakılmış olabilir (idiyotik ve / veya kötü niyetli katkıda bulunanlar nedeniyle hiçbir şeyin kaybolmamasını sağlamak için): config receive.denyNonFastforwardsbulmak için kullanın .
Frank Nocke

Yanıtlar:


1086

Kullanarak yerel repounuzu uzak repoya zorlayabilmelisiniz.

git push -f <remote> <branch>

(örneğin git push -f origin master). Bırakmak <remote>ve <branch>ayarlanmış tüm yerel şubeleri zorlar --set-upstream.

Sadece uyarın, eğer başkaları bu depoyu paylaşıyorsa, revizyon geçmişi yenisiyle çakışacaktır. Ve değişiklik noktasından sonra herhangi bir yerel taahhütleri varsa geçersiz olurlar.

Güncelleme : Bir yan not ekleyeceğimi düşündüm. Başkalarının inceleyeceği değişiklikler oluşturuyorsanız, bu değişikliklerle bir şube oluşturmak ve bunları ana geliştirme dalıyla güncel tutmak için periyodik olarak yeniden oluşturmak nadir değildir. Diğer geliştiricilerin bunun düzenli olarak olacağını bilmelerini sağlayın, böylece ne bekleyeceklerini bilecekler.

Güncelleme 2 : Görüntüleyenlerin sayısının artması nedeniyle, upstreambir zorlama uygulandığında ne yapacağınız konusunda bazı ek bilgiler eklemek istiyorum .

Diyelim ki repo klonladım ve böyle birkaç taahhüt ekledim:

            D ---- E konu
           /
A ---- B ---- C gelişimi

Ama daha sonra developmentşubeye rebasekoştuğumda böyle bir hata almama neden olacak bir a çarptı git pull:

Nesneleri ambalajından çıkarma:% 100 (3/3), bitti.
<Yeniden konumlandırma>
 * şube geliştirme -> FETCH_HEAD
Otomatik olarak birleştirme <files>
CONFLICT (içerik): <locations> içindeki çakışmayı birleştir
Otomatik birleştirme başarısız; anlaşmazlıkları düzeltin ve ardından sonucu kesin.

Burada çatışmaları çözebilirim commit, ama bu beni gerçekten çirkin bir taahhüt tarihiyle bırakacaktı:

       C ---- D ---- E ---- F konu
      / /
A ---- B -------------- C 'gelişimi

Kullanmak cazip gelebilir, git pull --forceancak dikkatli olun çünkü sizi mahsur taahhütlerle bırakacaktır:

            D ---- E konu

A ---- B ---- C 'gelişimi

Yani muhtemelen en iyi seçenek bir yapmaktır git pull --rebase. Bu, daha önce olduğu gibi herhangi bir çatışmayı çözmemi gerektirecek, ancak taahhütte bulunmak yerine her adım için kullanacağım git rebase --continue. Sonunda taahhüt tarihi çok daha iyi görünecek:

            D '--- E' konusu
           /
A ---- B ---- C 'gelişimi

Güncelleme 3: Bu --force-with-leaseseçeneği cevabı Cupcake tarafından belirtildiği gibi "daha güvenli" bir kuvvet itme olarak da kullanabilirsiniz :

"Kira" ile zorla itme, uzaktan kumandada beklemediğiniz yeni taahhütler varsa (teknik olarak, henüz uzaktan izleme şubenize almadıysanız) zorla itmenin başarısız olmasına izin verir; henüz bilmediğiniz bir başkasının taahhütlerinin üzerine yanlışlıkla yazmak istemezsiniz ve sadece kendinizin üzerine yazmak istersiniz:

git push <remote> <branch> --force-with-lease

--force-with-leaseAşağıdakilerden herhangi birini okuyarak nasıl kullanılacağı hakkında daha fazla bilgi edinebilirsiniz :


5
Seçilen cevap bu olduğundan, burada yorum yapacağım. Kendi başınıza çalışırken güç kullanmak sorun değil. Örneğin, bulut sunucum kendi git ile başlar. Yerel olarak çalışıp bir proje oluşturursam ve bunu bulut sunucuma (OpenShift) koymak istersem, iki ayrı git projem var. Yerel ve OpenShift'im. Yerelimi istediğim gibi alıyorum, ancak şimdi OpenShift'imde önizlemek istiyorum. Daha sonra -fbayrağı kullanarak ilk kez OpenShift'e basarsınız . Aslında yerel git OpenShift üzerine koyarak.
Wade

128

Zorla itmek istiyorsun

Temel olarak yapmak istediğiniz şey, uzak dalın üzerine yazmak için yerel şubenizi zorlamaktır.

Aşağıdaki komutların her biri için daha ayrıntılı bir açıklama istiyorsanız, aşağıdaki ayrıntılar bölümüne bakın. Git ile zorlamak için 4 farklı seçeneğiniz var:

git push <remote> <branch> -f
git push origin master -f # Example

git push <remote> -f
git push origin -f # Example

git push -f

git push <remote> <branch> --force-with-lease

Her komutun daha ayrıntılı bir açıklamasını istiyorsanız, aşağıdaki uzun cevaplarım bölümüne bakın.

Uyarı: zorla itme, uzak dalın üzerine bastığınız dalın durumunu yazar. Kullanmadan önce gerçekten yapmak istediğiniz bu olduğundan emin olun, aksi takdirde gerçekten tutmak istediğiniz taahhütlerin üzerine yazabilirsiniz.

Zorla itme ayrıntıları

Uzaktan kumandayı ve dalı belirtme

Belirli dalları ve bir kumandayı tamamen belirtebilirsiniz. -fBayrak kısa versiyonu--force

git push <remote> <branch> --force
git push <remote> <branch> -f

Şubenin çıkarılması

Dalın gönderileceği dal atlandığında Git, yapılandırma ayarlarınıza bağlı olarak bunu çözer. Git'in 2.0'dan sonraki sürümlerinde, yeni bir repo o anda kullanıma alınmış dalı itmek için varsayılan ayarlara sahip olacaktır:

git push <remote> --force

2.0'dan önce ise, yeni depoların birden çok yerel dalı itmek için varsayılan ayarları olacaktır. Söz konusu ayarlar remote.<remote>.pushve push.defaultayarlarıdır (aşağıya bakın).

Uzaktan kumandayı ve dalı atlama

Hem uzaktan kumanda hem de dal atlandığında, davranışı Git yapılandırma ayarlarınız git push --forcetarafından belirlenir push.default:

git push --force
  • Varsayılan ayar olan Git 2.0'dan itibaren, simpletemel olarak geçerli dalınızı yukarı akış uzak karşı bölümüne itecektir. Uzaktan kumanda, dalın branch.<remote>.remoteayarına göre belirlenir ve varsayılan olarak başlangıç ​​deposuna ayarlanır.

  • Git sürüm 2.0'dan önce, varsayılan ayar, matchingtemel olarak tüm yerel dallarınızı uzaktan kumandadaki aynı ada sahip dallara (varsayılan olarak başlangıç ​​noktasıdır) iter.

Git veya config (1) Kılavuz Sayfasının çevrimiçi bir sürümünüpush.default okuyarak git help configveya daha fazla ayar okuyabilirsiniz .

İle daha güvenli itmeye zorlayın --force-with-lease

"Kira" ile zorla itme, uzaktan kumandada beklemediğiniz yeni taahhütler varsa (teknik olarak, henüz uzaktan izleme şubenize almadıysanız) zorla itmenin başarısız olmasına izin verir; henüz bilmediğiniz bir başkasının taahhütlerinin üzerine yanlışlıkla yazmak istemezsiniz ve sadece kendinizin üzerine yazmak istersiniz:

git push <remote> <branch> --force-with-lease

--force-with-leaseAşağıdakilerden herhangi birini okuyarak nasıl kullanılacağı hakkında daha fazla bilgi edinebilirsiniz :


Haklısınız, ancak bu gerçekten sadece istisnai durumlarda kullanılmalıdır .
Scott Berrevoets

1
@ScottBerrevoets " Tercih ediyorum, sahip olduğum şeyi zorlamak ve entegre olmak yerine uzaktan üzerine yazmasına izin vermek. " OP'ye tam olarak istediğini verdim.

Biliyorum, ama OP bunu yapmanın sonuçlarının farkında olmayabilir. Soruyu teknik olarak cevapladınız, ancak bence bunu yapmamanın bir uyarısı yerinde değil.
Scott Berrevoets

1
@ScottBerrevoets Yeni bir --force-with-leaseseçenekten bahsediyorum çünkü bir moderatör cevabımı kanonikle birleştirmeye çalışıyorum;)


32

Başka bir seçenek (diğer katılımcılar için sorun yaratabilecek herhangi bir zorla itmeyi önlemek için):

  • yeni taahhütlerinizi özel bir şubeye koyun
  • senin reset masterONorigin/master
  • adanmış şubenizi birleştirin master, her zaman adanmış şubeden taahhütte bulunun ( masterbunun üzerine adanmış dalınızı yansıtacak yeni revizyonlar oluşturmak anlamına gelir ).
    A benzetme stratejileri için bkz. " Bir dalı diğeri gibi yapmak için git komutu " git merge --strategy=theirs.

Bu şekilde, herhangi bir şeyi zorlamak zorunda kalmadan ustayı uzaktan kumandaya itebilirsiniz.


Sonuç "itme kuvveti" ne göre farklılık gösterir?
alexkovelsky

6
@alexkovelsky Herhangi bir zorlamalı itme geçmişi yeniden yazarak, repodaki diğer kullanıcıları yeni itilen taahhütlerle eşleştirmek için kendi yerel repolarını sıfırlamaya zorlar. Bu yaklaşım sadece yeni taahhütler oluşturur ve zorla itme gerektirmez.
VonC

1
Cevabınıza bir başlık eklemenizi öneririm: "
Zorla

@alexkovelsky İyi bir nokta. Cevabı buna göre düzenledim.
VonC

4

git push -f, takımdaki herhangi bir kişi tarafından yapılan uzaktan değişiklikleri sıfırladığı için biraz yıkıcıdır. Daha güvenli bir seçenek {git push - force-lease}.

{- lease-with-lease} 'in yaptığı, beklediğimiz durum olmadığı sürece bir şubeyi güncellemeyi reddetmek; yani hiç kimse şubeyi yukarı yönde güncellemedi. Pratikte bu, yukarı akış ref'sinin beklediğimiz olduğunu kontrol ederek çalışır, çünkü ref'ler karmadır ve ebeveyn zincirini örtük olarak değerlerine kodlar. Tam olarak neyi kontrol edeceğinizi {--force-with-lease} ile söyleyebilirsiniz, ancak varsayılan olarak geçerli uzaktan referansı kontrol eder. Bunun pratikte anlamı, Alice dalını güncellediğinde ve uzak depoya doğru ittiğinde, dalın ref işaretleme kafasının güncelleneceğidir. Şimdi, Bob uzaktan kumandadan bir çekim yapmazsa, uzaktan kumandaya yerel referansı güncel olmayacaktır. {- for-lease} kullanarak itmeye gittiğinde git, yerel ref'yi yeni uzaktan kumandaya karşı kontrol eder ve itmeyi zorlamayı reddeder. {- lease-with-lease} sadece geçici olarak başka hiç kimse aradaki uzaktan kumandaya değişiklik yapmadıysa zorla itmenizi sağlar. Emniyet kemeri açıkken {--force}.


3

Benim için çalışıyor:

git push --set-upstream origin master -f

0

Tortoisegit kullanarak basit adımlar

GIT yerel dosyaları vermek ve git deposuna itmek.

Adımlar:

1) stash stash adını değiştirir

2) çekin

3) saklamak pop

4) işlemek 1 veya daha fazla dosya ve yer değişimi açıklama seti yazar ve Tarihi taahhüt vermek

5) İtme

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.