Вопросы Теги

Предыдущий git revert - удаление файлов в новом слиянии [duplicate]

Вот неизменная (не изменяющая входы) версия ответа @ Салакара. Полезно, если вы делаете материал типа функционального программирования. 

export function isObject(item) {
  return (item && typeof item === 'object' && !Array.isArray(item));
}

export default function mergeDeep(target, source) {
  let output = Object.assign({}, target);
  if (isObject(target) && isObject(source)) {
    Object.keys(source).forEach(key => {
      if (isObject(source[key])) {
        if (!(key in target))
          Object.assign(output, { [key]: source[key] });
        else
          output[key] = mergeDeep(target[key], source[key]);
      } else {
        Object.assign(output, { [key]: source[key] });
      }
    });
  }
  return output;
}
159
задан Scott Weldon 11 October 2016 в 16:11
поделиться

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, я действительно не должен был сливать его, потому что он еще не был готов, и мне действительно нужно отменить все слияния "). Итак, вы действительно должны вернуть слияние, но если вы хотите повторно выполнить слияние, вам нужно сделать это, возвращая возврат.

128
ответ дан VonC 18 August 2018 в 07:37
поделиться
  • 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).

2
ответ дан knweiss 18 August 2018 в 07:37
поделиться
  • 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

Предположим, что у вас есть такая история 

---o---o---o---M---W---x-------x-------*
              /                      
      ---A---B

Где A, B не удалось выполнить, а W - вернуть M

Итак, прежде чем я начну исправлять найденные проблемы, выберите W commit моей ветви 

git cherry-pick -x W

Затем я вернусь к W commit на моей ветке 

git revert W

После того, как я смогу продолжить исправление.

Последняя история может выглядеть так: 

---o---o---o---M---W---x-------x-------*
              /                       /     
      ---A---B---W---W`----------C---D

Когда я отправляю PR, это ясно показывает, что PR отменяет возврат и добавляет новые коммиты.

33
ответ дан Maksim Kotlyar 18 August 2018 в 07:37
поделиться
  • 1
    Это похоже на то, что это может быть полезно, но настолько детализировано в деталях (что такое C, D на последней диаграмме), что это более неприятно, чем полезно – Isochronous 29 June 2016 в 15:17
  • 2
    @Isochronous C и D, похоже, являются фиксациями, которые фиксируют проблемы, введенные A и B. – Thomas 6 July 2017 в 12:57
  • 3
    @Thomas точно – Maksim Kotlyar 6 July 2017 в 16:02

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

Вместо этого я проверил фиксацию, я хотел, чтобы ветка вернулась к, например, git checkout 123466t7632723. Затем преобразуется в ветвь git checkout my-new-branch. Затем я удалил ветку, в которой я больше не хотел. Конечно, это будет работать, только если вы сможете выбросить ветку, которую вы испортили.

1
ответ дан Nicola 18 August 2018 в 07:37
поделиться
  • 1
    git reflog защитит вас от жесткого сброса в течение нескольких месяцев, если вы позже обнаружите, что вам нужны потерянные коммиты. Reflog ограничен вашим местным репо. – Todd 5 January 2018 в 23:32

Чтобы вернуться назад: 

git revert <commit-hash-of-previous-revert>
0
ответ дан Richard 18 August 2018 в 07:37
поделиться

Чтобы вернуться назад, не слишком сильно закручивая рабочий процесс:

  • Создайте локальную копию мусора для разработки
  • Верните реверт фиксации на локальную копию разработки
  • Слейте эту копию в свою ветку функций и нажмите на свою ветку функций на свой сервер git.

Теперь ваша ветка функций должна быть объединена, как обычно, готов к этому. Единственным недостатком здесь является то, что у вас будет несколько дополнительных слияний / повторов в вашей истории.

4
ответ дан Sam Dufel 18 August 2018 в 07:37
поделиться
Другие вопросы по тегам:

Похожие вопросы: