git-rebase - Bulutta Çevrimiçi

Program:

ADI

git-rebase - İleri bağlantı noktası yerel, güncellenmiş yukarı akış başlığına taahhüt eder

SİNOPSİS

git yeniden baz almak [-i | --interactive] [seçenekler] [--exec ] [--üzerine ]
[ [ ]]
git yeniden baz almak [-i | --interactive] [seçenekler] [--exec ] [--üzerine ]
--kök [ ]
git yeniden baz almak --devam | --atla | -- iptal | --düzenle-yapılacak

TANIM

Eğer belirtilir, git yeniden baz almak otomatik bir git checkout gerçekleştirecek
başka bir şey yapmadan önce. Aksi takdirde mevcut dalda kalır.

Eğer belirtilmemiş, yukarı akış dalda yapılandırılmıştır. .uzaktan ve
dal. .merge seçenekleri kullanılacaktır (bkz. git-config(1) ayrıntılar için) ve
--fork-point seçeneği varsayılır. Şu anda herhangi bir şubede değilseniz veya mevcut
dalın yapılandırılmış bir yukarı akışı yok, yeniden başlatma iptal edilecek.

Geçerli dalda taahhütler tarafından yapılan ancak içinde olmayan tüm değişiklikler kaydedilir
geçici bir alana. Bu, git log tarafından gösterilecek olan taahhütlerin aynısıdır.
..KAFA; veya --fork-point etkinse git log 'fork_point'..HEAD ile (bkz.
aşağıdaki --fork-point ile ilgili açıklama); veya --root seçeneği belirtilmişse git log HEAD ile.

Mevcut şube şuna sıfırlandı: , veya --onto seçeneği sağlanmışsa.
Bu, git reset --hard ile tamamen aynı etkiye sahiptir. (veya ). ORIG_HEAD (şimdiki değeri)
sıfırlamadan önce dalın ucunu gösterecek şekilde ayarlayın.

Daha önce geçici alana kaydedilen taahhütler daha sonra geçici alana yeniden uygulanır.
mevcut şube, sırayla, birer birer. HEAD'de aşağıdakileri tanıtan herhangi bir taahhüdün olduğunu unutmayın.
HEAD'deki bir taahhütle aynı metinsel değişiklikler .. atlanmıştır (yani, zaten bir yama
farklı bir taahhüt mesajı veya zaman damgası ile yukarı yönde kabul edilenler atlanır).

Bir birleştirme hatasının bu işlemin tamamen gerçekleşmesini engellemesi mümkündür.
otomatik. Böyle bir birleştirme hatasını çözmeniz ve git rebase --continue komutunu çalıştırmanız gerekecek.
Başka bir seçenek de, git rebase ile birleştirme hatasına neden olan taahhüdü atlamaktır.
--atlamak. Orijinali kontrol etmek için ve .git/rebase-apply çalışma dosyalarını kaldırın,
bunun yerine git rebase --abort komutunu kullanın.

Aşağıdaki geçmişin var olduğunu ve mevcut dalın "konu" olduğunu varsayalım:

A---B---C konusu
/
D---E---F---G ustası

Bu noktadan itibaren, aşağıdaki komutlardan birinin sonucu:

git rebase ustası
git rebase ana konusu

olabilir:

A'-B'--C' konusu
/
D---E---F---G ustası

NOT: İkinci form, git checkout konusunun kısa bir eli ve ardından git rebase
usta. Rebase çıktığında konu, teslim alınan dal olarak kalacaktır.

Yukarı akış şubesi, yaptığınız bir değişikliği zaten içeriyorsa (örn.
yukarı yönde uygulanan yama), ardından bu taahhüt atlanacaktır. Örneğin, koşu
git rebase master aşağıdaki tarihte (A' ve A'nın aynı diziyi tanıttığı
değişiklikler, ancak farklı taahhütçü bilgilerine sahip):

A---B---C konusu
/
D---E---A'---F ustası

sonuçlanacak:

B'---C' konusu
/
D---E---A'---F ustası

Bir dala dayalı bir konu dalını diğerine nasıl nakledeceğiniz aşağıda açıklanmıştır.
rebase --onto kullanarak konu dalını ikinci daldan ayırdığınızı.

İlk önce senin olduğunu varsayalım konu şubeye dayalıdır sonraki. Örneğin, geliştirilen bir özellik
konu bulunan bazı işlevlere bağlıdır sonraki.

o---o---o---o---o usta
\
o---o---o---o---o sonraki
\
o---o---o konu

Yapmak istiyoruz konu daldan çatallı usta; örneğin, işlevsellik açık olduğundan
hangi konu bağımlı daha kararlı birleştirildi usta dal. ağacımızı istiyoruz
şuna benzer:

o---o---o---o---o usta
| \
| o'--o'--o' konusu
\
o---o---o---o---o sonraki

Bunu aşağıdaki komutu kullanarak alabiliriz:

git rebase --onto master sonraki konu

