Как собрать / протестировать код в локальном репо, продолжая при этом изменять его - PullRequest
Новая
       66

Как собрать / протестировать код в локальном репо, продолжая при этом изменять его

4 голосов
/ 08 мая 2020

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

Я не могу разложить задачу. Было бы полезно думать о «дополнительном коде» как о модульных тестах. Отзывы о том, насколько плохо факторизован этот репозиторий, мне не помогут. Было бы полезно думать о моем коде как о рефакторинге, чтобы сделать его более модульным.

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

Я бы хотел развиваться по этому шаблону:

  1. develop код в репо 1
  2. сборка репо 1 (часы начинаются при двухчасовой сборке)
  3. параллельно, вытягивать изменения из репо 1 в репо 2
  4. параллельно, делать дальше изменения в репо 2, которые не нарушают текущую сборку в репо 1
  5. параллельно, полный код в репо 2
  6. завершение сборки в репо 1
  7. извлечение изменений из репо 2 в репо 1

Какие у меня есть возможности выполнить sh это?

Я не женат на описанных выше шагах, но я заинтересован в сокращении времени, которое я должен тратить на отказ от разработки кода, пока выполняется невероятно длинная сборка.

1 Ответ

2 голосов
/ 09 мая 2020

У вас есть несколько вариантов в зависимости от вашей ситуации и потребностей. Варианты 1 и 2 полностью работают на вашем локальном компьютере, а вариант 3 работает через сервер git.

вариант 1. Создать локальный клон.

git clone /path/to/source-repo-dir /path/to/new-repo-dir создаст локальный клон. От git help clone:

Когда репозиторий для клонирования находится на локальном компьютере, этот флаг обходит обычный транспортный механизм «Git с учетом» и клонирует репозиторий путем создания копии HEAD и все в каталогах объектов и ссылок. Файлы в каталоге .git / objects / жестко связаны для экономии места, когда это возможно.

Даже если репозиторий, который вы клонируете, является локальным, он будет настроен как удаленный , и вы будете тянуть и pu sh к нему так же, как к серверу git, например GitHub.

Чтобы упростить удержание в голове, вы можете использовать опцию --origin с git clone, чтобы дать своему локальному удаленному устройству имя, отличное от "origin" по умолчанию, особенно если вы привыкли или уже используете это имя для фактического удаленного репозитория восходящего потока.

Я бы, вероятно, использовал нисходящий клон для сборок и мой dev в репозитории восходящего потока, но вы можете сделать это другим способом, если хотите. Вы даже можете сделать отношения симметричными, добавив новое репо в качестве удаленного в исходное репо (чтобы они оба были удаленными друг от друга).

См. Также git help clone для информации, например, о --no-hardlinks и --shared, но я рекомендую придерживаться значений по умолчанию.

вариант 2: используйте git worktree

Этот вариант позволяет вам иметь одно локальное репо, но иметь два или больше отдельных рабочих деревьев.

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

См. Несколько рабочих каталогов с Git? для получения дополнительной информации.

вариант 3: через центральный пульт (например, частный сервер git или GitHub)

Если вы отправляете свой код в удаленное «вышестоящее» репо, просто создайте его новый клон. Это работает точно так же, как вариант 1, за исключением того, что синхронизация изменений между вашими двумя локальными клонами требует дополнительного шага по отправке и извлечению из репозитория восходящего потока. Если вы все равно делаете это или если вы работаете в команде и хотите, чтобы ваши товарищи по команде увидели новый код еще до того, как ваша длинная сборка будет завершена, это способ go.

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

Вы также можете воспользоваться услугами непрерывной интеграции (например, Travis on GitHub).

...