Это как бы обрабатывается в этом вопросе , но я думаю, что ваш вопрос лучше, потому что он ищет немного большей ясности.
Короче говоря: Да, это нормально. Вот немного расширения:
Вы начинаете с этого в главном репозитории (где блоки представляют собой наборы изменений):
main: --[E]--[F]--[G]
затем вы клонируете на рабочий сервер и добавляете набор изменений H, который выполняет настройку развертывания. Таким образом, репозиторий развертывания выглядит так:
production: --[E]--[F]--[G]--[H]
, а затем в главном репо происходит больше работы, добавляются ревизии, I и J, и основной репо выглядит следующим образом:
main: --[E]--[F]--[G]--[I]--[J]
который при извлечении в производство выглядит так:
production: --[E]--[F]--[G]--[I]--[J]
\
\-[H]
с двумя головами, которые вы объединяете, чтобы получить:
production: --[E]--[F]--[G]--[I]--[J]
\ \
\-[H]-----[K]
где K - это просто J плюс изменения, которые вы изначально сделали в H.
Теперь в основном происходит больше работы, давая:
main: --[E]--[F]--[G]--[I]--[J]--[L]--[M]
которые вы тянете в производственную подачу:
production: --[E]--[F]--[G]--[I]--[J]--[L]--[M]
\ \
\-[H]-----[K]
и затем вы сливаетесь и получаете:
production: --[E]--[F]--[G]--[I]--[J]--[L]--[M]
\ \ \
\-[H]-----[K]-------[N]
Таким образом, каждый раз, когда вы вносите изменения из основного, вы выполняете одно слияние и создаете один новый набор изменений (на этот раз N).
Я думаю, что это нормально, и это "нормально".
Однако вы можете избежать этого, воспользовавшись некоторыми ответами в вопросе, с которым я связан выше и есть новый прием, который можно использовать, чтобы изменил исходных родителей H. (и содержание), чтобы он всегда перемещался в конец нового совета.
Хитрость заключается в Расширении Rebase , и оно даст линейную историю производства (хотя вы все равно будете делать то, что по сути является слиянием, чтобы его получить). Я не фанат этого, потому что мне не нравится менять наборы изменений после их фиксации, но, поскольку H никогда не покидает производственную коробку, все в порядке.
Другими ответами были ртутные очереди и , позволяющие вносить производственные изменения в живое хранилище dev и запускаться чем-то другим в производственной среде (например, заголовок Host:).