Можно ли рекомендовать запрос слияния / вытягивания после того, как что-то было возвращено в состояние ранее? [Дубликат]
Это просто и работает:
let item = {
firstName: 'Jonnie',
lastName: 'Walker',
fullName: function fullName() {
return 'Jonnie Walker';
}
Object.assign(Object.create(item), item);
Объясните:
Object.create() Создает новый объект. Если вы передадите параметры для работы, он создаст объект с прототипом другого объекта. Поэтому, если у вас есть какие-либо функции на прототипе объекта, они будут переданы прототипу другого объекта.
Object.assign() Объединяет два объекта и создает полностью новый объект, и у них больше нет ссылки. Так что этот пример хорошо работает для меня.
6 ответов
Вы должны «вернуть реверс». В зависимости от того, как вы это сделали, это может быть не так просто, как кажется. Посмотрите официальный документ на эту тему .
---o---o---o---M---x---x---W---x---Y
/
---A---B-------------------C---D
, чтобы разрешить:
---o---o---o---M---x---x-------x-------*
/ /
---A---B-------------------C---D
Но все ли работает? Конечно. Вы можете вернуть слияние, и с чисто технического ранга git сделал это очень естественно и не имел реальных проблем. Он просто считал это изменением от «состояния до слияния» до «состояния после слияния», и все. Ничего сложного, ничего странного, ничего действительно опасного. Гит сделает это, даже не подумав об этом.
Итак, с технической точки зрения, нет ничего плохого в возврате слияния, но из угла рабочего процесса это то, что вы обычно должны избегать.
Если возможно, например, если вы обнаружили проблему, которая была объединена с основным деревом, а не вернула слияние, попробуйте really трудно:
- делите проблему на ветку, которую вы объединили, и просто исправьте ее,
- или попытайтесь вернуть индивидуальную фиксацию, вызвавшую ее.
Да, это больше сложный, и нет, это не всегда будет работать (иногда ответ: «oops, я действительно не должен был сливать его, потому что он еще не был готов, и мне действительно нужно отменить все слияния "). Итак, вы действительно должны вернуть слияние, но если вы хотите повторно выполнить слияние, вам нужно сделать это, возвращая возврат.
-
1Хорошая ссылка (+1). Я взял на себя смелость скопировать часть документа в свой ответ, чтобы позволить читателям сразу увидеть соответствующие варианты в этом случае. Если вы не согласны, не стесняйтесь возвращаться. – VonC 3 July 2009 в 12:00
-
2Мы просто столкнулись с тем случаем, когда нам нужно было это сделать, и обнаружили, что здесь не совсем весело. Это была длинная ветка, которая была объединена, поэтому нам нужно было продолжать ее обновлять. Мой подход здесь: tech.patientslikeme.com/2010/09/29/… – jdwyah 29 September 2010 в 16:07
-
3Я следил за сообщением @ jdwyah в блоге, и это было великолепно (серьезно, это было потрясающе, что он просто сработал). – hellatan 20 August 2013 в 22:52
-
4@jdwyah, который кажется сломанной ссылкой, но это звучит как интересное чтение. Вот зеркало archive.org, но в нем отсутствуют изображения: web.archive.org/web/20111229193713/http://… – Alex KeySmith 17 June 2014 в 16:44
-
5Сообщение в блоге было воскрешено, спасибо: blog.jdwyah.com/2015/07/dealing-with-git-merge-revisions.html – jdwyah 7 July 2015 в 19:36
Вместо использования git-revert вы могли бы использовать эту команду в ветви devel, чтобы отбросить (отменить) неправильное коммитирование (вместо того, чтобы просто вернуть его).
git checkout devel
git reset --hard COMMIT_BEFORE_WRONG_MERGE
также соответствующим образом отрегулирует содержимое рабочего каталога. Будьте осторожны:
- Сохраните изменения в ветви разработки (с неправильного слияния), потому что они тоже будут удалены
git-reset. Все коммиты после того, что вы укажете в качестве аргументаgit reset, исчезнут! - Кроме того, не делайте этого, если ваши изменения уже были вытащены из других репозиториев, потому что сброс будет перезаписывать историю.
Я рекомендую внимательно изучить man-страницу git-reset, прежде чем пытаться это сделать.
Теперь, после сброса, вы можете повторно применить свои изменения в devel, а затем сделать
git checkout devel
git merge 28s
Это будет реальное слияние из 28s в devel, как и исходное (которое теперь стерлось из истории git).
-
1Для тех, кто не очень хорошо знаком с git и может захотеть следовать этим инструкциям: тщательно с сочетанием
reset --hardиpush origin. Также имейте в виду, что силовой толчок к происхождению может действительно замалчивать открытые PR на GitHub. – funroll 7 July 2014 в 22:21 -
2Очень полезно для исправления некоторых проблем с объединением на частном git-сервере. Благодаря! – mix3d 25 June 2015 в 15:20
-
3– njzk2 8 August 2016 в 17:28
-
4+1 для этой техники. Потенциально разрушительный, но может сэкономить вам много головной боли (и искаженной истории) при разумном применении. – siliconrockstar 25 May 2017 в 20:34
Я только что нашел этот пост, столкнувшись с той же проблемой. Я нахожу выше, чем страшно, чтобы сбросить лишние вещи и т. Д. Я в конечном итоге удалю то, чего я не хочу, и не смогу вернуть его.
Вместо этого я проверил фиксацию, я хотел, чтобы ветка вернулась к, например, git checkout 123466t7632723. Затем преобразуется в ветвь git checkout my-new-branch. Затем я удалил ветку, в которой я больше не хотел. Конечно, это будет работать, только если вы сможете выбросить ветку, которую вы испортили.
-
1
git reflogзащитит вас от жесткого сброса в течение нескольких месяцев, если вы позже обнаружите, что вам нужны потерянные коммиты. Reflog ограничен вашим местным репо. – Todd 5 January 2018 в 23:32
Чтобы вернуться назад:
git revert <commit-hash-of-previous-revert>
Чтобы вернуться назад, не слишком сильно закручивая рабочий процесс:
- Создайте локальную копию мусора для разработки
- Верните реверт фиксации на локальную копию разработки
- Слейте эту копию в свою ветку функций и нажмите на свою ветку функций на свой сервер git.
Теперь ваша ветка функций должна быть объединена, как обычно, готов к этому. Единственным недостатком здесь является то, что у вас будет несколько дополнительных слияний / повторов в вашей истории.