--onto seçeneğinin başka bir örneği, bir dalın bir kısmını yeniden temel almaktır. Aşağıdakilere sahipsek
durum:

H---I---J konuB
/
E---F---G konusuA
/
A---B---C---D ustası

sonra komut

git rebase --onto ana konuA konuB

sonuçlanacak:

H'--I'--J' konusuB
/
| E---F---G konusuA
|/
A---B---C---D ustası

Bu, konuB, konuA'ya bağlı olmadığında kullanışlıdır.

Rebase ile bir dizi taahhüt de kaldırılabilir. Aşağıdaki duruma sahipsek:

E---F---G---H---I---J konuA

sonra komut

git rebase --onto konuA~5 konuA~3 konuA

F ve G taahhütlerinin kaldırılmasına neden olur:

E---H'---I'---J' konusuA

Bu, F ve G'nin bir şekilde kusurlu olması veya konu A'nın bir parçası olmaması durumunda yararlıdır. Not
argümanı --onto ve parametre herhangi bir geçerli taahhüt olabilir.

Çatışma durumunda, git yeniden baz almak ilk sorunlu taahhütte duracak ve ayrılacak
ağaçtaki çatışma işaretleri. Kullanabilirsiniz git fark işaretçileri (<<<<<<) bulmak ve
Çatışmayı çözmek için düzenlemeler. Düzenlediğiniz her dosya için Git'e şunu söylemeniz gerekir:
çakışma çözüldü, genellikle bu

git ekle

Çakışmayı manuel olarak çözdükten ve indeksi istenilen çözünürlükte güncelledikten sonra,
ile yeniden temellendirme işlemine devam edebilirsiniz.

git rebase --devam et

Alternatif olarak, işlemi geri alabilirsiniz. git yeniden baz almak ile

git rebase --iptal

YAPILANDIRMA

rebase.stat
Son yeniden temellendirmeden bu yana yukarı yönde nelerin değiştiğine ilişkin bir fark gösterilip gösterilmeyeceği. tarafından yanlış
Varsayılan.

rebase.autoSquash
true olarak ayarlanırsa --otomatik kabak varsayılan olarak seçenek.

rebase.autoStash
true olarak ayarlanırsa --otomatik saklama varsayılan olarak seçenek.

rebase.missingCommitsCheck
"Uyar" olarak ayarlanırsa, etkileşimli modda kaldırılan taahhütlerle ilgili uyarıları yazdırın. olarak ayarlanırsa
"hata", uyarıları yazdırın ve yeniden başlatmayı durdurun. "Yoksay" olarak ayarlanırsa kontrol yapılmaz.
tamamlamak. varsayılan olarak "yoksay".

rebase.instructionFormat
sırasında kullanılacak özel kayıt listesi formatı --interaktif yeniden temel almak.

SEÇENEKLER

--üzerine
Yeni taahhütlerin oluşturulacağı başlangıç ​​noktası. --onto seçeneği değilse
belirtilen, başlangıç ​​noktası . Herhangi bir geçerli taahhüt olabilir ve sadece bir
mevcut şube adı.

Özel bir durum olarak, aşağıdaki durumlarda A ve B'nin birleştirme tabanı için bir kısayol olarak "A...B" kullanabilirsiniz.
tam olarak bir birleştirme üssü var. A ve B'den en fazla birini dışarıda bırakabilirsiniz.
varsayılan olarak HEAD'dir.


Karşılaştırılacak yukarı akış dalı. Yalnızca mevcut bir taahhüt değil, herhangi bir geçerli taahhüt olabilir
şube adı. Geçerli dal için yapılandırılmış yukarı akışa varsayılandır.


Çalışan şube; varsayılan olarak HEAD'dir.

--devam et
Bir birleştirme çakışmasını çözdükten sonra yeniden temellendirme işlemini yeniden başlatın.

-- iptal
Yeniden taban işlemini iptal edin ve HEAD'i orijinal şubeye sıfırlayın. Eğer NS
rebase işlemi başlatıldığında sağlanırsa, HEAD şu şekilde sıfırlanır: .
Aksi takdirde HEAD, yeniden başlatma işlemi başlatıldığında olduğu yere sıfırlanacaktır.

--boş tut
Sonuç olarak ebeveynlerinden hiçbir şeyi değiştirmeyen taahhütleri saklayın.

--atlamak
Geçerli yamayı atlayarak yeniden temellendirme işlemini yeniden başlatın.

--düzenle-yapılacak
Etkileşimli bir yeniden düzenleme sırasında yapılacaklar listesini düzenleyin.

-m, --birleştirme
Yeniden temel almak için birleştirme stratejilerini kullanın. Özyinelemeli (varsayılan) birleştirme stratejisi kullanıldığında,
bu, rebase'in yukarı akış tarafındaki yeniden adlandırmalardan haberdar olmasını sağlar.

