Рабочий процесс Git для локальных коммитов, восходящих коммитов и развертывания

Question

Я знаю, что есть много постов о рабочих процессах git, но я не смог найти именно то, что искал: рекомендации по передовым методам для следующего рабочего процесса:

У меня есть веб-приложение, котороеразвернут через git.Разработчики приложения выпускают обновления через публичное git-репо.У меня также есть свои собственные изменения, которые необходимо применить.Что было бы лучшим способом справиться с этим?

Что я делал: я создал локальный репозиторий для развертывания, клонированный из апстрима.Это подается через Gitolite, так что это голый репо.У меня есть клон этого репо, к которому я применяю изменения и возвращаю их в репозиторий развертывания.Когда изменения публикуются в вышестоящем репо, я включаю их в этот клон, используя рекомендованную команду:

git fetch && git pull --rebase

Затем я отправляюсь в репозиторий развертывания.Проблема в том, что я начинаю получать массу конфликтов слияния с любыми измененными файлами.Этот же файл даст мне много конфликтов во время ребазинга.Я ищу подход, который может быть более или менее автоматизированным, но я не достаточно умен, чтобы понять, в чем проблема.

Может ли какой-нибудь гит-гуру дать совет?Дайте мне знать, если что-то нужно уточнить.Благодарю.

Answer 1

Я не хочу знать и помнить дрянного, уродливого, глупого, «оригинального» Git-jargoon, поэтому я напишу рецепт в виде «необходимых действий», задача по переводу его в команду, которую я оставляю для вас

Подготовка

Отправка текущего рабочего процесса в мусорный ящик

Действия

• Необходимоиметь один репо с двумя филиалами (поставщик и собственный).Ветка поставщика связана с удаленным репо восходящего потока, ваша ветка - это единственное место, где вы храните свои изменения.Собственная ветвь должна быть создана из поставщика, чтобы получить общего родителя для всех файлов в обеих ветвях, файлы в собственном должны быть исправлены с вашими изменениями
• Синхронизация с восходящим потоком, выполняющая обновление ветки поставщика от удаленного и слияние сСобственная ветвь после нее (изменяется с Vendor merged на Own )

У вас будут конфликты только для измененных обеими сторонами (вами и вышестоящими) файловна стадии слияния

Answer 2

Ваш текущий рабочий процесс будет в порядке, если вы удалите --rebase из git pull. Затем pull выполнит слияние (по умолчанию) вместо ребазирования, и у вас будет меньше конфликтов. Конечно, всегда будут ситуации, когда git не сможет разрешить конфликты самостоятельно, поэтому процесс не может быть полностью автоматизирован.

Проблема в том, что rebase делает много шагов, просматривая всю вашу историю и решая каждое изменение, которое вы внесли поверх апстрима. Это не является необходимым для вашего сценария и даже контрпродуктивно, поскольку не позволяет определить, когда были внесены ваши изменения относительно изменений в восходящем потоке. Слияния будут работать лучше, потому что они делают только один шаг и не должны возвращаться слишком далеко в историю (только к предыдущему слиянию).

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