Как использовать git с Dropbox в одной пользовательской среде

Question

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

Примечание: Любой данный пользователь будет работать только с собственными файлами, поэтому нет сценария, в котором несколько пользователей будут нажимать на одно репо. Каждый пользователь будет иметь свои собственные файлы, отслеживаемые в собственном репо в своем собственном экземпляре Dropbox. Весь смысл состоит в том, чтобы эта возможность была уникальной для каждого пользователя, поэтому их файлы, в основном, поддерживаются и управляются версиями через git и Dropbox.

После прочтения немного (особенно the top two answers here и this great discussion и this article on bare vs non-bare repos), кажется, есть несколько различных подходов с большим количеством за и против обсуждения, и я задаюсь вопросом, какой подход ниже будет лучше в данном конкретном одно- пользовательская ситуация?

В принципе, варианты, которые я вижу, - это использовать Dropbox как однопользовательский git-сервер, поскольку он содержит голый репо, который я каждый раз клонирую локально или не имею метафорического сервера и просто использую Dropbox в качестве файла сервер с не-голым репливом git, который я копирую (полностью) с/на каждый раз.

Вариант 1: Голые репо в Dropbox, скрипт клонирует его в локальный рабочий каталог:c:\dropbox\master.git является голой репо, и сценарий делает git clone c:\dropbox\master.git c:\working, запускает программное обеспечение против полученных файлов в c:\working, затем делает git add и git commit и git push origin master и удаляет c:\working, а затем его выполнение.

Вариант 2: Non-голое репо в Dropbox, сценарий копирует его в локальный рабочем каталог: После копирования всего c:\dropbox\master каталога на c:\working он запускает программу против файлов в c:\working, затем делает git add и git commit, а затем перезаписывает c:\dropbox\master с содержимым c:\working и удаляет c:\working и его выполнение.

Окончательный сценарий powershell также отключит службу Dropbox до того, как он что-нибудь сделает, и запустит ее после того, как она совершит (вариант 1) или копии (вариант 2) обратно в мастер в Dropbox. Эта часть легко на самом деле и гарантирует, что Dropbox не изменит никаких файлов, пока работает локальное репо. И поскольку это будет однопользовательский процесс, я (или кто-то) может подождать несколько минут, чтобы Dropbox завершил синхронизацию при первой загрузке.

Вариант 1 кажется более «git-ish», но при использовании однопользовательского сценария вариант 2 может быть немного проще (только 1 репо для работы вместо 2), но я не уверен, есть ли какие- gotchas "Мне здесь не хватает.

Спасибо за любые советы/идеи/и т. Д.

Answer 1

Вариант 3: Обычный (не голый) Git Repo Dropbox: Проще чем варианты 1 и 2, потому что вам не нужно беспокоиться о копировании вещей в разные места. Просто используйте его как обычный локальный репозиторий git, за исключением того, что он автоматически синхронизируется с облаком.

Я лично использую опцию 3. Dropbox предназначен для бесшовной синхронизации файлов с облаком, когда они действуют как обычные файлы на компьютере, который вы используете. Существует довольно минимальный риск сделать это таким образом. Просто убедитесь, что ваши изменения синхронизированы, когда вы перестали работать. (Не вносите изменения на один компьютер в автономном режиме, а затем вносите изменения на отдельный компьютер до того, как будут синхронизированы первые изменения.) В любом случае Dropbox имеет встроенный откат.

Ни одно из упомянутых решений не является ужасным - все будет работать нормально. Но я не вижу причин, чтобы сделать это сложным, как опции 1 & 2.