Эффективно ли использовать Git и Dropbox?

1133

Как эффективно использовать Git и Dropbox вместе?

n1kh1lp
источник
2
Смотрите также учебник Брэдли Райта .
Рон Ромеро
39
Если вы небольшая команда (думаю, до 5), то BitBucket предоставляет бесплатный хостинг для частных репозиториев. По иронии судьбы у меня тогда есть локальное репо на DropBox, на случай, если я перейду между компьютерами, когда я над чем-то работаю.
Марк Адамсон
12
Я не уверен, что ваша избыточность версий иронична, но она, вероятно, весьма полезна
silasdavis
2
Этот вопрос неясен. Что значит использовать эти инструменты вместе "эффективно"? Это также слишком широко, и, вероятно, генерирует взвешенные ответы.
3
Эй, не могли бы вы считать мой ответ правильным: stackoverflow.com/a/32215708/589667 . Эта библиотека, о которой я упоминаю в своем ответе, является официальным инструментом, созданным разработчиками Dropbox, чтобы помочь людям использовать Git с Dropbox.
clu

Ответы:

1401

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

Установка выглядит примерно так:

~/project $ git init
~/project $ git add .
~/project $ git commit -m "first commit"
~/project $ cd ~/Dropbox/git

~/Dropbox/git $ git init --bare project.git
~/Dropbox/git $ cd ~/project

~/project $ git remote add origin ~/Dropbox/git/project.git
~/project $ git push -u origin master

Оттуда вы можете просто клонировать ~/Dropbox/git/project.gitто, что вы связали с вашей учетной записью Dropbox (или поделились этим каталогом с людьми), вы можете выполнять все обычные операции Git, и они будут синхронизироваться со всеми вашими другими машинами автоматически.

Я написал сообщение в блоге, на версии Control , ( старая ссылка мертвую ) на моих рассуждениях и как настроить мое окружение, это основано на моем Ruby On Rails опыт разработки, но оно может быть применено к чему - либо, на самом деле.

Дэн МакНевин
источник
61
Интересно, что произойдет, если вы нажмете на Dropbox голое репо с двух машин одновременно. Если это приведет к изменению одного из внутренних файлов git, dropbox покажет вам, что есть конфликт - но что вы тогда делаете? Просто выберите одну из версий, а затем снова нажмите на обе машины (по одной)?
Дубек
162
@dubek: Вы, вероятно, в конечном итоге испортите общий репо. Этот подход подходит только для небольшой команды (две в моем случае), где люди могут просто кричать через свои стены кабинета: «Эй! Никто не толкает! Я толкаю сейчас!».
Атес Горал
50
@Ates: По крайней мере, git децентрализован, поэтому, если вам удастся испортить вещи, вы можете восстановить их из чьей-то локальной копии. Если у вас большая команда, есть вероятность, что денег достаточно для размещения репозитория.
23
75
Я возвращался на эту страницу более пяти раз, чтобы использовать эту точную последовательность команд. Я никогда не запомню их, но спасибо за их предоставление!
Джереми Мак
32
@Jo: это не достаточно гетто.
Атес Горал
128

Правильный способ сделать это - использовать git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

Создание собственного репо в Dropbox вызывает много проблем. Аниш (создатель библиотеки) объясняет это лучше всего :

Основной причиной этих проблем является то, что клиент рабочего стола Dropbox предназначен для синхронизации файлов, а не репозиториев Git. Без специальной обработки для Git-репозиториев он не поддерживает те же гарантии, что и Git. Операции в удаленном репозитории больше не являются атомарными, и одновременные операции или неудачная синхронизация с синхронизацией могут привести к повреждению репозитория.

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

Решение: это можно решить правильно. Можно использовать Git с Dropbox и иметь такие же гарантии безопасности и согласованности, как и у традиционного пульта Git, даже при наличии нескольких пользователей и одновременных операций!

Для пользователя это так же просто, как использовать git-remote-dropbox, удаленный помощник Git, который действует как прозрачный двунаправленный мост между Git и Dropbox и поддерживает все гарантии традиционного удаленного Git. Его даже безопасно использовать с общими папками, поэтому его можно использовать для совместной работы (можно неограниченное количество частных репозиториев с неограниченным количеством соавторов!).

С помощью удаленного помощника можно использовать Dropbox в качестве удаленного Git и продолжать использовать все обычные команды Git, такие как git clone, git pull и git push, и все будет работать как положено.