Bir yeniden temel birleştirmenin, çalışma dalındaki her bir taahhüdü en üstte tekrar oynatarak çalıştığını unutmayın.
arasında dal. Bu nedenle, bir birleştirme çatışması meydana geldiğinde, taraf
olarak rapor edildi ayı ile başlayan şu ana kadar yeniden oluşturulmuş seridir. , ve onların is
çalışan şube. Başka bir deyişle, taraflar değiştirilir.

-s , --strateji=
Verilen birleştirme stratejisini kullanın. -s seçeneği yoksa git birleştirme özyinelemeli kullanılır
Bunun yerine. Bu --merge anlamına gelir.

Çünkü git yeniden baz almak üzerinde çalışma dalından her taahhüdü tekrarlar
verilen stratejiyi kullanarak şube, ayı strateji basitçe atar
gelen tüm yamalar , bu çok az mantıklı.

-X , --strateji seçeneği=
Geç birleştirme stratejisine kadar. Bu --merge ve eğer
hiçbir strateji belirtilmedi, -s özyinelemeli. geri dönüşünü not edin ayı ve onların as
-m seçeneği için yukarıda belirtilmiştir.

-S[ ], --gpg-işareti[= ]
GPG işareti taahhüt eder. Keyid argümanı isteğe bağlıdır ve varsayılan olarak taahhütte bulunur
Kimlik; belirtilirse, boşluk bırakmadan seçeneğe yapıştırılmalıdır.

-q, --sessiz
Sessiz olun. --no-stat anlamına gelir.

-v, --ayrıntılı
Ayrıntılı olun. --stat anlamına gelir.

--stat
Son yeniden temellendirmeden bu yana yukarı yönde neyin değiştiğinin bir farkını gösterin. Fark durumu aynı zamanda
rebase.stat yapılandırma seçeneği tarafından kontrol edilir.

-n, --istatistik yok
Yeniden temel alma işleminin bir parçası olarak bir fark göstermeyin.

--hayır-doğrulama
Bu seçenek, yeniden temellendirme öncesi kancayı atlar. Ayrıca bakınız githook'lar(5).

--Doğrulayın
Varsayılan olan, yeniden temellendirme öncesi kancanın çalışmasına izin verir. Bu seçenek için kullanılabilir
geçersiz kıl --no-doğrulama. Ayrıca bakınız githook'lar(5).

-C
En azından emin olun çevreleyen bağlam çizgileri, her değişiklikten önce ve sonra eşleşir.
Çevreleyen bağlamın daha az satırı olduğunda, hepsinin eşleşmesi gerekir. Varsayılan olarak hayır
bağlam hiç göz ardı edilir.

-f, --force-rebase
Geçerli dal güncel olsa ve komut olmadan olsa bile yeniden başlatmayı zorla
--force hiçbir şey yapmadan geri dönecekti.

Bunu (veya etkileşimli bir yeniden temelle --no-ff) bir
konu dalı birleştirme, bu seçenek konu dalını yeni taahhütlerle yeniden oluşturduğundan,
"geri döndürmeye" gerek kalmadan başarıyla yeniden birleştirilebilir (bkz.
hatalı birleştirme How-To[1] ayrıntılar için).

-- çatal noktası, -- çatal noktası yok
arasında daha iyi bir ortak ata bulmak için reflog kullanın. ve ne zaman
tarafından hangi taahhütlerin verildiğinin hesaplanması .

--fork-point etkin olduğunda, çatal_noktası yerine kullanılacak ile
rebase için taahhüt setini hesaplayın, burada çatal_noktası git'in sonucudur
birleştirme tabanı -- çatal noktası komut (bkz. git-birleştirme tabanı(1)). Eğer
çatal_noktası boş olarak sona erer, yedek olarak kullanılacaktır.

Eğer ikisinden biri veya --root komut satırında verilir, ardından varsayılan
--no-fork-point, aksi takdirde varsayılan değer --fork-point'tir.

--ignore-whitespace, --whitespace=
Bu bayraklar git uygulamak program (bkz. git-uygula(1)) geçerli olan
yama. --interactive seçeneğiyle uyumlu değil.

--yönetici-tarihi-yazar-tarihi, --ignore-tarihi
Bu bayraklar git am yeniden temellenen taahhütlerin tarihlerini kolayca değiştirmek için
(görmek git am(1)). --interactive seçeneğiyle uyumlu değil.

-i, --etkileşimli
Yeniden temellendirilmek üzere olan taahhütlerin bir listesini yapın. Kullanıcının bu listeyi düzenlemesine izin verin
yeniden temellendirmeden önce. Bu mod aynı zamanda taahhütleri bölmek için de kullanılabilir (bkz.
altında).

İşlem listesi formatı, yapılandırma seçeneği ayarlanarak değiştirilebilir.
rebase.instructionFormat. Özelleştirilmiş bir talimat formatı otomatik olarak
biçime önceden eklenen uzun taahhüt karması.

