Блог

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

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

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

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

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

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

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

Похоже, что git-worktree является заменой git-new-workdir. Для использования:

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

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

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

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

 git clone my-repo my-repo2
  

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

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

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

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

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