git-rebase - Dalam talian dalam Awan

JADUAL:

NAMA

git-rebase - Penyertaan tempatan port ke hadapan pada kepala huluan yang dikemas kini

SINOPSIS

pergi melunaskan semula [-i | --interaktif] [pilihan] [--exec ] [--kepada ]
[ [ ]]
pergi melunaskan semula [-i | --interaktif] [pilihan] [--exec ] [--kepada ]
--akar [ ]
pergi melunaskan semula --sambung | --langkau | --gugurkan | --edit-todo

DESCRIPTION

Jika dinyatakan, pergi melunaskan semula akan melakukan pembayaran git automatik
sebelum melakukan perkara lain. Jika tidak, ia kekal pada cawangan semasa.

Jika tidak ditentukan, huluan dikonfigurasikan dalam cawangan. .jauh dan
cawangan. Pilihan .merge akan digunakan (lihat git-config(1) untuk butiran) dan
Pilihan --fork-point diandaikan. Jika anda pada masa ini tidak berada di mana-mana cawangan atau jika semasa
cawangan tidak mempunyai huluan yang dikonfigurasikan, pangkalan semula akan dibatalkan.

Semua perubahan yang dibuat oleh komit dalam cawangan semasa tetapi yang tidak ada diselamatkan
ke kawasan sementara. Ini adalah set komit yang sama yang akan ditunjukkan oleh git log
..KEPALA; atau dengan git log 'fork_point'..HEAD, jika --fork-point aktif (lihat
penerangan pada --fork-point di bawah); atau dengan git log HEAD, jika pilihan --root ditentukan.

Cawangan semasa ditetapkan semula kepada , atau jika pilihan --onto telah dibekalkan.
Ini mempunyai kesan yang sama seperti git reset --hard (atau ). ORIG_HEAD ialah
ditetapkan untuk menunjuk pada hujung cawangan sebelum set semula.

Komit yang sebelum ini disimpan ke dalam kawasan sementara kemudiannya digunakan semula pada
cawangan semasa, satu demi satu, mengikut urutan. Ambil perhatian bahawa sebarang komit dalam HEAD yang memperkenalkan
perubahan teks yang sama seperti komit dalam HEAD.. ditinggalkan (iaitu, tampalan sudah
diterima di hulu dengan mesej komit yang berbeza atau cap masa akan dilangkau).

Ada kemungkinan kegagalan gabungan akan menghalang proses ini daripada menjadi sepenuhnya
automatik. Anda perlu menyelesaikan sebarang kegagalan gabungan tersebut dan jalankan git rebase --continue.
Pilihan lain ialah memintas komit yang menyebabkan kegagalan gabungan dengan git rebase
--langkau. Untuk menyemak yang asal dan keluarkan fail .git/rebase-apply yang berfungsi,
gunakan arahan git rebase --abort sebaliknya.

Andaikan sejarah berikut wujud dan cawangan semasa ialah "topik":

A---B---C topik
/
D---E---F---G tuan

Dari sudut ini, hasil daripada salah satu daripada arahan berikut:

git rebase master
topik induk git rebase

akan menjadi:

Topik A'--B'--C'
/
D---E---F---G tuan

PERHATIAN: Borang terakhir hanyalah ringkasan topik git checkout diikuti oleh git rebase
tuan. Apabila rebase keluar topik akan kekal sebagai cawangan daftar keluar.

Jika cawangan huluan sudah mengandungi perubahan yang telah anda buat (cth, kerana anda menghantar a
patch yang digunakan di hulu), maka komit itu akan dilangkau. Contohnya, berlari
git rebase master pada sejarah berikut (di mana A' dan A memperkenalkan set yang sama
perubahan, tetapi mempunyai maklumat committer yang berbeza):

A---B---C topik
/
D---E---A'---F tuan

akan menghasilkan:

Topik B'---C'
/
D---E---A'---F tuan

Berikut ialah cara anda memindahkan cawangan topik berdasarkan satu cawangan ke cawangan lain, untuk berpura-pura
bahawa anda telah memotong cabang topik dari cawangan yang terakhir, menggunakan rebase --onto.

Mula-mula mari kita anggap anda topik adalah berdasarkan cawangan seterusnya. Sebagai contoh, ciri dibangunkan dalam
topik bergantung pada beberapa fungsi yang terdapat dalam seterusnya.

o---o---o---o---o tuan
\
o---o---o---o---o seterusnya
\
o---o---o topik

Kami nak buat topik bercabang dari dahan master; sebagai contoh, kerana fungsi pada
yang topik bergantung telah digabungkan menjadi lebih stabil master cawangan. Kami mahu pokok kami
kelihatan seperti ini:

o---o---o---o---o tuan
| \
| topik o'--o'--o'
\
o---o---o---o---o seterusnya