-p, --preserve-birleştirmeler
Bir birleştirme taahhütlerini tekrar oynatarak geçmişi düzleştirmek yerine birleştirme taahhütlerini yeniden oluşturun
taahhüt tanıtır. Taahhütleri birleştirmek için çakışma çözümlerini veya manuel değişiklikleri birleştirin
korunmazlar.

Bu, --interactive makinelerini dahili olarak kullanır, ancak onu
--interactive seçeneği, ne yaptığınızı bilmiyorsanız, genellikle iyi bir fikir değildir.
yapıyor (aşağıdaki HATALAR'a bakın).

-x , --exec
"exec" ekle " her satırdan sonra nihai tarihte bir taahhüt oluşturur. niyet
bir veya daha fazla kabuk komutu olarak yorumlanabilir.

Bu seçenek yalnızca --interactive seçeneğiyle kullanılabilir (bkz. İNTERAKTİF MOD
altında).

Bir --exec örneğini birkaç komutla birlikte kullanarak birkaç komutu çalıştırabilirsiniz.
komutları:

git rebase -i --exec "cmd1 && cmd2 && ..."

veya birden fazla --exec vererek:

git rebase -i --exec "cmd1" --exec "cmd2" --exec ...

--autosquash kullanılırsa, ara için "exec" satırları eklenmez
taahhüt eder ve yalnızca her squash/düzeltme serisinin sonunda görünür.

--kök
Ulaşılabilen tüm taahhütleri yeniden temellendir ile sınırlamak yerine
. Bu, bir daldaki kök taahhütlerini yeniden temellendirmenizi sağlar. ile kullanıldığında
--onto, zaten içerdiği değişiklikleri atlayacak (onun yerine )
oysa --onto olmadan her değişiklikte çalışır. Her ikisi ile birlikte kullanıldığında
--onto ve --preserve-birleştirmeler, herşey kök taahhütler sahip olmak için yeniden yazılacak olarak
yerine ebeveyn.

--autosquash, --no-autosquash
Kayıt günlüğü mesajı "squash! ..." (veya "düzeltme!...") ile başladığında ve
Başlığı aynı ... ile başlayan bir taahhüt, yapılacaklar listesini otomatik olarak değiştirir
rebase -i böylece ezme için işaretlenen taahhüt, taahhütten hemen sonra gelir
değiştirildi ve taşınan taahhüdün eylemini seçimden squash'a (veya düzeltmeye) değiştirin.
İlkinden sonra gelen "düzeltme!" veya "squash!"
git commit --fixup/--squash ile önceki düzeltme/squash.

Bu seçenek yalnızca şu durumlarda geçerlidir: --interaktif seçeneği kullanılır.

Eğer --otomatik kabak seçenek, yapılandırma değişkeni kullanılarak varsayılan olarak etkinleştirilir
rebase.autoSquash, bu seçenek bu ayarı geçersiz kılmak ve devre dışı bırakmak için kullanılabilir.

--autostash, --no-autostash
İşlem başlamadan önce otomatik olarak geçici bir zula oluşturun ve sonra uygulayın
operasyon biter. Bu, kirli bir çalışma ağacında rebase çalıştırabileceğiniz anlamına gelir. Yine de,
dikkatli kullanın: Başarılı bir yeniden düzenlemeden sonraki son saklama uygulaması,
önemsiz çatışmalar

--hayır-off
--interactive ile, hızlı ileri sarmak yerine tüm yeniden temellenen taahhütleri kesin olarak seçin
değişmeyenler. Bu, yeniden temellenen dalın tüm geçmişinin
yeni taahhütlerden oluşur.

--interactive olmadan, bu --force-rebase ile eşanlamlıdır.

Bu seçenek olarak, bir konu dalı birleştirmesini geri aldıktan sonra bunu yararlı bulabilirsiniz.
konu dalını yeni taahhütlerle yeniden oluşturur, böylece başarıyla yeniden birleştirilebilir
"geri döndürmeye" gerek kalmadan (bkz. hatalı birleştirme How-To[1] için
detaylar).

BİRLEŞTİRMEK STRATEJİLER

Birleştirme mekanizması (git birleştirme ve git çekme komutları) arka uca izin verir birleştirme stratejileri
-s seçeneği ile seçilir. Bazı stratejiler kendi seçeneklerini de alabilir;
-X vererek geçti git birleştirme ve/veya git çekme için argümanlar.

çözmek
Bu sadece iki kafayı çözebilir (yani mevcut dal ve çektiğiniz başka bir dal
from) 3 yollu bir birleştirme algoritması kullanarak. Çapraz birleştirmeyi dikkatlice algılamaya çalışır
belirsizlikler ve genellikle güvenli ve hızlı olarak kabul edilir.

özyineli
Bu, yalnızca 3 yollu bir birleştirme algoritması kullanarak iki kafayı çözebilir. daha fazla olduğunda
3 yönlü birleştirme için kullanılabilecek ortak bir ata, birleştirilmiş bir ağaç oluşturur.
ortak atalar ve bunu 3 yollu birleştirme için referans ağacı olarak kullanır. bu var
testlerde yanlış birleştirmelere neden olmadan daha az birleştirme çatışmasına neden olduğu bildirildi
Linux 2.6 çekirdek geliştirme geçmişinden alınan gerçek birleştirme taahhütlerinde yapılır.
Ek olarak bu, yeniden adlandırma içeren birleştirmeleri algılayabilir ve işleyebilir. Bu varsayılan
bir dalı çekerken veya birleştirirken birleştirme stratejisi.

The özyineli strateji aşağıdaki seçenekleri alabilir:

ayı
Bu seçenek, çakışan parçaları tercih ederek temiz bir şekilde otomatik olarak çözülmeye zorlar. bizim
sürüm. Bizim tarafımızla çelişmeyen diğer ağaçtan gelen değişiklikler
birleştirme sonucuna yansır. Bir ikili dosya için tüm içerik alınır
bizim tarafımızdan.

Bu ile karıştırılmamalıdır ayı bile görünmeyen birleştirme stratejisi
diğer ağacın içerdiği şeyde. Diğer ağacın yaptığı her şeyi atar,
ilan bizim tarih, içinde olan her şeyi içerir.

onların
Bu tam tersi ayı.

sabır
Bu seçenekle, birleştirme özyinelemeli yanlış birleşmeleri önlemek için biraz fazladan zaman harcıyor
bazen önemsiz eşleşme çizgileri nedeniyle oluşur (örneğin, farklı köşeli ayraçlar
fonksiyonlar). Birleştirilecek dallar çılgınca ayrıldığında bunu kullanın. Ayrıca bakınız
git-diff(1) --sabır.

diff-algoritması=[sabır|minimal|histogram|myers]
Söyler birleştirme özyinelemeli önlemek için farklı bir fark algoritması kullanmak
Önemsiz eşleşen satırlar nedeniyle oluşan yanlış birleştirmeler (parantezler gibi)
farklı işlevler). Ayrıca bakınız git-diff(1) --diff-algoritması.