CLU
источник
8
Я рад видеть, что кто-то написал о git-remote-dropbox в этом вопросе StackOverflow. Интересно, есть ли способ получить этот ответ ближе к вершине. Метод, рекомендованный текущим принятым ответом, довольно опасен и может привести к повреждению хранилища.
Fwenom
1
это действительно круто Я обязательно проверю это. но когда я перехожу из одного блока разработки в другой и хочу продолжать работать с синхронизированным репо, этот метод будет работать только в том случае, если я всегда фиксирую свою работу, когда выхожу из машины А, и хочу выбрать, где я остановился на машина Б. я прав? если это так, это не идеально, так как это приведет к потоку «временных» коммитов, которые, как можно утверждать, будут загрязнять историю коммитов репо. может быть, я просто не могу взять свой пирог и съесть его тоже!
бху Буе видя
1
@bhuBouevidya Нет, это не правда. Вам не нужно фиксировать свою работу, чтобы изменения были синхронизированы. Пока файлы сохраняются, файлы будут синхронизироваться. В основном, если у вас есть куча измененных файлов на одном компьютере, изменения будут синхронизированы с другим, потому что Dropbox просто заботится о том, что было сохранено на диск.
clu
2
@ CLU: Да, вы должны совершить свою работу и подтолкнуть. Все, что делает git-remote-dropbox, действует как помощник git remote. Как и другие пульты, ваши локальные коммиты не будут переданы на пульт, пока не будет сделан push. Чтобы получить локально измененные файлы в локальный репозиторий, чтобы их можно было протолкнуть, можно выполнить коммит. Dropbox не будет ничего знать о ваших файлах, которых нет в хранилище.
Муравьи
2
Просто любопытно, является ли git-remote-dropbox кросс-платформенным ... Я вижу, что он использует python, и я знаю, что некоторые другие вещи на python для Dropbox не кроссплатформенные, например, в OS X содержимое командной строки несовместимо.
Майкл
89

Этот ответ основан на Mercurial опыте , а не на Git, но этот опыт говорит, что использование Dropbox таким способом запрашивает поврежденные репозитории, если даже есть вероятность, что вы будете обновлять один и тот же репозиторий на основе Dropbox с разных машин в разное время (Mac, Unix, Windows в моем случае).

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

После того, как я покопался в одном беспорядке, занимаясь этим, я использовал следующий рецепт с большим успехом и без каких-либо проблем. Просто переместите свой репозиторий из Dropbox. Используйте Dropbox для всего остального; документация, файлы JAR , все что угодно. И используйте GitHub (Git) или Bitbucket (Mercurial) для управления самим хранилищем. Оба бесплатны, так что это ничего не добавляет к затратам, и теперь каждый инструмент играет на своих сильных сторонах.

Запуск Git / Mercurial поверх Dropbox ничего не добавляет, кроме риска. Не делай этого.

Bradjcox
источник
13
Я чувствую, что хранилище git достаточно надежно, чтобы не портить себя. Мой опыт (более года использования, в основном однопользовательский, кросс-платформенный, кросс-компьютерный, несколько разработчиков), заключается в том, что репозиторий git не так легко испортить. В git добавляется только информация в хранилище, существующие файлы остаются одни 99,9% времени (изменяемые файлы в основном легко проверить вручную). Иногда я видел случаи, когда указатель ветки был перезаписан, но это легко увидеть (то есть «ветвь (конфликтующая копия XXX)») и удалить (на самом деле не нужно никакого реального исправления).
Эгон
1
@tc: Вы правы, во время сбора мусора недоступная информация удаляется в git. Тем не менее, я полагаю, что в большинстве практических случаев это не вредит надежности: затрагивается только недоступная информация старше 2 недель (что достаточно для синхронизации DropBox). И в этот момент такого конфликта я подозреваю, что большая часть информации будет доступна как в упакованном, так и в распакованном виде.
Egon
Я думаю, что сценарий совместного использования кода без центрального репо (описанный в ответе ниже) спасет один от возможных повреждений из-за одновременного обновления каталога в dropbox. Если нужен центральный репо, им можно управлять отдельно (и за исключением Dropbox); Dropbox будет содержать личные рабочие репозитории (что также удобно, потому что вы можете время от времени обновлять / извлекать из чужого репозитория в вашей команде, над которым вы работаете). (Я на самом деле обдумываю использование дарков в такой обстановке.)
imz - Иван Захарящев,
5
+1 Если вы не хотите размещать свои репозитории публично, используйте Bitbucket , частные репозитории бесплатны для команд до 5 пользователей.
Кристиан Шпехт
Одна вещь, которую я заметил между машиной Windows и машиной OSX, - права доступа к файлам могут вызывать проблемы с различиями. Вы можете отключить разрешения в Git, используя: «git config core.fileMode false»
devdrc
16