Kita boleh mendapatkan ini menggunakan arahan berikut:

git rebase --untuk menguasai topik seterusnya

Satu lagi contoh pilihan --onto ialah meletakkan semula sebahagian daripada cawangan. Jika kita mempunyai perkara berikut
keadaan:

H---I---J topikB
/
E---F---G topikA
/
A---B---C---D tuan

kemudian perintah

git rebase --kepada topik indukA topikB

akan mengakibatkan:

H'--I'--J' topikB
/
| E---F---G topikA
|/
A---B---C---D tuan

Ini berguna apabila topikB tidak bergantung pada topikA.

Pelbagai komitmen juga boleh dialih keluar dengan rebase. Jika kita mempunyai situasi berikut:

E---F---G---H---I---J topikA

kemudian perintah

git rebase --ke topikA~5 topikA~3 topikA

akan mengakibatkan penyingkiran komit F dan G:

E---H'---I'---J' topikA

Ini berguna jika F dan G mempunyai kecacatan dalam beberapa cara, atau tidak sepatutnya menjadi sebahagian daripada topikA. Catatan
bahawa hujah untuk --onto dan parameter boleh menjadi sebarang komit-ish yang sah.

Sekiranya berlaku konflik, pergi melunaskan semula akan berhenti pada komitmen bermasalah pertama dan pergi
penanda konflik dalam pokok. Anda boleh gunakan pergi diff untuk mencari penanda (<<<<<<) dan membuat
suntingan untuk menyelesaikan konflik. Untuk setiap fail yang anda edit, anda perlu memberitahu Git bahawa fail
konflik telah diselesaikan, biasanya ini akan dilakukan dengan

git add

Selepas menyelesaikan konflik secara manual dan mengemas kini indeks dengan resolusi yang diingini,
anda boleh meneruskan proses asas semula dengan

git rebase - teruskan

Sebagai alternatif, anda boleh membuat asal pergi melunaskan semula bersama

git rebase --abort

CONFIGURATION

rebase.stat
Sama ada mahu menunjukkan diffstat tentang perkara yang berubah di hulu sejak pangkalan semula terakhir. Palsu oleh
lalai.

rebase.autoSquash
Jika ditetapkan kepada benar dayakan --autoskuash pilihan secara lalai.

rebase.autoStash
Jika ditetapkan kepada benar dayakan --autostash pilihan secara lalai.

rebase.missingCommitsCheck
Jika ditetapkan kepada "amaran", cetak amaran tentang komit yang dialih keluar dalam mod interaktif. Jika ditetapkan kepada
"ralat", cetak amaran dan hentikan pangkalan semula. Jika ditetapkan kepada "abaikan", tiada semakan adalah
selesai. "abaikan" secara lalai.

rebase.instructionFormat
Format senarai komitmen tersuai untuk digunakan semasa --interaktif rebase.

PILIHAN

--kepada
Titik permulaan untuk membuat komitmen baharu. Jika pilihan --onto tidak
ditentukan, titik permulaan ialah . Mungkin sebarang komitmen yang sah, dan bukan hanya satu
nama cawangan sedia ada.

Sebagai kes khas, anda boleh menggunakan "A...B" sebagai pintasan untuk asas gabungan A dan B jika
terdapat betul-betul satu pangkalan gabungan. Anda boleh meninggalkan paling banyak satu daripada A dan B, di mana
kes ia lalai kepada HEAD.


Cawangan hulu untuk dibandingkan. Mungkin sebarang komitmen yang sah, bukan hanya yang sedia ada
nama cawangan. Lalai kepada huluan yang dikonfigurasikan untuk cawangan semasa.


Cawangan kerja; lalai kepada HEAD.

--sambung
Mulakan semula proses pengasingan semula selepas menyelesaikan konflik gabungan.

--menggugurkan kandungan
Hentikan operasi rebase dan tetapkan semula HEAD ke cawangan asal. Jika adalah
dengan syarat apabila operasi rebase dimulakan, maka HEAD akan ditetapkan semula kepada .
Jika tidak, HEAD akan ditetapkan semula ke tempatnya semasa operasi pangkalan semula dimulakan.

--terus-kosongkan
Kekalkan komitmen yang tidak mengubah apa-apa daripada ibu bapanya dalam hasilnya.

--langkau
Mulakan semula proses asas semula dengan melangkau patch semasa.

--edit-todo
Edit senarai tugasan semasa pangkalan semula interaktif.

-m, --bercantum
Gunakan strategi penggabungan untuk asas semula. Apabila strategi gabungan rekursif (lalai) digunakan,
ini membolehkan rebase mengetahui nama semula di bahagian hulu.