yoksay-boşluk-değiştir, tüm-boşluğu yoksay, eol-uzayda yoksay-boşluk
Belirtilen boşluk değişikliği türüne sahip satırları,
üç yönlü bir birleştirme uğruna. Bir satırdaki diğer değişikliklerle karışık boşluk değişiklikleri
göz ardı edilmez. Ayrıca bakınız git-diff(1) -b, -w ve --ignore-space-at-eol.

· Eğer ve bazı Asya sürüm yalnızca bir satırdaki boşluk değişikliklerini tanıtır, bizim versiyonu
kullanılmış;

· Eğer bizim sürüm boşluk değişikliklerini tanıtır ancak ve bazı Asya sürüm içerir
önemli değişiklik, ve bazı Asya sürüm kullanılır;

· Aksi takdirde, birleştirme olağan şekilde ilerler.

yeniden normalleştirmek
Bu, bir dosyanın üç aşamasının tümü için sanal bir kullanıma alma ve teslim etme işlemi gerçekleştirir.
üç yönlü bir birleştirmeyi çözme. Bu seçenek, dalları birleştirirken kullanılmak içindir.
farklı temiz filtreler veya satır sonu normalleştirme kuralları ile. Bkz. "Birleştirme
farklı iade/ödeme özelliklerine sahip şubeler" git özellikleri(5) için
detaylar.

yeniden normalleştirme yok
Yeniden normalleştirme seçeneğini devre dışı bırakır. Bu, merge.renormalize'ı geçersiz kılar
yapılandırma değişkeni.

yeniden adlandırma eşiği=
Yeniden adlandırma algılaması için kullanılan benzerlik eşiğini kontrol eder. Ayrıca bakınız git-diff(1)
-M.

alt ağaç[= ]
Bu seçenek, daha gelişmiş bir alt ağaç strateji, stratejinin yaptığı yer
Birleşirken iki ağacın birbiriyle eşleşmesi için nasıl kaydırılması gerektiğine dair bir tahmin.
Bunun yerine, belirtilen yola önek eklenir (veya baştan çıkarılır).
eşleşecek iki ağaç şekli.

ahtapot
Bu, ikiden fazla kafa içeren durumları çözer, ancak karmaşık bir birleştirme yapmayı reddeder.
manuel çözünürlüğe ihtiyaç duyar. Öncelikle konu dalını paketlemek için kullanılmak içindir.
birlikte kafalar. Bu, birden fazla çekerken veya birleştirirken varsayılan birleştirme stratejisidir.
bir şube.

ayı
Bu, herhangi bir sayıda kafayı çözer, ancak sonuçta ortaya çıkan birleştirme ağacı her zaman şudur:
geçerli şube başkanının, diğer tüm şubelerdeki tüm değişiklikleri etkin bir şekilde yok sayar.
Yan dalların eski gelişim tarihinin yerini almak için kullanılması amaçlanmıştır. Not
bunun -Xours seçeneğinden farklı olduğunu özyineli birleştirme stratejisi.

