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

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

19 ответов

Решение

Я думаю, что 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, и они будут синхронизироваться со всеми другими вашими компьютерами автоматически.

Я написал сообщение в блоге " О контроле версий"( старая ссылка умерла) о моих рассуждениях и о том, как я настраивал свою среду, оно основано на моем опыте разработки на 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, presto, сломанное хранилище. Это происходит немедленно и незаметно, поэтому вы даже не знаете, что ваш репозиторий сломан, пока не попытаетесь что-то восстановить из него.

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

Запуск Git/Mercurial поверх 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

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

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

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

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

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

Git:

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

Dropbox:

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

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

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

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

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

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

Настроить:

Использование:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для моих 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\""
Другие вопросы по тегам