Восстановление вернувшегося слияния в Мерзавце
list_methods - генерирует методы для добавления, удаления, подсчета и содержит для списка
public void add${listname}(${listtype} toAdd){
get${listname}s().add(toAdd);
}
public void remove${listname}(${listtype} toRemove){
get${listname}s().remove(toRemove);
}
public ${listtype} get${listname}(int index){
return get${listname}s().get(index);
}
public int get${listname}Count(){
return get${listname}s().size();
}
public boolean contains${listname}(${listtype} toFind){
return get${listname}s().contains(toFind);
}
${cursor}
id - вставляет аннотации, импорт, поле и получатель для простого JPA @Id
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
public Long getId(){
return id;
}
${cursor}
${:import (javax.persistence.GenerationType,javax.persistence.GeneratedValue,javax.persistence.Id)}
2 ответа
Вы должны «отменить возврат». В зависимости от того, как был восстановлен исходный файл, это может быть не так просто, как кажется. Посмотрите официальный документ по этой теме .
---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 сделал это очень естественно и не имел неприятности.
Он просто посчитал это изменением с «состояния до слияния» на «состояние после слияния», вот и все.
Ничего сложного, ничего лишнего, ничего особо опасного. Git сделает это, даже не задумываясь об этом.Итак, с технической точки зрения, нет ничего плохого в отмене слияния, но с точки зрения рабочего процесса это то, что вам обычно следует попробовать избегайте .
Если возможно, например, если вы обнаружите проблему, которая была объединена в главное дерево, вместо того, чтобы отменять слияние, попробуйте действительно усердно :
- разделите проблему пополам на ветку, которую вы слили, и просто исправьте ее,
- или попробуйте отменить отдельную фиксацию, которая ее вызвала.
Да, это более сложно, и нет, это не всегда будет работать (иногда ответ: "Ой, мне действительно не следовало объединять это, потому что это не готово, и мне действительно нужно отменить все слияния "). Тогда вы действительно следует отменить слияние, но когда вы хотите повторно выполнить слияние, вы теперь нужно сделать это, отменив откат.
Вместо использования git-revert вы могли бы использовать эту команду в ветке devel , чтобы выбросить (отменить) неправильная фиксация слияния (вместо того, чтобы просто отменить его).
git checkout devel
git reset --hard COMMIT_BEFORE_WRONG_MERGE
Это также соответствующим образом скорректирует содержимое рабочего каталога. Будьте осторожны :
- Сохраните свои изменения в ветке разработки (из-за неправильного слияния), потому что они
также будет удален командой
git-reset. Все коммиты после того, что вы указали как аргументgit resetисчезнет! - Кроме того, не делайте этого, если ваши изменения уже были извлечены из других репозиториев потому что сброс перезапишет историю.
Я рекомендую внимательно изучить справочную страницу git-reset , прежде чем пытаться это сделать.
Теперь, после сброса, вы можете повторно применить свои изменения в ] devel , а затем
git checkout devel
git merge 28s
. Это будет реальное слияние 28s в devel , подобное исходному (которое сейчас
стерто из истории git).