Ambil perhatian bahawa gabungan rebase berfungsi dengan memainkan semula setiap komit daripada cawangan kerja di atas
daripada cawangan. Kerana ini, apabila konflik gabungan berlaku, pihak
dilaporkan sebagai menanggung ialah siri berasaskan semula setakat ini, bermula dengan , dan mereka is
cawangan yang bekerja. Dalam erti kata lain, pihak ditukar.

-s , --strategi=
Gunakan strategi gabungan yang diberikan. Jika tiada pilihan -s pergi gabungan-rekursif digunakan
sebaliknya. Ini bermakna --merge.

Kerana pergi melunaskan semula memainkan semula setiap komit daripada cawangan kerja di atas
cawangan menggunakan strategi yang diberikan, menggunakan menanggung strategi hanya membuang
semua patch daripada , yang tidak masuk akal.

-X , --strategy-option=
Lulus melalui strategi gabungan. Ini membayangkan --gabung dan, jika
tiada strategi telah ditentukan, -s rekursif. Perhatikan pembalikan menanggung and mereka as
dinyatakan di atas untuk pilihan -m.

-S[ ], --gpg-sign[= ]
GPG-sign commit. Argumen keyid adalah pilihan dan lalai kepada committer
identiti; jika dinyatakan, ia mesti melekat pada pilihan tanpa ruang.

-q, --senyap
Senyap. Menyiratkan --no-stat.

-v, --verbose
Berkata-kata. Menyiratkan --stat.

--stat
Tunjukkan diffstat perkara yang berubah di hulu sejak pangkalan semula terakhir. Diffstatnya juga
dikawal oleh pilihan konfigurasi rebase.stat.

-n, --tiada-stat
Jangan tunjukkan diffstat sebagai sebahagian daripada proses asas semula.

--tidak-sahkan
Pilihan ini memintas cangkuk pra-rebase. Lihat juga githooks(5).

--sahkan
Membenarkan cangkuk pra-asas semula berjalan, yang merupakan lalai. Pilihan ini boleh digunakan untuk
override --no-verify. Lihat juga githooks(5).

-C
Pastikan sekurang-kurangnya barisan konteks sekeliling sepadan sebelum dan selepas setiap perubahan.
Apabila lebih sedikit baris konteks sekeliling wujud, semuanya mesti sepadan. Secara lalai no
konteks selalu diabaikan.

-f, --force-rebase
Paksa rebase walaupun cawangan semasa adalah terkini dan arahan tanpa
--force akan kembali tanpa melakukan apa-apa.

Anda mungkin mendapati ini (atau --no-ff dengan pangkalan semula interaktif) membantu selepas mengembalikan a
cawangan topik bergabung, kerana pilihan ini mencipta semula cawangan topik dengan komitmen baru supaya ia
boleh digabungkan semula dengan jayanya tanpa perlu "mengembalikan semula" (lihat
revert-a-faulty-merge How-To[1] untuk butiran).

--mata-garpu, --tiada-mata-garpu
Gunakan reflog untuk mencari nenek moyang yang lebih baik antara dan bila
mengira komit yang telah diperkenalkan oleh .

Apabila --fork-point aktif, fork_point akan digunakan sebagai ganti kepada
hitung set komitmen untuk asas semula, di mana fork_point adalah hasil daripada git
merge-base --fork-point perintah (lihat git-merge-base(1)). Jika
fork_point akhirnya menjadi kosong, yang akan digunakan sebagai sandaran.

Jika sama ada atau --root diberikan pada baris arahan, maka lalainya ialah
--no-fork-point, jika tidak lalai ialah --fork-point.

--ignore-whitespace, --whitespace=
Bendera ini diserahkan kepada pergi memohon program (lihat git-apply(1)) yang terpakai
tampalan. Tidak serasi dengan pilihan --interactive.

--committer-date-is-author-date, --ignore-date
Bendera ini diserahkan kepada pergi am untuk menukar tarikh komitmen berasaskan semula dengan mudah
(Lihat git-am(1)). Tidak serasi dengan pilihan --interactive.

-i, --interaktif
Buat senarai komitmen yang akan dibuat semula. Biarkan pengguna mengedit senarai itu
sebelum asas semula. Mod ini juga boleh digunakan untuk memisahkan commit (lihat SPLITTING COMMITS
di bawah).

Format senarai komit boleh diubah dengan menetapkan pilihan konfigurasi
rebase.instructionFormat. Format arahan yang disesuaikan secara automatik akan mempunyai
cincangan komit lama didahulukan pada format.

-p, --pelihara-bercantum
Cipta semula komit gabungan dan bukannya meratakan sejarah dengan memainkan semula komit gabungan
commit memperkenalkan. Gabungkan penyelesaian konflik atau pindaan manual untuk menggabungkan komitmen
tidak dipelihara.

