Використовуйте Git та Dropbox разом разом?

Як ефективно використовувати Git та Dropbox ?

Я думаю, що Git on Dropbox чудовий. Я ним користуюся весь час. У мене є кілька комп’ютерів (два вдома та один на роботі), які я використовую Dropbox як центральний голий сховище. Оскільки я не хочу розміщувати його на загальнодоступній службі, і у мене немає доступу до сервера, на який я завжди можу отримати доступ, 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, і вони будуть синхронізовані на всі ваші інші машини автоматично.

Я написав повідомлення в блозі On Control Control ( старе посилання ^мертве ) про свої міркування та про те, як я налаштував своє середовище, це засноване на моєму досвіді розробки Ruby on Rails , але воно може бути застосоване до будь-чого, насправді.

Правильний спосіб зробити це - використовувати git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

Створення власного голого репо в Dropbox викликає масу проблем. Аніш (творець бібліотеки) пояснює це найкраще :

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

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

Рішення: Це можна правильно вирішити. Можна використовувати Git з Dropbox і мати ті ж гарантії безпеки та послідовності, що і традиційний пульт дистанційного керування, навіть якщо є кілька користувачів та одночасні операції!

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

За допомогою віддаленого помічника можна використовувати Dropbox як пульт Git та продовжувати використовувати всі звичайні команди Git, такі як клон git, git pull та git push, і все буде працювати як слід.

Ця відповідь ґрунтується на досвіді Mercurial , а не на Git, але цей досвід говорить про те, що при використанні Dropbox таким чином потрібно просити корумповані сховища, якщо є навіть шанс, що ви оновлюватимете те саме сховище на основі Dropbox з різних машин у різний час (Mac, Unix, Windows у моєму випадку).

У мене немає повного переліку речей, які можуть піти не так, але ось конкретний приклад, який мене вкусив. Кожна машина має своє поняття про символи кінців рядків та про те, як обробляються великі та малі символи у назвах файлів. Dropbox і Git / Mercurial вирішують це дещо інакше (я не пам'ятаю точних відмінностей). Якщо Dropbox оновлює сховище за спиною Git / Mercurial, престолом, зламаним сховищем. Це відбувається негайно і непомітно, тому ви навіть не знаєте, що ваш сховище зламано, поки ви не спробуєте відновити щось із нього.

Після того, як викопані з одного безладу, роблячи речі таким чином, я користувався наступним рецептом з великим успіхом і жодних ознак проблем. Просто перемістіть сховище з 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 точно так само, як і будь-який інший віддалений git.

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
• Монтуйте контейнер, натисніть на зміни, відключіть його
• Запустіть дропбокс

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/вказаному імені та підштовхне весь вміст поточного каталогу до новоствореної гілки master origin. Якщо вказано більше однієї назви проекту, буде використано найправіший аргумент назви проекту.

Необов'язково, аргумент команди -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), виконайте наступну команду, щоб відключити автоматичне пакування (що є основною проблемою синхронізації Drobox)

git config --global gc.auto 0

Потім час від часу стискайте сховища з вимкненою скринькою. Наприклад, я роблю наступне в своєму 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\""