alt ağaç
Bu, değiştirilmiş bir özyinelemeli stratejidir. A ve B ağaçlarını birleştirirken, eğer B şuna karşılık geliyorsa
A, B'nin bir alt ağacı, önce A'nın ağaç yapısına uyacak şekilde ayarlanır.
ağaçları aynı seviyede okumak. Bu ayar aynı zamanda ortak
ata ağacı.

3 yönlü birleştirmeyi kullanan stratejilerle (varsayılan dahil, özyineli), eğer bir değişiklik
her iki dalda da yapılır, ancak daha sonra dallardan birinde geri alınırsa, bu değişiklik
birleştirilmiş sonuçta mevcut; bazı insanlar bu davranışı kafa karıştırıcı buluyor. oluşur çünkü
birleştirme yapılırken yalnızca başlıklar ve birleştirme tabanı dikkate alınır,
bireysel taahhütler. Bu nedenle birleştirme algoritması, geri alınan değişikliği hayır olarak kabul eder.
hiç değiştirir ve bunun yerine değiştirilen sürümü değiştirir.

NOTLAR

kullanmanın etkilerini anlamalısınız. git yeniden baz almak paylaştığınız bir depoda.
Ayrıca aşağıdaki UPSTREAM REBASE'DEN KURTARMA bölümüne bakın.

git-rebase komutu çalıştırıldığında, eğer varsa önce bir "yeniden temellendirme öncesi" kancayı çalıştıracaktır.
var. Bu kancayı, akıl sağlığı kontrolleri yapmak ve değilse, yeniden yapılanmayı reddetmek için kullanabilirsiniz.
uygun. Bir örnek için lütfen şablon öncesi yeniden yapılandırma kanca komut dosyasına bakın.

Bitmesi uzerine, mevcut şube olacaktır.

İNTERAKTİF MOD

Etkileşimli olarak yeniden temellendirme, yeniden temellenen taahhütleri düzenleme şansınız olduğu anlamına gelir.
Taahhütleri yeniden sıralayabilir ve bunları kaldırabilirsiniz (kötü veya başka türlü ayıklamak
istenmeyen yamalar).

Etkileşimli mod, bu tür iş akışı içindir:

1. harika bir fikrin var

2. kodu hackleyin

3. Gönderim için bir dizi hazırlayın

4. göndermek

burada 2. nokta birkaç örnekten oluşur

a) düzenli kullanım

1. taahhüt etmeye değer bir şeyi bitirmek

2. taahhüt etmek

b) bağımsız düzeltme

1. bir şeyin çalışmadığını fark etmek

2. bunu düzelt

3. taahhüt et

Bazen b.2'de sabitlenen şey. oldukça mükemmel olmayan bir şekilde değiştirilemez
düzeltmeler, çünkü bu taahhüt bir yama serisine derinden gömülür. tam olarak bu
etkileşimli rebase şunun içindir: bol miktarda "a" ve "b"den sonra, yeniden düzenleyerek ve
düzenleme taahhütleri ve birden fazla işlemi bir araya getirme.

Olduğu gibi tutmak istediğiniz son taahhütle başlayın:

git rebase -i

Mevcut şubenizdeki tüm taahhütlerle bir editör ateşlenecek (birleştirme yok sayılarak
taahhütler), verilen taahhütten sonra gelir. Bu listedeki taahhütleri yeniden sıralayabilirsiniz.
kalbinizin içeriği ve bunları kaldırabilirsiniz. Liste aşağı yukarı şuna benziyor:

pick deadbee Bu taahhüdün tek satırı
seçim fa1afe1 Bir sonraki taahhüdün tek satırı
Kendi ID’n ile mağazalarını oluştur

Oneline açıklamaları tamamen sizin zevkiniz içindir; git yeniden baz almak onlara bakmayacak
ancak taahhüt adlarında (bu örnekte "deadbee" ve "fa1afe1"), silmeyin veya
isimleri düzenleyin.

"seç" komutunu "düzenle" komutuyla değiştirerek, git yeniden baz almak durdurmak için
bu taahhüdü uyguladıktan sonra, dosyaları ve/veya taahhüt mesajını düzenleyebilmeniz için,
taahhüdü değiştirin ve yeniden düzenlemeye devam edin.

Sadece bir taahhüt için taahhüt mesajını düzenlemek istiyorsanız, "seç" komutunu ile değiştirin.
"tekrar kelime" komutu.

Bir taahhüdü bırakmak için, "seç" komutunu "bırak" ile değiştirin veya eşleşmeyi silin
hattı.