Ini menggunakan jentera --interactive secara dalaman, tetapi menggabungkannya dengan
--pilihan interaktif secara eksplisit secara amnya bukanlah idea yang baik melainkan anda tahu perkara anda
sedang lakukan (lihat BUGS di bawah).

-x , --exec
Tambah "exec " selepas setiap baris mencipta komit dalam sejarah akhir. kehendak
ditafsirkan sebagai satu atau lebih arahan shell.

Pilihan ini hanya boleh digunakan dengan pilihan --interactive (lihat MOD INTERAKTIF
di bawah).

Anda boleh melaksanakan beberapa arahan sama ada dengan menggunakan satu contoh --exec dengan beberapa
arahan:

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

atau dengan memberikan lebih daripada satu --exec:

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

Jika --autosquash digunakan, baris "exec" tidak akan ditambahkan untuk perantaraan
melakukan, dan hanya akan muncul pada penghujung setiap siri skuasy/pembetulan.

--akar
Asaskan semula semua komitmen yang boleh dicapai daripada , bukannya mengehadkannya dengan
. Ini membolehkan anda membuat asas semula komit akar pada cawangan. Apabila digunakan dengan
--ke, ia akan melangkau perubahan yang telah terkandung dalam (sebaliknya )
sedangkan tanpa --onto ia akan beroperasi pada setiap perubahan. Apabila digunakan bersama dengan kedua-duanya
--ke dan --pelihara-bercantum, semua root commit akan ditulis semula untuk dimiliki sebagai
ibu bapa sebaliknya.

--autosquash, --no-autosquash
Apabila mesej log komit bermula dengan "skuasy! ..." (atau "fixup! ..."), dan terdapat
komitmen yang tajuknya bermula dengan yang sama ..., mengubah suai senarai tugasan secara automatik
rebase -i supaya komit yang ditandakan untuk skuasy datang sejurus selepas komit to be
diubah suai, dan tukar tindakan komit yang dialihkan daripada pick kepada skuasy (atau fixup).
Abaikan "pembetulan!" atau "skuasy!" yang berikutnya selepas yang pertama, sekiranya anda merujuk kepada
fixup/skuasy sebelum ini dengan git commit --fixup/--squash.

Pilihan ini hanya sah apabila --interaktif pilihan digunakan.

Jika --autoskuash pilihan didayakan secara lalai menggunakan pembolehubah konfigurasi
rebase.autoSquash, pilihan ini boleh digunakan untuk mengatasi dan melumpuhkan tetapan ini.

--autostash, --no-autostash
Buat simpanan sementara secara automatik sebelum operasi bermula, dan gunakannya selepas itu
operasi tamat. Ini bermakna anda boleh menjalankan rebase pada worktree yang kotor. Walau bagaimanapun,
gunakan dengan berhati-hati: permohonan simpanan terakhir selepas pangkalan semula yang berjaya mungkin mengakibatkan
konflik bukan perkara remeh.

--tidak-ff
Dengan --interactive, cherry-pick semua komitmen berasaskan semula dan bukannya meneruskan pantas
yang tidak berubah. Ini memastikan bahawa keseluruhan sejarah cawangan berasaskan semula adalah
terdiri daripada komitmen baharu.

Tanpa --interactive, ini adalah sinonim untuk --force-rebase.

Anda mungkin mendapati ini berguna selepas mengembalikan gabungan cabang topik, sebagai pilihan ini
mencipta semula cabang topik dengan komitmen baharu supaya ia boleh digabungkan semula dengan jayanya
tanpa perlu "mengembalikan semula" (lihat revert-a-faulty-merge How-To[1] untuk
perincian).

MERGE STRATEGI

Mekanisme merge (arahan git merge dan git pull) membenarkan bahagian belakang bergabung strategi
untuk dipilih dengan pilihan -s. Sesetengah strategi juga boleh mengambil pilihan mereka sendiri, yang boleh
diluluskan dengan memberi -X hujah untuk git merge dan/atau git pull.

menyelesaikan
Ini hanya boleh menyelesaikan dua kepala (iaitu cawangan semasa dan cawangan lain yang anda tarik
daripada) menggunakan algoritma gabungan 3 hala. Ia cuba mengesan cantuman silang silang dengan teliti
kekaburan dan dianggap secara amnya selamat dan cepat.

