Вытащить все коммиты из ветки, перенаправить указанные коммиты в другую

У меня есть следующие ветки:

  • master
  • production

и следующие удаленные ветки:

  • origin/master
  • origin/production

У меня есть сценарий, который извлекает ветку origin/master и получает различие того, что изменилось из моей последней выборки (log -p master..origin/master). Потом сливаю origin/master.

Найденные коммиты отправляются в инструмент проверки кода.

Я хочу отправить успешные коммиты - и только их - в производственную ветку, а затем, конечно, в origin/production.

Как я могу это сделать?

Кроме того, у меня запущено 2 сценария: один, который извлекает из origin/master, передает детали в базу данных и объединяет, а другой, который я сейчас пишу, должен будет подтолкнуть успешные коммиты.

Я бы хотел, чтобы эти 2 сценария работали, избегая при этом состояния гонки / конфликта слияния. Поскольку я хочу работать только с указанными коммитами, может быть, есть способ избавиться от коммитов, которые мне не нужны?


git branch
person Sylvain    schedule 19.05.2009    source источник
comment
Что вы имеете в виду под «успешными коммитами»?   -  person bdonlan    schedule 19.05.2009
comment
тот, который был рассмотрен и отмечен как успешный. здесь это не имеет особого значения, важно то, что есть коммиты, которые я хочу сохранить и переместить в другую ветку, и другие, от которых я хочу избавиться / игнорировать.   -  person Sylvain    schedule 19.05.2009

Ответы (2)


arrow_upward
327
arrow_downward

Я думаю, вы ищете термин «вишневый выбор». То есть возьмите одну фиксацию из середины одной ветки и добавьте ее в другую:

A-----B------C
 \
  \
   D

становится

A-----B------C
 \
  \
   D-----C'

Это, конечно, можно сделать с помощью команды git cherry-pick.

Проблема с этим коммитом в том, что git считает, что коммиты включают всю предшествующую им историю - таким образом, если у вас есть три таких коммита:

A-----B-----C

И попробуйте избавиться от B, вам нужно создать совершенно новый коммит, например:

A-----------C'

Где C 'имеет другой идентификатор SHA-1. Точно так же Cherry выбор фиксации из одной ветки в другую в основном включает в себя создание патча, а затем его применение, что также приводит к потере истории.

Это изменение идентификаторов коммитов, помимо прочего, нарушает функциональность слияния git (хотя при умеренном использовании есть эвристика, которая устранит это). Что еще более важно, он игнорирует функциональные зависимости - если C действительно использовал функцию, определенную в B, вы никогда не узнаете.

Возможно, лучший способ справиться с этим - иметь более мелкозернистые ветки. То есть, вместо того, чтобы просто иметь 'master', иметь 'featureA', 'bugfixB' и т. Д. Выполняйте проверку кода для всей ветки за раз - где каждая ветка очень сосредоточена на выполнении только одной задачи - а затем объедините это одна ветка, когда вы закончите. Это рабочий процесс, для которого предназначен git, и в чем он хорош :)

Если вы настаиваете на работе с вещами на уровне патчей, вы можете посмотреть на darcs - он рассматривает репозиторий как набор патчей, и, таким образом, выбор вишни становится фундаментальной операцией. Однако у этого есть свой набор проблем, например, очень медленный :)

Изменить: Кроме того, я не уверен, что понимаю ваш второй вопрос о двух скриптах. Может быть, вы могли бы описать это более подробно, возможно, как отдельный вопрос, чтобы не запутаться?

person bdonlan    schedule 19.05.2009
comment
Что касается моего второго вопроса, я просто хочу убедиться, что процессы получения изменений (1-й сценарий) и отправка заданных коммитов в другое место (2-й сценарий) могут работать без состояния гонки / конфликта слияния при работе с разными ветвями. Но, в конце концов, я думаю, это не имеет значения, так как я мог объединить 2 сценария в один, чтобы 2 сценария не работали одновременно :) - person Sylvain; 19.05.2009
comment
Это изменение идентификаторов коммитов, помимо прочего, нарушает функциональность слияния git @bdonlan, пожалуйста, объясните, как тормозится функциональность слияния. Что это значит? - person Narek; 19.09.2013
comment
@Narek Он, вероятно, имеет в виду, что изменения в фиксации C 'будут конфликтовать с такими же изменениями в фиксации C, когда вы объедините вторую ветвь. Это следствие потери истории за коммитом C. - person bytefu; 18.11.2013
comment
И попробуйте избавиться от B - почему вы пытаетесь избавиться от B? - person d512; 22.02.2015
comment
@ user1334007, он имеет ввиду, что раньше это были A-B-C. Теперь, из-за того, что вы выбрали C, ваша ветка A-D-C ', которая больше не содержит' B '. - person AnneTheAgile; 10.04.2015
comment
Насколько я понимаю, C 'не будет включать фактические изменения из B. Таким образом, после выбора вишни B не будет отображаться в истории ветки, И изменения в B не появятся в C'. Однако сегодня я сделал c-p, и у меня возникают конфликты слияния. Когда я пытаюсь разрешить слияние, я вижу изменения из B в C '(тот же файл был изменен в B и C). Это ожидаемое поведение? Должен ли он пытаться вытащить изменения из B в C ', где тот же файл был изменен в B и C? Я этого не ожидал, но похоже, что так оно и есть. Я хотел бы понять, что делает git под капотом при запуске Cherry-Pick. - person CodeClimber; 10.11.2016
comment
У нас есть главная ветка и ветки выпуска. Если в ветке выпуска есть ошибка, мы исправляем ее и снова объединяем с мастером. Нет проблем, но что, если нам нужно применить это исправление к нескольким веткам выпуска. Тогда есть ли альтернатива сбору вишен? - person Christian Rapp; 14.09.2020

arrow_upward
1
arrow_downward

Я понимаю, что это старый вопрос, но он упоминается здесь: Как объединить конкретный коммит в Git

Следовательно, новый ответ: используйте функциональные ветки и запросы на вытягивание.

Как это выглядит, где fA - это фиксация с функцией A, а fB - это фиксация с функцией B:

            fA   fC (bad commit, don't merge)
           /  \ /
master ----A----B----C
                \  /
                 fB

Запросы на вытягивание связаны с функциональностью GitHub, но на самом деле я имею в виду только то, что кто-то несет ответственность за объединение веток функций в master.

person MattJenko    schedule 25.06.2015