Сделал ошибку с Git
У нас есть 3 релиза: 4.0.3, 4.0.4 и 4.0.5. Когда я создавал новую ветку, я случайно взял ее из 4.0.5, где должен был взять 4.0.4. Вот графическое представление этого случая от TortoiseGit. Я создал ветку release_4_0_4_new и хочу включить все изменения с этого момента в этот выпуск. Как мне это сделать?
Ответы 2
Вам нужно перебазировать ветку:
git checkout -f yourFeatureBranch
git rebase release-4.0.5 --onto=release-4.0.4
# if conflict appears:
git mergetool # resolve it
git rebase --continue # to continue rebase after conflict resolution
git push --force-with-lease
В git rebase первый аргумент указывает, с какой ветки был запущен barnch. --onto= указывает, откуда должна начинаться ваша функциональная ветка.
Только git push --force-with-lease может привести к ошибкам аутентификации. Но когда вы достигли этого шага, вы можете сделать push-форму, которую вы git Frontend UI. Я не использую GitKraken или TortoiseGit. В Windows я использую GitExtenstions — отличный инструмент, но я все же предпочитаю командную строку, так как точно знаю, как она работает. Я использую UI-интерфейсы в качестве инструментов визуализации.
Это публичная ветка? Поскольку перебазирование общедоступной ветки является смертным грехом в Git... вы можете в конечном итоге испортить локальные репозитории всех остальных пользователей.
@DanK он объясняет, что у него активны 3 ветки релиза, и создает новую ветку, начиная с одной из веток релиза. Я думаю, что это хорошее предположение, что это функциональная ветка (используемая только им во время разработки).
Достаточно справедливо, но в этот момент я думаю, что было бы проще просто откатить главный коммит и применить изменения как новый коммит в правильной ветке. Но это я... Перебазирование всегда вызывает у меня дискомфорт, так как так легко уничтожить вашу историю.
@DanK, вы никогда ничего не «испортите», и это лишь небольшая проблема, если вы не работаете с большим количеством людей, которые не знают, что они делают. И, чем раньше вы это сделаете, тем меньше проблем это вызовет!
@hobbs Мне придется с уважением, но категорически с вами не согласиться. Когда вы перебазируете, под капотом вы переназначаете родительские адреса sha-1, содержащиеся в ваших коммитах. Это коренным образом меняет историю в вашем базовом графике, и при выполнении общих коммитов может нарушить непрерывность в другом месте вашего репо. Учитывая, что единственной целью системы контроля версий является отслеживание истории разработки, эта сила должна дать паузу. Rebase абсолютно имеет свое место, но его не следует использовать легкомысленно. Неправильное перебазирование может свести на нет возможность точно установить вину git или git diff в будущем.
@DanK Я не призываю делать что-либо «неправильно». Я говорю, что вы не должны бояться делать это должным образом в таких случаях, когда это очевидно правильный и очевидно выгодный способ предоставить полезную и точную историю. Не подменяйте страхом реальные размышления о результатах (хороших и плохих) того или иного действия.
Итак, сначала хорошие новости, это полностью поправимо. Плохая новость заключается в том, что на этом этапе вам нужно выйти из любой программы с графическим интерфейсом, которую вы используете для взаимодействия с системой управления версиями, и положиться на консоль Git для исправления ваших веток.
Предполагая, что вы уже отправили неправильные изменения в свой общедоступный репозиторий, вам больше не следует перебазировать свою проблемную ветку... это может испортить локальный репозиторий любого другого разработчика.
Исправление неправильной ветки
Чтобы безопасным образом исправить ветку, к которой вы неправильно применили свои изменения, вы должны вручную вручную откатить свои изменения локально, а затем отправить новый коммит «отредактированный код». Имейте в виду, что это не должно быть так сложно, как вы можете напрямую git checkout хэш-идентификатор sha-1 коммита до внесения проблемных изменений, которые вы применили, скопируйте код в другое место, повторно извлеките проблемную ветку, а затем перезапишите свой рабочий каталог с помощью откатной код.
Применение ваших изменений к правильной ветке
Для вашей новой ветки вы можете сделать пару вещей. Предполагая, что у вас есть исходный код, вы можете просто проверить ветку, которую вы хотели отправить, и применить изменения как новую фиксацию.
В качестве альтернативы вы можете поэкспериментировать с командой git cherrypick, чтобы получить коммиты, которые вы хотели применить к ветке, к которой вы хотели зафиксировать. Имейте в виду, однако, что, поскольку история коммитов строится на предыдущих коммитах, если ваша проблемная ветка содержала какие-либо правки, которые вам не нужны в правильной ветке, то они тоже попадут при выборе вишенки в вашу правильную ветку. Таким образом, создание нового коммита может быть самым безопасным путем для применения ваших изменений.
Я решил создать новую ветку с того места, где я знаю, что все хорошо, и выбрал все изменения. Это было 2 часа работы, но я уверен, что теперь все в порядке. Спасибо за понимание Дэн.
Обычно я использую GitKraken для работы с GIT, который автоматически регистрирует меня, но в командном терминале я получаю ошибки аутентификации.