Что касается небольших команд, использующих Dropbox:

Если у каждого разработчика есть свой собственный доступный для записи пустой репозиторий в Dropbox, доступный только для других разработчиков, то это облегчает совместное использование кода без риска повреждения!

Затем, если вам нужна централизованная «основная линия», вы можете попросить одного разработчика управлять всеми ее усилиями из собственного репо.

teh_senaus
источник
1
Отлично так много! Кроме того, для защиты повреждений репо от множественных записей вы можете легко сделать несколько репозиториев и синхронизировать только их папки .git! Все, что вам нужно в данный момент - это вытащить из желаемого происхождения! Отличный П-к-П человек! Вы понимаете философию децентрализованного Git!
Брайан Хаак
16

Я не хотел помещать все свои проекты в один репозиторий Git, и при этом я не хотел входить и запускать этот код для каждого отдельного проекта, поэтому я создал скрипт Bash , который автоматизирует процесс. Вы можете использовать его в одном или нескольких каталогах - так что он может сделать код в этом посте для вас, или он может сделать это для нескольких проектов одновременно.

#!/bin/sh
# Script by Eli Delventhal
# Creates Git projects for file folders by making the origin Dropbox. You will need to install Dropbox for this to work.

# Not enough parameters, show help.
if [ $# -lt 1 ] ; then

cat<<HELP
projects_to_git.sh -- Takes a project folder and creates a Git repository for it on Dropbox

USAGE:
    ./projects_to_git.sh file1 file2 ..

EXAMPLES:
    ./projects_to_git.sh path/to/MyProjectDir
        Creates a git project called MyProjectDir on Dropbox

    ./projects_to_git.sh path/to/workspace/*
        Creates a git project on Dropbox for every folder contained within the workspace directory, where the project name matches the folder name

HELP
    exit 0
fi

# We have enough parameters, so let's actually do this thing.

START_DIR=$(pwd)

# Make sure we have a connection to Dropbox
cd ~
if [ -s 'Dropbox' ] ; then
    echo "Found Dropbox directory."
    cd Dropbox
    if [ -s 'git' ] ; then
        echo "    Dropbox Git directory found."
    else
        echo "    Dropbox Git directory created."
        mkdir git
    fi
else
    echo "You do not have a Dropbox folder at ~/Dropbox! Install Dropbox. Aborting..."
    exit 0
fi

# Process all directories matching the passed parameters.
echo "Starting processing for all files..."
for PROJ in $*
do
    if [ -d $PROJ ] ; then
        PROJNAME=$(basename $PROJ)
        echo "  Processing $PROJNAME..."

        # Enable Git with this project.
        cd $PROJ
        if [ -s '.git' ] ; then
            echo "    $PROJNAME is already a Git repository, ignoring..."
        else
            echo "    Initializing Git for $PROJNAME..."
            git init -q
            git add .
            git commit -m "Initial creation of project." -q

            # Make the origin Dropbox.

            cd ~/Dropbox/git
            if [ -s $PROJNAME ] ; then
                echo "    Warning! $PROJNAME already exists in Git! Ignoring..."
            else
                echo "    Putting $PROJNAME project on Dropbox..."
                mkdir $PROJNAME
                cd $PROJNAME
                git init -q --bare
            fi

            # Link the project to the origin
            echo "    Copying local $PROJNAME to Dropbox..."
            cd $PROJ
            git remote add origin "~/Dropbox/git/$PROJNAME"
            git push -q origin master
            git branch --set-upstream master origin/master
        fi
    fi
done

echo "Done processing all files."
cd $START_DIR
Eli
источник
15

Я не думаю, что использование Git и Dropbox - это путь ... Просто подумайте об особенностях обоих:

Git:

  • Позволяет иметь центральное хранилище
  • Позволяет вам иметь свой собственный репозиторий со своими изменениями
  • Позволяет отправлять и получать изменения из центрального хранилища
  • Позволяет нескольким людям изменять одни и те же файлы, и они объединяют их или просит объединить их, если он не может этого сделать
  • Имеет веб-клиенты и клиенты для доступа к центральному хранилищу

Dropbox:

  • Хранит все в центральном хранилище
  • Позволяет вам иметь свои собственные версии файлов на сервере
  • Заставляет вас отправлять и получать изменения из центрального хранилища
  • Если несколько человек изменяют одни и те же файлы, первый зафиксированный файл заменяется последующим подтверждением, и слияние не происходит, что является проблематичным (и, безусловно, его самым большим недостатком)
  • Имеет веб-клиенты и клиенты для доступа к центральному хранилищу.

И если вы беспокоитесь о том, чтобы поделиться некоторыми своими файлами, почему бы не зашифровать их? И тогда вы можете получить самое большое преимущество Dropbox для Git, то есть иметь открытые и закрытые файлы ...

Coyote21
источник
Dropbox - просто хороший вариант для центрального репо. Если поместить в общую папку, он даже работает для групп.
Mac
1
Да, но у вас не будет тех же функций слияния, что и в git, на самом деле, если кто-то редактирует тот же файл, что и ваш, и он сохраняет файл после вас, ваши изменения будут потеряны, если вы не зайдете в веб-интерфейс и не загрузите старая версия (ваша версия).
Coyote21
8
Это не верно. Dropbox не сбрасывает конфликты. Он искажает имя файла одного редактирования и использует другое для преемственности. Вы можете вручную объединить их, если хотите. Это хороший компромисс, и он не теряет данные. dropbox.com/help/36
Clueless
6
Да, но поскольку речь идет о коде, чем меньше времени я трачу на объединение файлов, тем больше кода я могу создать, и в обычной кодовой базе это может привести к сотням конфликтов одновременно, в зависимости от размеров проекта, и это будет кошмаром для затем объединяйте одно за другим, даже с помощью инструмента объединения, такого как WinMerge (или чего-то подобного).
Coyote21
15

Сейчас 2015 год, и три дня назад был создан новый инструмент на основе Dropbox API v2 для безопасного использования git в Dropbox. Он работает против API, а не с помощью клиента рабочего стола, и правильно обрабатывает несколько одновременных запросов в репозиторий, размещенный в общей папке.

После настройки он позволяет настроить git remote точно так же, как и любой другой git remote.

git clone "dropbox::/path/to/repo"
git remote add origin "dropbox::/path/to/repo"
merlin2011
источник
2
Было бы неплохо, если бы какой-нибудь мод объединял все вопросы о git-with-dropbox на stackexchange в супер-потоке, который первым упоминает последние вещи.
Блэр Хоутон
9

Я использую Mercurial (или Git) + TrueCrypt + Dropbox для зашифрованных удаленных резервных копий .

Самое классное, что Dropbox НЕ синхронизирует весь контейнер TrueCrypt, если вы изменили небольшую часть вашего кода. Время синхронизации примерно пропорционально количеству изменений. Несмотря на то, что он зашифрован, комбинация TrueCrypt + Dropbox отлично использует блочный шифр + синхронизацию на уровне блоков.

Во-вторых, монолитный зашифрованный контейнер не только повышает безопасность, но и снижает вероятность повреждения хранилища .

Внимание: Однако вы должны быть очень осторожны, чтобы не устанавливать контейнер во время работы Dropbox. Также может быть затруднительно разрешать конфликты, если 2 разных клиента регистрируют разные версии в контейнере. Таким образом, это практично только для одного человека, использующего его для резервного копирования, а не для команды.

Настроить:

  • Создайте контейнер Truecrypt (несколько гигабайт в порядке)
  • В настройках Truecrypt снимите флажок preserve modification timestamp*.
  • Создайте репо, как упомянуто выше Дэном ( https://stackoverflow.com/a/1961515/781695 )

Применение:

  • Выйти из Dropbox
  • Смонтируйте контейнер, вставьте изменения, размонтируйте
  • Запустить Dropbox

PS Снятие флажка preserve modification timestampговорит о том, что файл был изменен, и он должен быть синхронизирован. Обратите внимание, что монтирование контейнера изменяет временную метку, даже если вы не измените в ней файл. Если вы не хотите, чтобы это произошло, просто смонтируйте том какread-only

пользователь
источник
Будет ли это сильно отличаться, если использовать зашифрованное изображение MacOS .dmg , будет ли время синхронизации примерно пропорционально изменениям?
IBrum
@IBrum К сожалению, я не пробовал его с файлом .dmg
пользователь
7

Мне нравится ответ Дэна МакНевина! Я тоже сейчас использую Git и Dropbox вместе, и я использую несколько псевдонимов в моем .bash_profile, так что мой рабочий процесс выглядит так:

~/project $ git init
~/project $ git add .
~/project $ gcam "first commit"
~/project $ git-dropbox

Это мои псевдонимы:

alias gcam='git commit -a -m'
alias gpom='git push origin master'
alias gra='git remote add origin'
alias git-dropbox='TMPGP=~/Dropbox/git/$(pwd | awk -F/ '\''{print $NF}'\'').git;mkdir -p $TMPGP && (cd $TMPGP; git init --bare) && gra $TMPGP && gpom'
Михель де Маре
источник
Вероятно, я бы не использовал последнюю вещь в качестве псевдонима, а скорее сценарий оболочки. В остальном мне это очень нравится. Дополнительный кредит за использование awk.
pauljohn32
6

Мы используем этот метод (создание чистого хранилища в Dropbox) в общей папке .

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

Одна вещь, которую я пропускаю, - это хороший способ отправить электронное письмо с информацией о наборе изменений после того, как произойдет толчок к источнику. Мы используем Google Wave для отслеживания изменений вручную.

Dengel
источник
81
Кто-нибудь использует Google Wave?
Кристофер Джонсон
6

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

Брэд кокс
источник
У меня была такая же проблема с ртутью
Томба
Git делает гораздо больше проверок на наличие повреждений, чем другие по дизайну. По крайней мере, вы будете знать, когда это произойдет, и сможете исправить проблему.
Андерс
6

Есть также проект с открытым исходным кодом (коллекция кроссплатформенных [Linux, Mac, Win] сценариев), который выполняет все мелкие детали управления хранилищем с помощью нескольких (3-4) команд.

https://github.com/karalabe/gitbox/wiki

Пример использования:

$ gitbox create myapp
Creating empty repository...
Initializing new repository...
Repository successfully created.

$ gitbox clone myapp
Cloning repository...
Repository successfully cloned.

После чего нормальное использование git:

$ echo “Some change” > somefile.txt
$ git add somefile.txt
$ git commit –m “Created some file”
$ git push

Проверьте вики проекта и руководства для полного справочника команд и учебных пособий.

Петер Силаджи
источник
4

Я храню свои репозитории без Github в Dropbox. Одна оговорка, с которой я столкнулся, была синхронизация после переустановки. Dropbox сначала загрузит самые маленькие файлы, а затем перейдет к более крупным. Не проблема, если вы начинаете ночью и возвращаетесь после выходных :-)

Моя ветка - http://forums.dropbox.com/topic.php?id=29984&replies=6

Бен
источник
4

Сейчас, в 2014 году, я без проблем пользуюсь Git и Dropbox около полутора лет. Некоторые моменты, хотя:

  • Все мои машины, использующие Dropbox, работают под Windows, разные версии (от 7 до 8) + 1 mac.
  • Я не делюсь хранилищем с кем-то еще, поэтому я единственный, кто может его изменить.
  • git push отправляет в удаленный репозиторий, так что если он когда-либо будет поврежден, я легко смогу его восстановить.
  • Мне пришлось создавать псевдонимы C:\Usersс, mklink /D link targetпотому что некоторые библиотеки указывали на абсолютные местоположения.
Микаэль Майер
источник
3

Мне нравится лучший голос Дэна МакНевина. В итоге я слишком много раз выполнял последовательность команд git и решил создать скрипт. Итак, вот оно:

#!/bin/bash

# Usage
usage() {
    echo "Usage: ${0} -m [ master-branch-directory ] -r [ remote-branch-directory ] [ project-name ]"
    exit 1
}

# Defaults
defaults() {
    masterdir="${HOME}/Dropbox/git"
    remotedir="${PWD}"
    gitignorefile="# OS generated files #\n\n.DS_Store\n.DS_Store?\n.Spotlight-V100\n.Trashes\nehthumbs.db\nThumbs.db"
}

# Check if no arguments
if [ ${#} -eq 0 ] ; then
    echo "Error: No arguments specified"
    usage
fi

#Set defaults
defaults

# Parse arguments
while [ ${#} -ge 1 ]; do
    case "${1}" in
        '-h' | '--help' ) usage ;;
        '-m' )
            shift
            masterdir="${1}"
            ;;
        '-r' )
            shift
            remotedir="${1}"
            ;;
        * )
            projectname="${1##*/}"
            projectname="${projectname%.git}.git"
            ;;
    esac
    shift
