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

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

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

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

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

обновление через 3 года

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

Ответ 1

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

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

Ответ 2

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

git clone my-repo my-repo2

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

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

Ответ 3

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

Ответ 4

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

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