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

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

ОТВЕТЫ

Ответ 1

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

Я написал сообщение в блоге "Управление версиями" , старая ссылка dead) по моим рассуждениям и тому, как я настроил свою среду, основанную на моем опыте разработки Ruby on Rails, но она может быть применена ко всему, действительно.

Ответ 2

Правильный способ сделать это - использовать 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. Его даже безопасно использовать с общими папками, поэтому его можно использовать для сотрудничество (yay неограниченное частное РЕПО с неограниченным соавторы!).

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

Ответ 3

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

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

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

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

Ответ 4

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

#!/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 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

Ответ 5

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

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

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

Ответ 6

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

Git:

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

Dropbox:

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

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

Ответ 7

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

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

git clone "dropbox::/path/to/repo"
git remote add origin "dropbox::/path/to/repo"

Ответ 8

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

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

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

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

Настройка:

  • Создайте контейнер Truecrypt (несколько Gigabyte в порядке)
  • В настройках Truecrypt снимите флажок preserve modification timestamp *.
  • Создайте репо, как упоминалось выше Dan (fooobar.com/questions/1274/...)

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

  • Выход из Dropbox
  • Установите контейнер, нажмите свои изменения, отключите
  • Запустить dropbox

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

Ответ 9

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

  ~/project $Git init
~/project $Git добавить.
~/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"
Код>

Ответ 10

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

Ответ 11

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

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

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

Ответ 12

Также есть проект с открытым исходным кодом (сборник скриптов [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

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

Ответ 13

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

My thread - http://forums.dropbox.com/topic.php?id=29984&replies=6

Ответ 14

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

#!/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}"

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

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

Ответ 15

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

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

Ответ 16

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

script доступен в https://github.com/nuttylabs/box-git.

Ответ 17

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

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

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

Практическое руководство имеет следующие шаги:

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

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

  • запустите 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, чтобы сохранить ветки в отдельных каталоги.

Ответ 18

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

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

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

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

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

Ответ 19

Я думаю, вы можете попробовать GitDrive, очень интересное решение для локального сервера git, превращает ваше устройство iOS в портативное жесткое диск, но он был вызван Git. Он также синхронизирует все ваши репозитории с iCloud. В вашем кармане вы получите отлично функционирующий сервер git.

Ответ 20

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