done

# check if specified directories and project name exists
if [ -z "${projectname}" ]; then
    echo "Error: Project name not specified"
    usage
fi

if [ ! -d "${remotedir}" ]; then
    echo "Error: Remote directory ${remotedir} does not exist"
    usage
fi

if [ ! -d "${masterdir}" ]; then
    echo "Error: Master directory ${masterdir} does not exist"
    usage
fi

#absolute paths
remotedir="`( cd \"${remotedir}\" && pwd )`"
masterdir="`( cd \"${masterdir}\" && pwd )`"

#Make master git repository
cd "${masterdir}"
git init --bare "${projectname}"

#make local repository and push to master
cd "${remotedir}"
echo -e "${gitignorefile}" > .gitignore # default .gitignore file
git init
git add .
git commit -m "first commit"
git remote add origin "${masterdir}/${projectname}"
git push -u origin master

#done
echo "----- Locations -----"
echo "Remote branch location: ${remotedir}"
echo "Master branch location: ${masterdir}"
echo "Project Name: ${projectname}"

Сценарий требует только имя проекта. Это сгенерирует git-репозиторий в~/Dropbox/git/ с указанным именем и отправит все содержимое текущего каталога во вновь созданную главную ветвь источника. Если задано более одного имени проекта, будет использован самый правый аргумент имени проекта.

