Рабочий процесс Git - изменение ветки и медленная перекомпиляция

Question

Я работаю над большим проектом Scala, где мы используем Git для контроля версий. Мой рабочий процесс состоит в том, чтобы работать над новыми функциями в моей собственной ветке и переключаться при необходимости. Различные выпуски кода находятся в своих собственных ветках. Все очень стандартно.

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

Проблема в том, что, хотя git мгновенно переключается на другую ветку, как только я там, я должен перекомпилировать код. Что занимает несколько минут. Затем исправьте ошибку, вернитесь к моей собственной ветке и выполните еще одну перекомпиляцию, что займет еще несколько минут. Кажется, это побеждает цель того, что Git так быстр.

Кто-нибудь еще сталкивался с этим? Есть ли способы обойти это? Я уверен, что это не специфическая проблема для Scala (хотя Scala очень медленно компилирует).

обновление 3+ года спустя

Я использую ответ @djs (git-new-workdir) последние несколько лет. Это сработало очень хорошо для меня. У меня есть главный каталог и несколько других каталогов (например, производство, следующий выпуск и т. Д.), На которые я переключаюсь, когда мне нужно там работать. Затраты очень малы, и это означает, что вы можете быстро переключиться, чтобы сказать, производство, что-то проверить, а затем вернуться к тому, над чем вы работали.

обновление 7+ лет спустя

Похоже, git-worktree - это замена для git-new-workdir. Использовать:

cd ~/git/my-repo
git worktree add ~/git/my-linked-repo

Answer 1

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

git clone my-repo my-repo2

Затем вы можете работать в своем дополнительном клоне и перенести его обратно в свой основной.(Вы должны нажимать только на ветки, которые не извлечены, но в этом-то и все дело. Вы также можете извлечь или даже извлечь и сбросить или выполнить ветвь -f, если хотите.)

И это не будетдействительно занимают много места;Git жестко связывает объекты в репозитории с локальными клонами, поэтому дополнительное пространство будет просто дополнительной извлеченной копией.

Answer 2

Предполагая, что вы не хотите изменять процесс сборки (на основе хеша вместо отметки времени), вы можете захотеть взглянуть на скрипт git-new-workdir в каталоге contrib исходного кода git. Как и в случае с предложением клона, вы получите несколько рабочих копий, но вместо двух независимых репозиториев вы получите один с несколькими рабочими копиями. Таким образом, между локальными репозиториями не должно быть проталкивания.

Это сценарий оболочки, который выполняется только в Unix-подобных системах, но концепция может быть воспроизведена в современных версиях Windows.

Answer 3

Вы можете попробовать использовать разные целевые каталоги для разных веток, переопределив outputDirectoryName.Может быть, выбрав имя ветви git и установив выходной каталог в target- <branch>;хотя это будет означать, что каждая новая ветка начинается с нуля.

Answer 4

Вы можете значительно улучшить время компиляции scala с помощью [sbt] [1] или «быстрого компилятора scala».Оба позволяют хранить компилятор в памяти, что значительно улучшает время компиляции.

Использование одного каталога на ветвь позволяет избежать такого количества перекомпиляций.Но этот рабочий процесс лучше поддерживается Mercurial.