git squash и сохранить последнюю фиксацию точно

Я получаю конфликты слияния при раздавливании коммитов, и последний коммит заканчивается РАЗЛИЧНЫМ, чем это было до раздавливания. Почему конечный результат меняется, когда я запускаю

git rebase -i someothercommit

затем удалить нежелательные промежуточные коммиты, оставив только первый?? Я не понимаю, как могут возникать конфликты слияния, учитывая, что каждый коммит выполняется последовательно. Более подробная информация приведена ниже:

Для моего рабочего процесса у меня есть несколько веток master 0somefeature 1anotherfeature 2lastfeature

обычно 0feature основан на главном, 1 основан на 0 и т. д., когда я вношу изменения в master, я объединяю master в 0feature, затем 0feature в 1newfeature и т. д.

это то, что я запустил:

$ git log --online -5
990cfb1 combine dump, add prog, combine validate
41013a9 Merge branch '5flash_addr' into 6flash_bankcheck
6f5e8f1 nothing interesting
7b8140d nothing interesting
2347714 implementation of dump and program

$ git rebase -i 2347714

затем я уничтожаю все коммиты, кроме 990cfb1, в итоге возникают конфликты слияния, и мой новый коммит теперь отличается от того, что был до слияния!!

Спасибо!


git workflow squash
person swinman    schedule 12.05.2013    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Слово «удалить» неверно в вашем утверждении «тогда я удаляю все коммиты, кроме 990cfb1». Вам нужно использовать squash.

Когда вы запустите $ git rebase -i 2347714, вы увидите всплывающее окно текстового редактора, показывающее все ваши сообщения, например:

pick 990cfb1 combine dump, add prog, combine validate
pick 41013a9 Merge branch '5flash_addr' into 6flash_bankcheck
pick 6f5e8f1 nothing interesting
pick 7b8140d nothing interesting
pick 2347714 implementation of dump and program

В этот момент я бы сказал НЕ ТРОГАТЬ первый!(990cfb1). Затем для остальных замените «выбрать» на «сквош» или «s» в качестве псевдонима.

Теперь сохраните файл и выйдите из редактора.

Затем git rebase продолжит работу. Через несколько секунд появится другое окно текстового редактора, в котором будут показаны все сообщения фиксации.

В этот момент вы можете безопасно удалить все сообщения и переписать их в одно предложение в качестве окончательного сообщения коммита.

Теперь сохраняйтесь и уходите. Git сделает следующее автоматически. Сделанный!

Примечание

У вас могут возникнуть проблемы с выполнением описанного выше процесса, потому что ваша «перебазировка» уже запущена, но останавливается из-за какой-то ошибки.

Тебе следует:

  1. Сначала сделайте физическую копию всего проекта git в другом месте!!!
  2. Затем запустите git rebase --abort
  3. Начните с чистого состояния, как описано выше.
person Billy Chan    schedule 12.05.2013
comment
на самом деле я удалял строку в интерактивном окне. Если вы удалите строку здесь, THAT COMMIT БУДЕТ ПОТЕРЯН.. - person swinman; 13.05.2013
comment
Спасибо за заметку - жаль, что я не сделал это в бегах, прежде чем я сделал этот пост! - person swinman; 13.05.2013
comment
Мне все еще интересно, почему я получаю так много ошибок и мне приходится вручную выбирать, с какой фиксацией идти? Есть ли способ сказать, всегда выбирать из самой последней фиксации или слияния? В качестве альтернативы, есть ли что-то неправильное в том, как я использую git? - person swinman; 13.05.2013
comment
похоже, что вместо использования git мне было бы лучше создать новую ветку 5somefeature_new из 4other_feature, заменить все файлы, используя файлы в 5somefeature, затем удалить ветку 5somefeature и переименовать 5somefeature_new обратно в старое имя ветки... быть лучшим способом раздавить коммиты!! - person swinman; 13.05.2013
comment
@swinman, рабочий процесс перебазирования в основном предназначен для слияния функциональной ветки с основной или другой основной веткой для развертывания / распространения. При разработке функции вам нужно часто вносить небольшие изменения, но для мастера она должна быть чистой. Вот почему эти небольшие коммиты в функциональной ветке необходимо объединить в одну, прежде чем ветка будет объединена с мастером, как рабочий процесс перебазирования. - person Billy Chan; 13.05.2013
comment
Как это отвечает на вопрос, это просто не так. - person AymenDaoudi; 27.05.2020

arrow_upward
0
arrow_downward

Теперь я стал намного лучше делать это. Основная проблема заключалась в слиянии «старой» ветки с новой, что я делал несколько раз, а затем перемещался по шагам слияния и раздавливал все коммиты. Должна быть проблема с изменением хэша или коммитами, сжатыми не по порядку.

Лучшей практикой было бы перебазировать новую ветку на дополнительную фиксацию в старой ветке, чтобы история коммитов была линейной (вместо слияния H с G).

             0feature    1feature
                |           |
                v           |
A --  B -- C -- D -- H      |
                 \          v
                  E -- F -- G

Другими словами, с приведенной выше схемой, если я сделаю дополнительную фиксацию H на D (что переместит указатель 0feature на H), затем объединим 0feature в 1feature (и сделаю это несколько раз), а затем попытаюсь перебазировать/сжать всю историю между 0feature и 1feature у меня могут возникнуть проблемы. Вместо git checkout G; git merge H я должен был использовать git rebase --onto H D G для каждой маленькой очистки. Я выполнял второй из этих вариантов с момента публикации исходного поста, и с тех пор все было в порядке.

Кроме того, если это был мой журнал коммитов:

990cfb1 combine dump, add prog, combine validate
41013a9 Merge branch '5flash_addr' into 6flash_bankcheck
6f5e8f1 nothing interesting
7b8140d nothing interesting
2347714 implementation of dump and program

и я переустанавливаю 2347714, параметр перебазирования должен выглядеть так:

pick 7b8140d nothing interesting
s 6f5e8f1 nothing interesting
s 41013a9 Merge branch '5flash_addr' into 6flash_bankcheck
s 990cfb1 combine dump, add prog, combine validate
person swinman    schedule 18.06.2013