Необязательно, аргумент команды -r указывает удаленную ветвь, которая будет отправлять на мастер-источник. Расположение мастера происхождения проекта также можно указать с помощью аргумента -m. Файл .gitignore по умолчанию также помещается в каталог удаленной ветви. По умолчанию каталог и файл .gitignore указываются в скрипте.

ChisholmKyle
источник
3

Другой подход:

Все ответы на данный момент, включая ответ @Dan который является самым популярным, направлены на идею использования Dropbox для централизации общего репозитория вместо использования службы, ориентированной на git, такой как github, bitbucket и т. Д.

Но поскольку в первоначальном вопросе не указано, что на самом деле означает «эффективно объединять Git и Dropbox», давайте поработаем над другим подходом: «Использование Dropbox для синхронизации только рабочего дерева».

В руководстве есть следующие шаги:

  1. внутри каталога проекта создается пустой .gitкаталог (например mkdir -p myproject/.git)

  2. отменить синхронизацию .gitкаталога в Dropbox. При использовании приложения Dropbox: перейдите в «Настройки», «Синхронизация» и «выберите папки для синхронизации», где .gitкаталог должен быть без опознавательных знаков. Это удалит .gitкаталог.

  3. запустить git initв каталоге проекта

Это также работает, если .gitуже существует, тогда только сделайте шаг 2. Хотя Dropbox сохранит копию файлов git на веб-сайте.

