Обновление нескольких локальных рабочих копий с использованием одного источника GitHub? - PullRequest
0 голосов
/ 02 февраля 2012

Переключаясь на GitHub, я не могу найти информацию о том, как сделать то, что я делал с SVN:

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

Раньше я использовал CornerStone на Mac (просто fwiw / у меня его больше нет), и одно обновление от SVN обновило бы все мои различные локальные «зависимые проекты» (все они одинаковые, кроме одного или две строки, обычно в конфигурационном файле). Я бы рассмотрел неизбежные конфликты и почти всегда отклонял их, при условии, что единственное различие в конфликтующем файле было моей настройкой для целей тестирования, или если было что-то новое, я бы слил его и оставил URL-адреса своей промежуточной среды или что-то еще, как они были.

Могу ли я эффективно делать подобные вещи с GitHub? (предпочтительно с использованием GitHub's / Xcode или другого клиента Mac с графическим интерфейсом?)

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

1 Ответ

1 голос
/ 02 февраля 2012

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

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

git pull --rebase

... который получит последнюю версию с сервера, а затем попытается повторно применить ваши коммиты с локальными изменениями поверх них. Если те же части файлов, в которых вы зафиксировали изменения, также не были изменены в новых коммитах на GitHub, у вас даже не должно быть конфликтов для разрешения.

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

(Я надеюсь, что клиенты GUI, которые вы используете, имеют опцию перебазирования при извлечении новых изменений. В противном случае вы можете настроить это на автоматическую настройку с параметром branch.<name>.rebase, где <name> - это имя вашего местное отделение.)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...