Скасування бази git

Хто-небудь знає, як легко відмінити git rebase?

Єдиний спосіб, який спадає на думку, це перейти до цього вручну:

• git checkout батьків прихильності до обох гілок
• потім створіть звідти тимчасову гілку
• вишні вибирайте всі вручну
• замініть гілку, в якій я переобладнаний, створеною вручну гілкою

У моїй теперішній ситуації це буде спрацьовувати, тому що я можу легко помітити комітети з обох гілок (одна була моїми матеріалами, а інша - моїми колегами).

Однак мій підхід вважає мене як неоптимальний і схильний до помилок (скажімо, я щойно переосмислив 2 власні гілки).

Будь-які ідеї?

Уточнення: я говорю про ребауз, під час якого було повторено купу комітетів. Не лише один.

Найпростішим способом було б знайти керівник філії відділення, як це було безпосередньо перед початком роботи рефералу в рефлогу ...

git reflog

і відновити поточну гілку до неї (із звичайними застереженнями щодо того, щоб бути абсолютно впевненим перед тим, як повторно налаштувати --hardпараметр).

Припустимо, старий фіксатор був HEAD@{5}у журналі ref:

git reset --hard HEAD@{5}

У Windows вам може знадобитися цитувати посилання:

git reset --hard "HEAD@{5}"

Ви можете перевірити історію старого голови кандидата, просто виконавши git log HEAD@{5}( Windows git log "HEAD@{5}" :).

Якщо ви не відключили кожну відгалуження гілки, ви повинні мати можливість просто зробити git reflog branchname@{1}так, як база даних від'єднує головку гілки перед повторним приєднанням до кінцевої заголовка. Я б ще раз перевірив це, хоча, як це нещодавно не підтвердив.

За замовчуванням всі відхилення активуються для неочищених сховищ:

[core]
    logAllRefUpdates = true

Власне, база даних зберігає вашу вихідну точку, ORIG_HEADтому це, як правило, так просто, як:

git reset --hard ORIG_HEAD

Однак reset, rebaseі mergeвсе , крім вихідного HEADпокажчика в ORIG_HEADтак, якщо ви зробили будь - якого з цих команд з Rebase ви намагаєтеся скасувати , то ви повинні будете використовувати reflog.

Відповідь Чарльза працює, але ви можете зробити це:

git rebase --abort

прибирати після reset.

В іншому випадку ви можете отримати повідомлення " Interactive rebase already started".

Перезавантаження гілки на об'єкт, що звисає, виконувати старий наконечник - це, звичайно, найкраще рішення, оскільки воно відновлює попередній стан, не витрачаючи жодних зусиль. Але якщо ви втратили ці комісії (f.ex. тому, що тим часом ви зібрали сміття зі свого сховища або це свіжий клон), ви завжди можете знову відновити гілку. Ключ до цього - --ontoперемикач.

Скажімо, у вас була тематично названа галузь теми topic, яку ви розгалужували, masterколи вістрям masterбуло 0deadbeefвиконано. У якийсь момент, перебуваючи на topicгілці, ти це зробив git rebase master. Тепер ви хочете скасувати це. Ось як:

git rebase --onto 0deadbeef master topic

Це займе всі комітети, на topicяких не ввімкнено, masterі повторити їх поверх 0deadbeef.

З цим --ontoви можете переставити свою історію в майже будь-яку форму .

Весело. :-)

Я фактично ставлю тег резервного копіювання на гілку перед тим, як робити будь-яку нетривіальну операцію (більшість повторних баз є тривіальною, але я б це зробив, якщо це виглядає де-небудь складним).

Тоді відновити так само просто git reset --hard BACKUP.

У випадку, якщо ви відсунули свою філію у віддалений сховище (зазвичай це походження), а потім ви виконали успішне ребазування (без злиття) ( git rebase --abortдає "Без перезавантаження не працює "), ви можете легко скинути гілку за допомогою команди:

git reset - жорстке походження / {відділенняName}

Приклад:

$ ~/work/projects/{ProjectName} $ git status
On branch {branchName}
Your branch is ahead of 'origin/{branchName}' by 135 commits.
  (use "git push" to publish your local commits)

nothing to commit, working directory clean

$ ~/work/projects/{ProjectName} $ git reset --hard origin/{branchName}
HEAD is now at 6df5719 "Commit message".

$ ~/work/projects/{ProjectName} $ git status
On branch {branchName}
Your branch is up-to-date with 'origin/{branchName}.

nothing to commit, working directory clean

Використання reflog не працювало для мене.

Те, що працювало для мене, було схожим на описане тут . Відкрийте файл у .git / logs / refs з назвою гілки, яка була повторно базована, і знайдіть рядок, що містить "завершене оновлення", як-от:

5fce6b51 88552c8f Kris Leech <me@example.com> 1329744625 +0000  rebase finished: refs/heads/integrate onto 9e460878

Оформити другу комісію, вказану на рядку.

git checkout 88552c8f

Після того, як це підтвердилось, що у мене були втрачені зміни, я розгалужився і полегшено зітхнув.