rekursif
Ini hanya boleh menyelesaikan dua kepala menggunakan algoritma gabungan 3 hala. Apabila terdapat lebih daripada
satu nenek moyang biasa yang boleh digunakan untuk cantuman 3 hala, ia mewujudkan pokok gabungan
nenek moyang yang sama dan menggunakannya sebagai pokok rujukan untuk gabungan 3 hala. Ini mempunyai
telah dilaporkan mengakibatkan lebih sedikit konflik cantuman tanpa menyebabkan salah cantum oleh ujian
dilakukan pada penggabungan sebenar yang diambil daripada sejarah pembangunan kernel Linux 2.6.
Selain itu, ini boleh mengesan dan mengendalikan gabungan yang melibatkan nama semula. Ini adalah lalai
strategi gabungan apabila menarik atau menggabungkan satu cabang.

. rekursif strategi boleh mengambil pilihan berikut:

menanggung
Pilihan ini memaksa orang yang bercanggah untuk diselesaikan secara automatik dengan memilih kami
versi. Perubahan dari pokok lain yang tidak bercanggah dengan pihak kita ialah
dicerminkan kepada hasil gabungan. Untuk fail binari, keseluruhan kandungan diambil
dari pihak kami.

Ini tidak boleh dikelirukan dengan menanggung strategi gabungan, yang tidak kelihatan
pada apa yang pokok lain mengandungi sama sekali. Ia membuang semua yang dilakukan oleh pokok lain,
mengisytiharkan kami sejarah mengandungi semua yang berlaku di dalamnya.

mereka
Ini adalah bertentangan dengan menanggung.

kesabaran
Dengan pilihan ini, gabungan-rekursif meluangkan sedikit masa tambahan untuk mengelakkan kesilapan
yang kadangkala berlaku disebabkan oleh garis padanan yang tidak penting (cth, pendakap daripada berbeza
fungsi). Gunakan ini apabila cawangan yang hendak dicantumkan telah menyimpang secara liar. Lihat juga
git-diff(1) --sabar.

diff-algorithm=[kesabaran|minimal|histogram|myers]
Memberitahu gabungan-rekursif untuk menggunakan algoritma perbezaan yang berbeza, yang boleh membantu mengelakkan
salah cantum yang berlaku disebabkan oleh garisan padanan yang tidak penting (seperti pendakap daripada
fungsi yang berbeza). Lihat juga git-diff(1) --algoritma-perbezaan.

abaikan-ruang-ubah, abaikan-semua-ruang, abaikan-ruang-at-eol
Menganggap garisan dengan jenis perubahan ruang putih yang ditunjukkan sebagai tidak berubah untuk
demi gabungan tiga hala. Perubahan ruang putih bercampur dengan perubahan lain pada baris
tidak diabaikan. Lihat juga git-diff(1) -b, -w, dan --abaikan-ruang-at-eol.

· Jika perkhidmatan versi hanya memperkenalkan perubahan ruang putih pada baris, kami versi adalah
digunakan;

· Jika kami versi memperkenalkan perubahan ruang putih tetapi perkhidmatan versi termasuk a
perubahan yang ketara, perkhidmatan versi digunakan;

· Jika tidak, penggabungan diteruskan dengan cara biasa.

menormalkan semula
Ini menjalankan daftar keluar dan daftar masuk maya bagi ketiga-tiga peringkat fail apabila
menyelesaikan gabungan tiga hala. Pilihan ini dimaksudkan untuk digunakan apabila menggabungkan cawangan
dengan penapis bersih yang berbeza atau peraturan normalisasi hujung talian. Lihat "Penggabungan
cawangan dengan atribut daftar masuk/daftar keluar yang berbeza" masuk gitattribut(5) untuk
butiran.

tidak menormalkan semula
Melumpuhkan pilihan normalisasi semula. Ini mengatasi merge.renormalize
pembolehubah konfigurasi.

namakan semula-ambang=
Mengawal ambang persamaan yang digunakan untuk pengesanan nama semula. Lihat juga git-diff(1)
-M.

pokok kecil[= ]
Pilihan ini adalah bentuk yang lebih maju pokok kecil strategi, di mana strategi membuat
tekaan tentang bagaimana dua pokok mesti dianjak untuk dipadankan antara satu sama lain apabila bergabung.
Sebaliknya, laluan yang ditentukan diberi awalan (atau dilucutkan dari awal) untuk dibuat
bentuk dua pokok untuk dipadankan.

sotong
Ini menyelesaikan kes dengan lebih daripada dua kepala, tetapi enggan melakukan gabungan kompleks itu
memerlukan resolusi manual. Ia terutamanya bertujuan untuk digunakan untuk menghimpunkan cawangan topik
kepala bersama-sama. Ini ialah strategi gabungan lalai apabila menarik atau menggabungkan lebih daripada
satu cabang.

menanggung
Ini menyelesaikan sebarang bilangan kepala, tetapi pokok gabungan yang terhasil sentiasa itu
ketua cawangan semasa, dengan berkesan mengabaikan semua perubahan daripada semua cawangan lain.
Ia bertujuan untuk digunakan untuk menggantikan sejarah pembangunan lama cawangan sampingan. Catatan
bahawa ini berbeza daripada pilihan -Xours kepada rekursif strategi gabungan.

