Это просто и работает:
let item = {
firstName: 'Jonnie',
lastName: 'Walker',
fullName: function fullName() {
return 'Jonnie Walker';
}
Object.assign(Object.create(item), item);
Объясните:
Object.create()
Создает новый объект. Если вы передадите параметры для работы, он создаст объект с прототипом другого объекта. Поэтому, если у вас есть какие-либо функции на прототипе объекта, они будут переданы прототипу другого объекта.
Object.assign()
Объединяет два объекта и создает полностью новый объект, и у них больше нет ссылки. Так что этот пример хорошо работает для меня.
Вы должны «вернуть реверс». В зависимости от того, как вы это сделали, это может быть не так просто, как кажется. Посмотрите официальный документ на эту тему .
---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, я действительно не должен был сливать его, потому что он еще не был готов, и мне действительно нужно отменить все слияния "). Итак, вы действительно должны вернуть слияние, но если вы хотите повторно выполнить слияние, вам нужно сделать это, возвращая возврат.
blockquote>
Вместо использования 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).
reset --hard
и push origin
. Также имейте в виду, что силовой толчок к происхождению может действительно замалчивать открытые PR на GitHub.
– funroll
7 July 2014 в 22:21
Я только что нашел этот пост, столкнувшись с той же проблемой. Я нахожу выше, чем страшно, чтобы сбросить лишние вещи и т. Д. Я в конечном итоге удалю то, чего я не хочу, и не смогу вернуть его.
Вместо этого я проверил фиксацию, я хотел, чтобы ветка вернулась к, например, git checkout 123466t7632723
. Затем преобразуется в ветвь git checkout my-new-branch
. Затем я удалил ветку, в которой я больше не хотел. Конечно, это будет работать, только если вы сможете выбросить ветку, которую вы испортили.
git reflog
защитит вас от жесткого сброса в течение нескольких месяцев, если вы позже обнаружите, что вам нужны потерянные коммиты. Reflog ограничен вашим местным репо.
– Todd
5 January 2018 в 23:32
Чтобы вернуться назад:
git revert <commit-hash-of-previous-revert>
Чтобы вернуться назад, не слишком сильно закручивая рабочий процесс:
Теперь ваша ветка функций должна быть объединена, как обычно, готов к этому. Единственным недостатком здесь является то, что у вас будет несколько дополнительных слияний / повторов в вашей истории.