İki veya daha fazla taahhüdü bire katlamak istiyorsanız, "seç" komutunu değiştirin.
ikinci ve sonraki taahhütler "squash" veya "fixup" ile. Taahhütler farklı olsaydı
yazarlar, katlanmış taahhüt, ilk taahhüdün yazarına atfedilecektir. NS
katlanmış taahhüt için önerilen taahhüt mesajı, taahhüt mesajlarının birleştirilmesidir
ilk taahhüdün ve "squash" komutuna sahip olanların, ancak taahhüt mesajlarını atlayanların
"düzeltme" komutuyla taahhüt eder.

git yeniden baz almak "seçme", "düzenleme" ile değiştirildiğinde veya bir komut nedeniyle başarısız olduğunda duracaktır
hataları birleştirmek için. Düzenlemeyi ve/veya çakışmaları çözmeyi tamamladığınızda devam edebilirsiniz.
git rebase ile --continue.

Örneğin, son 5 taahhüdü yeniden sıralamak istiyorsanız, HEAD~4 olan şey şu şekilde olur:
yeni BAŞ. Bunu başarmak için git yeniden baz almak bunun gibi:

$ git rebase -i HEAD~5

Ve ilk yamayı listenin sonuna taşıyın.

Bunun gibi bir geçmişiniz varsa, birleştirmeleri korumak isteyebilirsiniz:

X
\
A---M---B
/
----o---O---P---Q

"A" ile başlayan yan dalı "Q"ya yeniden temellendirmek istediğinizi varsayalım. emin olun
mevcut HEAD "B" ve çağrı

$ git rebase -i -p --onto QO

Yeniden sıralama ve düzenleme taahhütleri genellikle test edilmemiş ara adımlar oluşturur. İsteyebilirsin
bir test yaparak veya en azından, geçmiş düzenlemenizin hiçbir şeyi bozmadığını kontrol etmek için
"exec" komutunu (kısayol "x") kullanarak geçmişin ara noktalarında yeniden derleme.
Bunun gibi bir yapılacaklar listesi oluşturarak bunu yapabilirsiniz:

ölü arıyı seç XXX özelliğini uygula
düzeltme f1a5c00 XXX özelliğine düzeltme
yürütmek
c0ffee'yi seç Sonraki işlemin tek satırı
deadbab'ı düzenle: İşlemin tek satırı
exec cd alt dizini; test yapmak
Kendi ID’n ile mağazalarını oluştur

Bir komut başarısız olduğunda (yani 0 olmayan durumla çıkar) etkileşimli yeniden temel duracaktır.
size sorunu çözme fırsatı verin. git rebase --continue ile devam edebilirsiniz.

"exec" komutu, komutu bir kabukta başlatır ($SHELL'de belirtilen veya
$SHELL ayarlanmamışsa varsayılan kabuk), böylece kabuk özelliklerini ("cd", ">", ";" gibi) kullanabilirsiniz.
...). Komut, çalışan ağacın kökünden çalıştırılır.

$ git rebase -i --exec "test yap"

Bu komut, ara taahhütlerin derlenebilir olup olmadığını kontrol etmenizi sağlar. Yapılacaklar listesi
şöyle olur:

5928aea birini seç
exec yapmak testi
04d0fda iki seç
exec yapmak testi
ba46169 üç seç
exec yapmak testi
f4593f9'u dört seç
exec yapmak testi

AYIRMA KOMİTELER

Etkileşimli modda, "düzenle" eylemiyle taahhütleri işaretleyebilirsiniz. Ancak, bu olmaz
mutlaka demek git yeniden baz almak bu düzenlemenin sonucunun tam olarak bir taahhüt olmasını bekler.
Gerçekten de, taahhüdü geri alabilir veya başka taahhütler ekleyebilirsiniz. Bu bir bölmek için kullanılabilir
ikiye katlayın:

· git rebase -i ile etkileşimli bir rebase başlatın ^, nerede taahhüt mü
bölmek istiyorsun. Aslında, herhangi bir taahhüt aralığı, bunu içerdiği sürece yapacaktır.
taahhüt.

· Bölmek istediğiniz taahhüdü "düzenle" eylemiyle işaretleyin.

· Bu taahhüdü düzenlemeye gelince, git reset HEAD^ yürütün. Etkisi şu ki,
HEAD bir geri sarılır ve indeks de buna uygundur. Ancak, çalışan ağaç kalır
aynısı.

· Şimdi, ilk işlemde olmasını istediğiniz değişiklikleri dizine ekleyin. Yapabilirsiniz
git add kullanın (muhtemelen etkileşimli olarak) veya git gui (veya her ikisi) bunu yapmak için.

· Şu anda geçerli olan dizini, şimdi uygun olan herhangi bir taahhüt mesajı ile taahhüt edin.

· Çalışan ağacınız temiz olana kadar son iki adımı tekrarlayın.

· Rebase'e git rebase --continue ile devam edin.

Ara revizyonların tutarlı olduğundan kesinlikle emin değilseniz (bunlar
derlemek, test takımını geçmek vb.) kullanmanız gerekir git saklamak saklamak için
Her bir taahhütten sonra henüz taahhüt edilmemiş değişiklikler, düzeltmeler yapıldıysa taahhüdü test edin ve değiştirin
gerekli.