pokok kecil
Ini ialah strategi rekursif yang diubah suai. Apabila mencantumkan pokok A dan B, jika B sepadan dengan
subpokok A, B mula-mula dilaraskan agar sepadan dengan struktur pokok A, bukannya
membaca pokok pada tahap yang sama. Pelarasan ini juga dilakukan kepada yang biasa
pokok nenek moyang.

Dengan strategi yang menggunakan gabungan 3 hala (termasuk lalai, rekursif), jika ada perubahan
dibuat pada kedua-dua cawangan, tetapi kemudian dibalikkan pada salah satu cawangan, perubahan itu akan berlaku
hadir dalam hasil gabungan; sesetengah orang mendapati tingkah laku ini mengelirukan. Ia berlaku kerana
hanya kepala dan pangkalan gabungan dipertimbangkan semasa melakukan gabungan, bukan
individu melakukan. Oleh itu, algoritma gabungan menganggap perubahan yang dibalikkan sebagai tidak
berubah sama sekali, dan menggantikan versi yang diubah.

NOTA

Anda harus memahami implikasi penggunaan pergi melunaskan semula pada repositori yang anda kongsi.
Lihat juga MEMULIH DARI BASE REBASE UPSTREAM di bawah.

Apabila arahan git-rebase dijalankan, ia akan melaksanakan cangkuk "pra-rebase" terlebih dahulu jika satu
wujud. Anda boleh menggunakan cangkuk ini untuk melakukan semakan kewarasan dan menolak rebase jika tidak
sesuai. Sila lihat skrip cangkuk pra-semula templat sebagai contoh.

Apabila selesai, akan menjadi cawangan semasa.

INTERAKTIF MODE

Mengasingkan semula secara interaktif bermakna anda mempunyai peluang untuk mengedit komitmen yang berasaskan semula.
Anda boleh menyusun semula komit, dan anda boleh mengalih keluarnya (menyingkirkan yang buruk atau sebaliknya
tompok yang tidak diingini).

Mod interaktif dimaksudkan untuk jenis aliran kerja ini:

1. mempunyai idea yang bagus

2. menggodam kod

3. menyediakan satu siri untuk penyerahan

4. menyerahkan

di mana titik 2. terdiri daripada beberapa contoh

a) penggunaan biasa

1. menyelesaikan sesuatu yang layak untuk dilakukan

2. beriltizam

b) pembetulan bebas

1. menyedari bahawa sesuatu tidak berfungsi

2. betulkan itu

3. beriltizam

Kadang-kadang benda tetap dalam b.2. tidak boleh dipinda kepada komitmen yang tidak cukup sempurna
pembetulan, kerana komitmen itu terkubur secara mendalam dalam siri tampung. Itulah sebenarnya
rebase interaktif adalah untuk: gunakannya selepas banyak "a" dan "b", dengan menyusun semula dan
penyuntingan commit, dan squasing berbilang commit menjadi satu.

Mulakannya dengan komit terakhir yang anda mahu kekalkan seperti sedia ada:

git rebase -i

Editor akan bersemangat dengan semua komit dalam cawangan semasa anda (mengabaikan merge
commits), yang datang selepas commit yang diberikan. Anda boleh menyusun semula komitmen dalam senarai ini kepada
sesuka hati anda, dan anda boleh mengeluarkannya. Senarainya kelihatan lebih kurang seperti ini:

pilih deadbee Satu baris komit ini
pilih fa1afe1 Baris satu komit seterusnya
...

Penerangan satu talian adalah semata-mata untuk kesenangan anda; pergi melunaskan semula tidak akan memandang mereka
tetapi pada nama komit ("deadbee" dan "fa1afe1" dalam contoh ini), jadi jangan padam atau
mengedit nama.

Dengan menggantikan arahan "pilih" dengan arahan "edit", anda boleh memberitahu pergi melunaskan semula untuk menghentikan
selepas menggunakan komit itu, supaya anda boleh mengedit fail dan/atau mesej komit,
pinda komit, dan teruskan asas semula.

Jika anda hanya mahu mengedit mesej komit untuk komit, gantikan arahan "pilih" dengan
arahan "kata semula".

Untuk menggugurkan komit, gantikan arahan "pilih" dengan "jatuhkan", atau hanya padamkan padanan
line.

