как для релизов управления версиями с git

Question

У меня есть небольшой побочный проект, поддерживающий его контроль версий с Git. Термин контроль версии здесь относится к его простейшей форме, которую вы можете себе представить: , производя коммит один за другим только на ведущей ветке и в конце дня, нажимая все фиксации на удаленный. Пока все хорошо. Достаточно было иметь только ведущую ветку, потому что последнее состояние приложения требовалось все время.

Тогда продавец сообщил мне, что им нужны версии 1.1 и v1.2. Проблема в том, что последняя комманда-хозяин содержит все вещи для v1.1 и некоторые неустановленные вещи для v1.2.

Мое первое намерение состояло в том, чтобы найти базовую фиксацию, где два «функциональных пакета» расходятся. Я создал две ветви из этой фиксации, и я начал вишневый захват над основанием один за другим. К счастью, их было не так уж много. Это привело к двум ветвям (v1.1 и v1.2), содержащим соответствующие вещи на месте, за исключением того, что мне пришлось переустановить v1.2 на v1.1, так как функциональность в v1.1 также необходима в v1.2

После всего этого, у меня есть следующие истории:

Как вы можете видеть, у меня есть «оборванных» ветвь, которая является хозяином, на самом деле, но мне не нужны эти коммиты, потому что все они были выбраны вишней в нужном месте.

Вопрос просто в том, как элегантно справляться с такой ситуацией (в основном, устраняя ненужные коммиты) без какого-либо вреда или иначе я бы достиг того же результата?

Answer 1

В этом году на этой конференции был действительно хороший разговор (слайд-колода доступна по ссылке): http://www.thatconference.com/sessions/speaker_188 У докладчика была именно эта проблема и описал, как она решила его с помощью git.

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

Как бесполезно, как это звучит (очевидно, вы уже создали свою историю с помощью текущего рабочего процесса), это может быть полезно для будущего.

Answer 2

Я думаю, что лучшее решение для этого, и я надеюсь, что у меня есть unterstand это правильно является git rebase

Вот некоторые сведения о rebase филиала.

Другое замечательное решение для получения рабочего процесса вы должны посмотреть на gitflow.

Answer 3

Похоже, вы видите, что это не идеальная ситуация. Чтобы не волноваться, решение довольно простое.

Было бы неплохо иметь возможность просто вытащить топор и просто начать измельчение этой большой линии расходящихся коммитов на хозяине, а затем объединить вашу работу обратно в мастера. К сожалению, я сомневаюсь, что с коллегами все будет хорошо, так как это вызовет конфликт (возможно, даже буквальный), когда они попытаются объединить свои изменения в мастер-ветку. Поэтому вместо повторной записи истории лучше всего сделать новый фиксатор.

1. Сначала перейдите на главную ветку, запустив git checkout master.
2. Затем из корня вашего проекта запустите git checkout -f <commit> ., где <commit> представляет собой SHA-хэш коммита с сообщением «активный цвет pst, измененный в средстве рендеринга ячейки измерения» (например, что-то похожее на: 7cd052c). Обратите внимание на точку в конце, которая говорит, чтобы проверить версию текущего каталога из указанной фиксации.
3. Последний шаг изменил файлы в вашем рабочем каталоге, чтобы отразить состояние, в котором они находились у общего предка, где началось расхождение. Теперь давайте сделаем это с помощью git commit -a.
4. На этом этапе вы сможете объединиться в мастер без каких-либо конфликтов: git merge v12.

С этого момента вы можете объединить любые дополнительные изменения, которые вы вносите в главную ветку!