Шаг 2 заставит Dropbox не синхронизировать структуру git-системы, что является желаемым результатом для этого подхода.

Почему бы использовать этот подход?

  • Изменения, которые еще не были переданы, будут иметь резервную копию Dropbox, и они будут синхронизироваться между устройствами.

  • В случае, если Dropbox что-то испортит при синхронизации между устройствами, git statusи git diffбудет удобно разобраться.

  • Это экономит место в учетной записи Dropbox (там не будет храниться вся история)

  • Это позволяет избежать проблем, поднятых @dubek и @Ates в комментариях к ответу @ Dan, и проблем @clu в другом ответе .

Существование удаленного где-то еще (github и т. Д.) Будет нормально работать при таком подходе.

Работа в разных ветках приносит некоторые проблемы, о которых нужно позаботиться:

  • Одна потенциальная проблема заключается в том, что Dropbox (излишне?) Синхронизирует потенциально много файлов, когда проверяются разные ветви.

  • Если два или более синхронизированных устройства Dropbox имеют разные ветки, не зафиксированные изменения на обоих устройствах могут быть потеряны,

Одним из способов решения этих проблем является использование git worktreeпроверок филиалов в отдельных каталогах.

IBrum
источник
Как кто-то, кто работает с файлами, которые были бы хороши для контроля версий, но также были бы доступны для редактирования на iPad (с помощью синхронизации Dropbox), этот ответ охватывает этот вариант использования.
Вагари
Быстрое отслеживание, текущее поведение Dropbox другое. Простое удаление и указание Dropbox не синхронизировать означает обратное, пребывание в облаке, удаление из локального. Но есть суперпользовательский ответ с решением. superuser.com/a/1527145/109561 В моем случае (на Mac) следующие флаги файл для игнорирования, xattr -w com.dropbox.ignored 1 /path/to/somewhere.
Вагари
3