Jika anda ingin melipat dua atau lebih komit menjadi satu, gantikan arahan "pilih" untuk
komitmen kedua dan seterusnya dengan "skuasy" atau "fixup". Jika komitmen berbeza
pengarang, komit yang dilipat akan dikaitkan dengan pengarang komit pertama. The
mesej komit yang dicadangkan untuk komit yang dilipat ialah gabungan mesej komit
daripada komit pertama dan yang mempunyai arahan "skuasy", tetapi meninggalkan mesej komit
of commit dengan arahan "fixup".

pergi melunaskan semula akan berhenti apabila "pilih" telah digantikan dengan "edit" atau apabila arahan gagal dibayar
untuk menggabungkan ralat. Apabila anda selesai mengedit dan/atau menyelesaikan konflik, anda boleh meneruskan
dengan git rebase --continue.

Sebagai contoh, jika anda ingin menyusun semula 5 komitmen terakhir, supaya apa yang HEAD~4 menjadi
KEPALA yang baru. Untuk mencapai itu, anda akan menghubungi pergi melunaskan semula seperti ini:

$ git rebase -i HEAD~5

Dan alihkan tampung pertama ke penghujung senarai.

Anda mungkin mahu mengekalkan gabungan, jika anda mempunyai sejarah seperti ini:

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

Katakan anda ingin meletakkan semula cawangan sisi bermula dari "A" hingga "Q". Pastikan bahawa
HEAD semasa ialah "B", dan panggil

$ git rebase -i -p --ke QO

Komit penyusunan semula dan penyuntingan biasanya mencipta langkah perantaraan yang belum diuji. Anda mungkin mahu
untuk menyemak sama ada penyuntingan sejarah anda tidak memecahkan apa-apa dengan menjalankan ujian, atau sekurang-kurangnya
menyusun semula pada titik perantaraan dalam sejarah dengan menggunakan arahan "exec" (pintasan "x").
Anda boleh berbuat demikian dengan membuat senarai tugasan seperti ini:

pilih ciri Laksana deadbee XXX
fixup f1a5c00 Betulkan untuk menampilkan XXX
exec buat
pilih c0ffeee Baris satu komit seterusnya
edit deadbab Satu baris komit selepas
exec cd subdir; buat ujian
...

Pangkalan semula interaktif akan berhenti apabila arahan gagal (iaitu keluar dengan status bukan 0) ke
memberi anda peluang untuk menyelesaikan masalah. Anda boleh meneruskan dengan git rebase --continue.

Perintah "exec" melancarkan arahan dalam shell (yang dinyatakan dalam $SHELL, atau
shell lalai jika $SHELL tidak ditetapkan), jadi anda boleh menggunakan ciri shell (seperti "cd", ">", ";"
...). Perintah dijalankan dari akar pokok kerja.

$ git rebase -i --exec "buat ujian"

Perintah ini membolehkan anda menyemak bahawa komit perantaraan boleh dikompilasi. Senarai yang perlu dilakukan
menjadi seperti itu:

pilih 5928aea satu
exec membuat ujian
pilih 04d0fda dua
exec membuat ujian
pilih ba46169 tiga
exec membuat ujian
pilih f4593f9 empat
exec membuat ujian

BERPECAH KOMITED

Dalam mod interaktif, anda boleh menandakan komit dengan tindakan "edit". Walau bagaimanapun, ini tidak
semestinya bermaksud begitu pergi melunaskan semula menjangkakan hasil suntingan ini betul-betul satu komitmen.
Sesungguhnya, anda boleh membuat asal komit, atau anda boleh menambah komitmen lain. Ini boleh digunakan untuk membelah a
komitmen kepada dua:

· Mulakan pangkalan semula interaktif dengan git rebase -i ^, di mana adalah komitmen
anda mahu berpecah. Malah, sebarang julat komit akan berjaya, selagi ia mengandunginya
komited.

· Tandakan komit yang anda mahu belah dengan tindakan "edit".

· Apabila ia datang untuk mengedit komit itu, laksanakan git reset HEAD^. Kesannya ialah
HEAD digulung semula oleh satu, dan indeks mengikutinya. Walau bagaimanapun, pokok kerja kekal
sama.

· Sekarang tambahkan perubahan pada indeks yang anda ingin miliki dalam komit pertama. Awak boleh
gunakan git add (mungkin secara interaktif) atau pergi gui (atau kedua-duanya) untuk melakukannya.

· Komit indeks semasa dengan apa-apa mesej komit yang sesuai sekarang.

· Ulangi dua langkah terakhir sehingga pokok kerja anda bersih.

· Teruskan rebase dengan git rebase --continue.

Jika anda tidak pasti sepenuhnya bahawa semakan pertengahan adalah konsisten (mereka
menyusun, lulus testsuite, dsb.) yang patut anda gunakan pergi tutup untuk menyimpan jauh
perubahan yang belum komited selepas setiap komit, uji dan pindaan komit jika pembetulan dilakukan
perlu.

