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

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

Я думаю, что 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 опыт разработки, но оно может быть применено к чему - либо, на самом деле.

Правильный способ сделать это - использовать 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, и все будет работать как положено.

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

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

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

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

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

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

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

Я не хотел помещать все свои проекты в один репозиторий 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

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

Git:

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

Dropbox:

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

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

Сейчас 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"

Я использую 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

Мне нравится ответ Дэна МакНевина! Я тоже сейчас использую 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'

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

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

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

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

Есть также проект с открытым исходным кодом (коллекция кроссплатформенных [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

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

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

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

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

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

Мне нравится лучший голос Дэна МакНевина. В итоге я слишком много раз выполнял последовательность команд 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 указываются в скрипте.

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

Все ответы на данный момент, включая ответ @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проверок филиалов в отдельных каталогах.

Для моих 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

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

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

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

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

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

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

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

В 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\""