Для моих 2 центов Dropbox имеет смысл только для личного использования, где вы не хотите беспокоиться о получении центрального хоста репо. Для любого профессионального развития вы, вероятно, создадите больше проблем, чем решите, как уже упоминалось в этой теме несколько раз, Dropbox не предназначен для этого варианта использования. Тем не менее, совершенно безопасный способ выгрузить репозитории на Dropbox без каких-либо сторонних плагинов или инструментов - это использовать пакеты. У меня есть следующие псевдонимы .gitconfigдля сохранения ввода:

[alias]
        bundle-push = "!cd \"${GIT_PREFIX:-.}\" && if path=\"$(git config remote.\"$1\".url)\" && [ \"${path:0:1}\" = / ]; then git bundle create \"$path\" --all && git fetch \"$1\"; else echo \"Not a bundle remote\"; exit 1; fi #"
        bundle-fetch = "!cd \"${GIT_PREFIX:-.}\" && if path=\"$(git config remote.\"$1\".url)\" && [ \"${path:0:1}\" = / ]; then git bundle verify \"$path\" && git fetch \"$1\"; else echo \"Not a bundle remote\"; exit 1; fi #"
        bundle-new = "!cd \"${GIT_PREFIX:-.}\" && if [ -z \"${1:-}\" -o -z \"${2:-}\" ]; then echo \"Usage: git bundle-new <file> <remote name>\"; exit 1; elif [ -e \"$2\" ]; then echo \"File exist\"; exit 1; else git bundle create \"$2\" --all && git remote add -f \"$1\" \"$(realpath \"$2\")\"; fi #"

Пример:

# Create bundle remote (in local repo)
$ git bundle-new dropbox ~/Dropbox/my-repo.bundle
# Fetch updates from dropbox
$ git bundle-fetch dropbox
# NOTE: writes over previous bundle. Thus, roughly equivalent to push --force --prune --all
$ git bundle-push
Никлас Холм
источник
2

Я столкнулся с подобной проблемой и создал небольшой сценарий для того же. Идея состоит в том, чтобы использовать Dropbox с Git как можно проще. В настоящее время я быстро реализовал код на Ruby и скоро добавлю еще.

Сценарий доступен по адресу https://github.com/nuttylabs/box-git.

Киран Мадипалли
источник
0

Без использования сторонних инструментов интеграции я мог бы немного улучшить условия и использовать DropBox и другие подобные сервисы облачных дисков, такие как SpiderOak с Git.

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

Чтобы избежать этой проблемы, я сделал:

  1. Объедините мой индекс git в один файл, используя git bundle create my_repo.git --all.
  2. Установите задержку для мониторинга файла, например, 5 минут, а не мгновенную. Это уменьшает шансы, что DropBox синхронизирует частичное состояние в середине изменения. Это также очень помогает при изменении файлов на облачном диске на лету (например, при мгновенном сохранении приложений для создания заметок).

Он не идеален, поскольку нет гарантии, что он не испортит состояние git снова, но это помогает, и на данный момент у меня не возникло никаких проблем.

gaborous
источник
0

В MacOS вы также можете просто остановить Dropbox, внести свои изменения и снова запустить Dropbox. Я использую следующую комбинацию и вполне ей доволен:

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

git config --global gc.auto 0

Затем время от времени сжимайте репозитории с отключенным Dropbox. Например, я делаю следующее в моем bash-build-script всякий раз, когда делаю новые выпуски своих приложений.

osascript -e "tell application \"Dropbox\" to quit"

# Compress local
git gc --prune=now; git repack -a -d

# Compress remote
REPOS_DIR_REMOTE=`git remote get-url --push origin`
cd "${REPOS_DIR_REMOTE}"
git gc --prune=now; git repack -a -d

osascript -e "tell application \"Dropbox\" to launch"
osascript -e "display notification with title \"Compress Done\""
berbie
источник