Работа с Git на нескольких машинах

Это может звучать немного странно, но я задаюсь вопросом о хорошем способе работы в Git с несколькими компьютерами, которые каким-то образом объединены в сеть. Мне кажется, у меня есть два варианта, и я вижу преимущества с обеих сторон:

• Используйте сам git для обмена, у каждой машины есть свой репо, и вы должны выбирать между ними.
  • Вы можете работать на любом компьютере, даже если другой не подключен к сети. Это само по себе довольно большое, я думаю.
• Используйте один репозиторий, который является общим по сети между машинами.
  • Не нужно делать git pull каждый раз, когда вы переключаете машины, так как ваш код всегда актуален.
  • Никогда не беспокойтесь, что вы забыли отправить код с другого компьютера, не являющегося хостингом, который сейчас недоступен, так как вы работали с файловым ресурсом на этом компьютере.

Моя интуиция говорит, что все обычно выбирают первый вариант. Но недостатком, который я вижу, является то, что вы не всегда сможете получить доступ к коду с других ваших машин, и я, конечно же, не хочу отправлять все свои ветки WIP в github в конце каждого дня. Я также не хочу постоянно оставлять свои компьютеры включенными, чтобы я мог получать их напрямую. Наконец, второстепенный момент заключается в том, что все команды git для обновления нескольких веток могут быть утомительными.

Есть ли третья ручка в этой ситуации? Может быть, есть некоторые сторонние инструменты, которые помогут сделать этот процесс проще? Если вы регулярно сталкиваетесь с этой ситуацией, что вы предлагаете?

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

1. Используйте тематические ветки. Я считаю, что история производства должна быть чистой. В результате я трачу много времени на то, чтобы сделать productionисторию моей ветви логичной, воспроизводимой и отлаживаемой. Однако при использовании нескольких машин вам иногда требуется зафиксировать незавершенную работу. Используйте ветку темы. Вы можете pullи pushэту ветку с обеих машин приложить без особых усилий, и когда она будет готова слиться masterили production перебазировать ее, чтобы создать более понятную историю.
2. Использование одного репо с общим доступом по сети - это хорошо, если только вы не делитесь им с другими пользователями. Мы используем общий репозиторий для скриптов, креативно названный scriptsрепозиторий. Сначала это казалось хорошей идеей, поскольку репо не часто меняется, но со временем это стало настоящим кошмаром. Работу друг друга легко переписать, и вы тратите столько времени на управление воздушным движением, кто развертывает хранилище, сколько вы работаете в нем.

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

Если вы обнаружите, что работаете над несколькими git push <remote>ветками тем в течение дня, но не хотите передавать каждую из них по отдельности на удаленный сервер, по умолчанию будут отправлены все соответствующие ветки <remote>. Это значение по умолчанию изменится в более поздней версии git , но может быть изменено путем установки push.defaultв файле конфигурации или путем указания соответствия refspec:

git push <remote> :

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

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

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

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

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

Ключевым моментом здесь является то, что репозиторий SkyDrive существует главным образом для обеспечения того, чтобы у меня был доступ к более или менее последней версии кода на обеих моих машинах - хотя это будет работать также и для большего количества - и для обеспечения дополнительная резервная копия. Все, что «сделано», отправляется в Kiln (если бы я использовал git и правильно понял, как проходит игра, то это будет момент, когда я делаю ребаз).

То, что я действительно не хотел бы делать, это запускать из общей папки ... если вы используете DVCS, то вы также можете воспользоваться преимуществом.

Первая из двух ваших альтернатив - это ответ. Это подразумевается буквой «D» в «DVCS». У каждого пользователя есть свой локальный экземпляр хранилища, и хранилища общаются между собой управляемыми способами.

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

Существует золотая середина, имеющая пустой репозиторий на сетевом диске и позволяющая отдельным пользователям регистрироваться и выходить из него. Это отделяет вашу работу WIP (которую вы сохраняете локально) от работы, которую вы публикуете до репозитория. Это не «сохранить» - это «опубликовать». Работа, которую вы хотите, чтобы ваши коллеги видели и использовали.