git log
git checkout -b lost_changes

Для кількох комітетів пам’ятайте, що будь-які комісії посилаються на всю історію, що веде до цього коміту. Тож у відповіді Чарльза читайте "старий поступ" як "найновіший із старих домовленостей". Якщо ви скинетеся на цю команду, то вся історія, що веде до цього введення, знову з’явиться. Це має робити те, що ви хочете.

Після рішення @Allan та @Zearin, я хотів би просто зробити коментар, але мені не вистачає репутації, тому я використав таку команду:

Замість того щоб робити git rebase -i --abort (зверніть увагу на -i ) я повинен був просто зробити git rebase --abort( без -i ).

Використання обох -iі --abortодночасно змушує Git показати мені список використання / варіантів.

Отже, мій попередній та поточний статус філії з цим рішенням:

matbhz@myPc /my/project/environment (branch-123|REBASE-i)
$ git rebase --abort

matbhz@myPc /my/project/environment (branch-123)
$

Якщо ви успішно відмовились від віддаленого відділення і не можете, git rebase --abortви все одно можете зробити кілька хитрощів, щоб зберегти свою роботу і не маєте вимушених натискань. Припустимо, ваша поточна галузь, яка була перезавантажена помилково, називається your-branchі відстежуєorigin/your-branch

• git branch -m your-branch-rebased # перейменувати поточну гілку
• git checkout origin/your-branch # замовлення до останнього стану, за яким відомо, що походить
• git checkout -b your-branch
• перевірити git log your-branch-rebased, порівняти git log your-branchта визначити комітети, яких немаєyour-branch
• git cherry-pick COMMIT_HASH для кожного вчинення в your-branch-rebased
• натисніть на зміни. Зауважте, що два локальні відділення пов’язані з remote/your-branchвами, і вам слід лише натиснутиyour-branch

Скажімо, я перезавантажую майстер до своєї функції, і я отримую 30 нових комітетів, які щось порушують. Я виявив, що часто найпростіше просто усунути погані порушення.

git rebase -i HEAD~31

Інтерактивна база даних за останні 31 комітет (не зашкодить, якщо ви виберете занадто багато).

Просто візьміть комітети, яких ви хочете позбутися, і позначте їх "d" замість "pick". Тепер комісії видаляються, фактично скасовуючи ребазу (якщо ви видаляєте лише ті зобов’язання, які ви отримали під час перезавантаження).

Для новачків / тих, хто занадто боїться зробити жорсткий перезавантаження, ви можете взяти на себе зобов’язання з рефлогу, а потім зберегти його як нову гілку.

git reflog

Знайдіть комісію безпосередньо перед тим, як розпочати випуск. Вам може знадобитися прокрутити далі вниз, щоб знайти його (натисніть Enter або PageDown). Зверніть увагу на номер HEAD та замініть 57:

git checkout HEAD@{57}

Перегляньте відділення / зобов’язання, якщо це добре виглядає, створіть нову гілку за допомогою цієї HEAD:

git checkout -b new_branch_name

Якщо ви знаходитесь у відділенні, ви можете використовувати:

git reset --hard @{1}

Існує не лише довідковий журнал для HEAD (отриманий git reflog), також є рефлоги для кожної гілки (отримані користувачем git reflog <branch>). Тож, якщо ви перебуваєте в masterтакому режимі, ви git reflog masterпобачите всі зміни до цієї гілки. Ви можете звернутися до того , що зміни з боку master@{1}, master@{2}і т.д.

git rebase зазвичай змінюється HEAD кілька разів, але поточна гілка буде оновлена ​​лише один раз.

@{1}це просто ярлик для поточної гілки , тож це дорівнює, master@{1}якщо ви перебуваєте в master.

git reset --hard ORIG_HEADне працюватиме, якщо ви використовувались git resetпід час інтерактивної роботи rebase.

Що я зазвичай роблю git reset #commit_hash

до останнього зобов’язання, де я думаю, що база даних не мала ефекту.

тоді git pull

Тепер ваша філія повинна відповідати точно так само, як і майстри, а переоформлені комісії не повинні знаходитись у ній.

Тепер ви можете просто вибрати вишні на цій гілці.

Я спробував усі пропозиції зі скиданням та відхиленням без успіху. Відновлення місцевої історії IntelliJ вирішило проблему втрачених файлів

git reset - жорстке походження / {відділенняName}

- це правильне рішення для скидання всіх локальних змін, здійснених шляхом перезавантаження.

Якщо ви щось зіпсуєте в рамках git rebase, наприклад git rebase --abort, поки у вас є непослані файли, вони втратяться і git reflogне допоможуть. Це сталося зі мною, і вам тут потрібно буде подумати поза межами. Якщо вам пощастило, як я, і використовуєте IntelliJ Webstorm, ви можете right-click->local historyі можете повернутись до попереднього стану свого файлу / папок незалежно від помилок, які ви зробили з версією програмного забезпечення. Завжди добре проводити чергову несправність.