PULIH DARIPADA UCAPAN REBASE

Mengasaskan semula (atau apa-apa bentuk penulisan semula lain) cawangan yang diusahakan oleh orang lain adalah perkara yang tidak baik
idea: sesiapa di hilirnya terpaksa membetulkan sejarah mereka secara manual. Bahagian ini
menerangkan cara melakukan pembetulan dari sudut pandangan hiliran. Pembaikan sebenar, bagaimanapun,
adalah untuk mengelakkan asas semula huluan di tempat pertama.

Untuk menggambarkan, katakan anda berada dalam situasi di mana seseorang mengembangkan a subsistem cawangan,
dan anda sedang mengusahakan a topik yang bergantung pada ini subsistem. Anda mungkin berakhir dengan
sejarah seperti berikut:

o---o---o---o---o---o---o---o---o tuan
\
o---o---o---o---o subsistem
\
*---*---* topik

If subsistem adalah berdasarkan semula terhadap master, perkara berikut berlaku:

o---o---o---o---o---o---o---o tuan
\ \
o---o---o---o---o o'--o'--o'--o'--o' subsistem
\
*---*---* topik

Jika anda kini meneruskan pembangunan seperti biasa, dan akhirnya bergabung topik kepada subsistem, yang
melakukan daripada subsistem akan kekal disalin selama-lamanya:

o---o---o---o---o---o---o---o tuan
\ \
o---o---o---o---o o'--o'--o'--o'--o'--M subsistem
\ /
*---*---*-..........-*--* topik

Pendua sedemikian biasanya tidak disukai kerana ia mengacaukan sejarah, menjadikannya
lebih sukar untuk diikuti. Untuk membersihkan perkara, anda perlu memindahkan komit pada topik kepada
baru subsistem tip, iaitu, rebase topik. Ini menjadi kesan riak: sesiapa sahaja di hilir
dari topik dipaksa untuk membuat semula juga, dan seterusnya!

Terdapat dua jenis pembetulan, dibincangkan dalam subseksyen berikut:

Kes mudah: Perubahan secara literal adalah sama.
Ini berlaku sekiranya subsistem rebase ialah pangkalan semula yang mudah dan tidak mempunyai konflik.

Kes keras: Perubahan tidak sama.
Ini berlaku sekiranya subsistem rebase mempunyai konflik, atau digunakan --interaktif untuk ditinggalkan,
edit, skuasy, atau fixup commit; atau jika huluan menggunakan salah satu komit --pindaan, tetapkan semula,
atau cawangan penapis.

. mudah kes
Hanya berfungsi jika perubahan (ID tampung berdasarkan kandungan perbezaan) dihidupkan subsistem adalah
betul-betul sama sebelum dan selepas pangkalan semula subsistem lakukan.

Dalam kes itu, pembaikan adalah mudah kerana pergi melunaskan semula tahu melangkau perubahan yang sudah ada
hadir di hulu baru. Jadi jika anda berkata (dengan andaian anda berada di topik)

$ git rebase subsistem

anda akan berakhir dengan sejarah tetap

o---o---o---o---o---o---o---o tuan
\
subsistem o'--o'--o'--o'--o'
\
*---*---* topik

. keras kes
Perkara menjadi lebih rumit jika subsistem perubahan tidak betul-betul sesuai dengan yang
sebelum asas semula.

Nota
Walaupun "pemulihan kes mudah" kadangkala kelihatan berjaya walaupun dalam kesukaran
kes, ia mungkin mempunyai akibat yang tidak diingini. Contohnya, komit yang telah dialih keluar melalui
git rebase --interactive akan menjadi dibangkitkan!

Ideanya adalah untuk memberitahu secara manual pergi melunaskan semula "mana yang lama subsistem berakhir dan anda topik
bermula", iaitu, asas gabungan lama antara mereka. Anda perlu mencari jalan untuk
namakan komit terakhir yang lama subsistem, Contohnya:

· Dengan subsistem reflog: selepas pergi ambil, hujung lama subsistem ada di
subsistem@{1}. Pengambilan seterusnya akan meningkatkan bilangannya. (Lihat git-reflog(1).)

· Berbanding dengan hujung topik: mengetahui bahawa anda topik mempunyai tiga komitmen, tip lama
of subsistem mestilah topik~3.

Anda kemudian boleh memindahkan subsistem lama..topik ke petua baharu dengan mengatakan (untuk reflog
kes, dan dengan andaian anda berada di atas topik sudah):

$ git rebase --ke subsistem subsistem@{1}

Kesan riak pemulihan "kes keras" amat teruk: semua orang hilir dari
topik kini perlu melakukan pemulihan "kes keras" juga!

Gunakan git-rebase dalam talian menggunakan perkhidmatan onworks.net