KURTARMA DAN YÜKSEK AKIM YENİDEN BAZ

Başkalarının temel aldığı bir dalın yeniden temellendirilmesi (veya başka bir yeniden yazma biçimi) kötüdür.
fikir: aşağı akışındaki herkes geçmişini manuel olarak düzeltmeye zorlanır. Bu bölüm
aşağı yöndeki bakış açısından düzeltmenin nasıl yapılacağını açıklar. Ancak asıl düzeltme,
ilk etapta yukarı akışı yeniden temellendirmekten kaçınmak olacaktır.

Örneklemek gerekirse, birinin bir şey geliştirdiği bir durumda olduğunuzu varsayalım. alt şube,
ve üzerinde çalışıyorsun konu bu buna bağlı alt. ile bitebilirsin
aşağıdaki gibi bir geçmiş:

o---o---o---o---o---o---o---o---o usta
\
o---o---o---o---o alt sistemi
\
*---*---* başlık

If alt karşı yeniden temellendirilir usta, aşağıdakiler olur:

o---o---o---o---o---o---o---o usta
\\
o---o---o---o---o o'--o'--o'--o'--o' alt sistemi
\
*---*---* başlık

Şimdi her zamanki gibi geliştirmeye devam ederseniz ve sonunda birleşirseniz konu için alt,
taahhüt eder alt sonsuza kadar kopyalanmış olarak kalacaktır:

o---o---o---o---o---o---o---o usta
\\
o--o---o---o---o o'--o'--o'--o'--o'--M alt sistemi
\ /
*---*---*-..........-*--* başlık

Bu tür kopyalar genellikle hoş karşılanmaz çünkü tarihi karmaşıklaştırırlar.
takip etmesi daha zor. İşleri temizlemek için, taahhütleri aktarmanız gerekir. konu için
yeni alt ipucu, yani rebase konu. Bu bir dalgalanma etkisi haline gelir: aşağı yöndeki herkes
itibaren konu da yeniden temel almaya zorlanır, vb!

Aşağıdaki alt bölümlerde tartışılan iki tür düzeltme vardır:

Kolay durum: Değişiklikler kelimenin tam anlamıyla aynı.
Bu, eğer alt rebase basit bir rebase idi ve hiçbir çatışması yoktu.

Zor durum: Değişiklikler aynı değil.
Bu, eğer alt rebase'in çakışmaları vardı veya --interactive'i atlamak için kullandı,
düzenleme, ezme veya düzeltme taahhütleri; veya yukarı akış, taahhütten birini kullandıysa --amend, reset,
veya filtre dalı.

The kolay dava
Yalnızca değişiklikler (fark içeriğine dayalı yama kimlikleri) alt vardır
rebase öncesi ve sonrası kelimenin tam anlamıyla aynı alt yaptı.

Bu durumda, düzeltme kolaydır çünkü git yeniden baz almak zaten olan değişiklikleri atlamayı bilir
yeni yukarı akışta mevcut. Yani (açık olduğunuzu varsayarak) derseniz konu)

$ git rebase alt sistemi

sabit geçmişle sonuçlanacaksın

o---o---o---o---o---o---o---o usta
\
o'--o'--o'--o'--o' alt sistemi
\
*---*---* başlık

The zor dava
olursa işler daha da karmaşıklaşır. alt değişiklikler tam olarak olanlara uymuyor
rebase'den önce.

not
Bir "kolay vaka kurtarma" bazen zor koşullarda bile başarılı gibi görünse de
durumda, istenmeyen sonuçlar doğurabilir. Örneğin, aracılığıyla kaldırılan bir taahhüt
git rebase --interactive olacak dirildi!

Fikir manuel olarak anlatmaktır git yeniden baz almak "nerede eski alt bitti ve senin konu
başladı", yani aralarındaki eski birleştirme üssü neydi.
eskinin son taahhüdünü adlandır alt, Örneğin:

· İle alt reflog: sonra git almak, eski ucu alt var
altsistem@{1}. Sonraki alımlar sayıyı artıracaktır. (Görmek git-reflog(1)).

· Ucuna göre konu: senin olduğunu bilmek konu üç taahhüt var, eski ipucu
of alt konu~3 olmalıdır.

Daha sonra (reflog için) diyerek eski alt sistemi..konuyu yeni ipucuna nakledebilirsiniz.
durumda ve açık olduğunuzu varsayarsak konu çoktan):

$ git rebase --onto alt sistem alt sistemi@{1}

"Zor durum" kurtarma işleminin dalgalanma etkisi özellikle kötüdür: herkes aşağı akış
konu şimdi de bir "zor durumda" kurtarma işlemi yapmak zorunda kalacak!

onworks.net hizmetlerini kullanarak git-rebase'i çevrimiçi kullanın