Korzystasz razem z Git i Dropbox skutecznie?

Jak efektywnie korzystać z Git i Dropbox razem?

Myślę, że Git na Dropbox jest świetny. Używam tego cały czas. Mam wiele komputerów (dwa w domu i jeden w pracy), których używam Dropbox jako centralnego repozytorium. Ponieważ nie chcę hostować go w usłudze publicznej i nie mam dostępu do serwera, do którego zawsze mogę ssh, Dropbox zajmuje się tym, synchronizując (bardzo szybko) w tle.

Konfiguracja wygląda mniej więcej tak:

~/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

Stamtąd możesz po prostu sklonować ~/Dropbox/git/project.gitpowiązanie ze swoim kontem Dropbox (lub udostępnić ten katalog innym osobom), możesz wykonać wszystkie normalne operacje Git i zostaną one automatycznie zsynchronizowane ze wszystkimi innymi komputerami.

Napisałem post na blogu, „ Kontrola wersji” ( stary link nie ^żyje ) na temat mojego rozumowania i sposobu konfiguracji środowiska. Opiera się on na doświadczeniu programistycznym Ruby on Rails , ale tak naprawdę można go zastosować do wszystkiego.

Właściwym sposobem na to jest użycie git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

Utworzenie własnego nagiego repozytorium w Dropbox powoduje wiele problemów. Anish (twórca biblioteki) wyjaśnia to najlepiej :

Główną przyczyną tych problemów jest to, że klient pulpitu Dropbox jest przeznaczony do synchronizacji plików, a nie repozytoriów Git. Bez specjalnej obsługi repozytoriów Git nie zachowuje takich samych gwarancji jak Git. Operacje na zdalnym repozytorium nie są już atomowe, a jednoczesne operacje lub pechowe synchronizowanie mogą spowodować uszkodzenie repozytorium.

Tradycyjne piloty Git uruchamiają kod po stronie serwera, aby to działało poprawnie, ale nie możemy tego zrobić.

Rozwiązanie: Możliwe jest prawidłowe rozwiązanie tego problemu. Można używać Git z Dropbox i mieć takie same gwarancje bezpieczeństwa i spójności, jak tradycyjny pilot Git, nawet jeśli jest wielu użytkowników i wykonywane są jednocześnie operacje!

Dla użytkownika jest to tak proste, jak użycie git-remote-dropbox, zdalnego pomocnika Git, który działa jak przezroczysty dwukierunkowy most pomiędzy Git i Dropbox i zachowuje wszystkie gwarancje tradycyjnego pilota Git. Korzystanie z folderów współdzielonych jest nawet bezpieczne, więc można z niego korzystać do współpracy (nielimitowane prywatne repozytoria z nieograniczoną liczbą współpracowników!).

Za pomocą zdalnego pomocnika można używać Dropboksa jako pilota Git i nadal używać wszystkich zwykłych poleceń Git, takich jak klon git, pull git i git push, a wszystko będzie działać zgodnie z oczekiwaniami.

Ta odpowiedź jest oparta na doświadczeniu Mercurial , a nie na Git, ale doświadczenie to mówi, że korzystanie z Dropbox w ten sposób prosi o uszkodzone repozytoria, jeśli istnieje nawet szansa, że ​​będziesz aktualizować to samo repozytorium oparte na Dropbox z różnych komputerów w różnych momentach (Mac, Unix, Windows w moim przypadku).

Nie mam pełnej listy rzeczy, które mogą się nie udać, ale oto konkretny przykład, który mnie ugryzł. Każda maszyna ma swoje własne pojęcie o znakach kończących wiersze oraz o tym, jak w nazwach plików obsługiwane są wielkie / małe litery. Dropbox i Git / Mercurial radzą sobie z tym nieco inaczej (nie pamiętam dokładnych różnic). Jeśli Dropbox zaktualizuje repozytorium za plecami Git / Mercurial, repozytorium uszkodzone. Dzieje się to natychmiast i niewidocznie, więc nawet nie wiesz, że twoje repozytorium jest uszkodzone, dopóki nie spróbujesz coś z niego odzyskać.

Po wykopaniu się z jednego bałaganu i robieniu tego w ten sposób, korzystam z następującego przepisu z wielkim sukcesem i bez oznak problemów. Po prostu przenieś swoje repozytorium poza Dropbox. Użyj Dropbox do wszystkiego innego; dokumentacja, pliki JAR , cokolwiek zechcesz. I użyj GitHub (Git) lub Bitbucket (Mercurial) do zarządzania samym repozytorium. Oba są bezpłatne, więc to nic nie zwiększa kosztów, a każde narzędzie wykorzystuje teraz swoje zalety.

Uruchomienie Git / Mercurial na Dropbox nie dodaje nic oprócz ryzyka. Nie rób tego

W odniesieniu do małych zespołów korzystających z Dropbox:

Jeśli każdy programista ma własne zapisywalne repozytorium na Dropbox, które jest pobierane tylko dla innych programistów, ułatwia to dzielenie kodu bez ryzyka uszkodzenia!

Następnie, jeśli chcesz scentralizowanej „linii głównej”, możesz mieć jednego programistę, który zarządza wszystkimi wypchnięciami do niego z własnego repozytorium.

Nie chciałem umieszczać wszystkich moich projektów w jednym repozytorium Git, ani nie chciałem wchodzić i uruchamiać tego kodu dla każdego projektu, więc stworzyłem skrypt Bash , który zautomatyzuje ten proces. Możesz użyć go w jednym lub wielu katalogach - dzięki czemu może on zrobić kod w tym poście dla ciebie lub może to zrobić w wielu projektach jednocześnie.

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

Nie sądzę, aby korzystanie z Git i Dropbox było dobrym rozwiązaniem ... Pomyśl tylko o funkcjach obu:

Git:

• Pozwala mieć centralne repozytorium
• Pozwala mieć własne repozytorium z własnymi zmianami
• Umożliwia wysyłanie i odbieranie zmian z centralnego repozytorium
• Pozwala wielu osobom na zmianę tych samych plików, a one łączą je lub prosi o scalenie, jeśli nie jest w stanie tego zrobić
• Ma klientów internetowych i stacjonarnych, aby umożliwić dostęp do centralnego repozytorium

Dropbox:

• Przechowuje wszystko w centralnym repozytorium
• Pozwala mieć własne wersje plików na serwerze
• Zmusza do wysyłania i odbierania zmian z centralnego repozytorium
• Jeśli wiele osób zmieni te same pliki, pierwszy zatwierdzony plik zostanie zastąpiony późniejszymi zatwierdzeniami i nie dojdzie do scalenia, co jest kłopotliwe (i zdecydowanie jego największą wadą)
• Ma klientów internetowych i stacjonarnych, aby umożliwić dostęp do centralnego repozytorium.

A jeśli martwisz się udostępnianiem niektórych swoich plików, dlaczego nie zaszyfrować ich? A potem możesz uzyskać największą korzyść Dropbox z Git, to znaczy mieć pliki publiczne i prywatne ...

Jest teraz 2015 r., A trzy dni temu zostało utworzone nowe narzędzie oparte na API Dropbox v2 , aby bezpiecznie korzystać z git na Dropbox. Działa przeciwko interfejsowi API zamiast przy użyciu klienta pulpitu i poprawnie obsługuje wiele jednoczesnych wypychań do repozytorium hostowanego w folderze współdzielonym.

Po skonfigurowaniu umożliwia skonfigurowanie pilota git dokładnie tak, jak każdego innego pilota git.

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

Używam Mercurial (lub Git) + TrueCrypt + Dropbox do szyfrowania zdalnych kopii zapasowych .

Najfajniejsze jest to, że Dropbox NIE synchronizuje całego kontenera TrueCrypt, jeśli zmodyfikujesz niewielką część kodu. Czas synchronizacji jest mniej więcej proporcjonalny do ilości zmian. Mimo że jest szyfrowany, połączenie TrueCrypt + Dropbox doskonale wykorzystuje synchronizację szyfru blokowego + synchronizację poziomu bloku.

Po drugie, monolityczny zaszyfrowany pojemnik nie tylko zwiększa bezpieczeństwo, ale także zmniejsza ryzyko uszkodzenia repozytorium .

Uwaga: Należy jednak bardzo uważać, aby nie zamontować kontenera podczas działania Dropbox. Rozwiązywanie konfliktów może być również utrudnione, jeśli 2 różnych klientów zamelduje różne wersje kontenera. Jest to więc praktyczne tylko dla jednej osoby używającej go do tworzenia kopii zapasowych, a nie dla zespołu.

Ustawiać:

• Utwórz kontener Truecrypt (wiele Gigabyte jest w porządku)
• W preferencjach Truecrypt usuń zaznaczenie preserve modification timestamp*.
• Utwórz repo, jak wspomniano powyżej przez Dan ( https://stackoverflow.com/a/1961515/781695 )

Stosowanie:

• Zamknij Dropbox
• Zamontuj pojemnik, pchnij zmiany, odmontuj
• Uruchom dropbox

PS Odznaczenie preserve modification timestampdropbox informuje, że plik został zmodyfikowany i należy go zsynchronizować. Pamiętaj, że zamontowanie kontenera modyfikuje znacznik czasu, nawet jeśli nie zmienisz w nim żadnego pliku. Jeśli nie chcesz, aby tak się stało, po prostu zamontuj wolumin jakoread-only

Uwielbiam odpowiedź Dana McNevina! Używam teraz Git i Dropbox razem i używam kilku aliasów w moim .bash_profile, więc mój przepływ pracy wygląda następująco:

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

Oto moje pseudonimy:

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'

Używamy tej metody (tworzenie nagiego repozytorium w Dropbox) w folderze udostępniania .

Niewielka grupa programistów może pobrać z tego zsynchronizowanego repozytorium i utworzyć lokalny klon. Po zakończeniu jednostki pracy cofamy się do źródła.

Jedną z rzeczy, których mi brakuje, jest dobry sposób na wysłanie wiadomości e-mail z informacjami o zestawie zmian, gdy nastąpi wypychanie do źródła. Używamy Google Wave do ręcznego śledzenia zmian.

Używam Mercurial w zalecany sposób i zachęcam do zachowania ostrożności, szczególnie jeśli którakolwiek z maszyn różni się. Fora Dropbox są pełne skarg na tajemnicze problemy z nazwami plików pojawiające się spontanicznie. Hg (i przypuszczam, że Git) nie zauważy ani nie narzeka podczas rutynowych kontroli, a usłyszysz o korupcji tylko wtedy, gdy narzeka na zepsute repo, gdy próbujesz go użyć naprawdę. Złe wieści. Chciałbym być bardziej szczegółowy na temat problemu i jego obejść; Nadal sam próbuję wydostać się z tego bałaganu.

Istnieje również projekt open source (zbiór skryptów między platformami [Linux, Mac, Win]), który wykonuje wszystkie drobiazgowe szczegóły zarządzania repozytorium za pomocą kilku (3-4) poleceń.

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

Przykładowe użycie to:

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

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

Po czym normalne użycie git:

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

Sprawdź wiki projektu i podręczniki, aby uzyskać pełne informacje na temat poleceń i samouczki.

Przechowuję moje repozytorium inne niż Github na Dropbox. Jednym zastrzeżeniem, na które natrafiłem, była synchronizacja po ponownej instalacji. Dropbox najpierw pobierze najmniejsze pliki, zanim przejdzie do większych. Nie stanowi problemu, jeśli zaczniesz w nocy i wrócisz po weekendzie :-)

Mój wątek - http://forums.dropbox.com/topic.php?id=29984&replies=6

Teraz w 2014 roku bez problemu korzystam z Git i Dropbox od około półtora roku. Niektóre punkty:

• Wszystkie moje maszyny korzystające z Dropbox są w systemie Windows, różne wersje (od 7 do 8) + 1 mac.
• Nie udostępniam repozytorium komuś innemu, więc jestem jedynym, który go modyfikuje.
• git push wypycha do zdalnego repozytorium, więc jeśli kiedykolwiek zostanie uszkodzony, mogę go łatwo odzyskać.
• Musiałem tworzyć aliasy w C:\Usersz mklink /D link targetponieważ niektóre biblioteki wskazał bezwzględnych lokalizacjach.

Podoba mi się najlepiej głosowana odpowiedź Dana McNevina. Skończyłem robić sekwencję poleceń git zbyt wiele razy i postanowiłem napisać skrypt. Oto on:

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

Skrypt wymaga tylko nazwy projektu. Wygeneruje repozytorium git ~/Dropbox/git/pod podaną nazwą i przepchnie całą zawartość bieżącego katalogu do nowo utworzonej gałęzi master pochodzenia. Jeśli podano więcej niż jedną nazwę projektu, użyty zostanie argument znajdujący się najbardziej po prawej stronie.

Opcjonalnie argument -r komendy określa gałąź zdalną, która będzie przekazywać do wzorca początkowego. Położenie wzorca początkowego projektu można również określić za pomocą argumentu -m. Domyślny plik .gitignore znajduje się również w zdalnym katalogu oddziału. Domyślne ustawienia katalogu i pliku .gitignore są określone w skrypcie.

Inne podejście:

Wszystkie dotychczasowe odpowiedzi, w tym najpopularniejsza odpowiedź @Dan , odnoszą się do pomysłu korzystania z Dropbox w celu scentralizowania wspólnego repozytorium zamiast korzystania z usługi skoncentrowanej na git takich jak github, bitbucket itp.

Ponieważ jednak oryginalne pytanie nie precyzuje, co tak naprawdę oznacza „Git i Dropbox razem”, przyjmijmy inne podejście: „Używanie Dropbox do synchronizacji tylko drzewa roboczego”.

Poradnik ma następujące kroki:

1. wewnątrz katalogu projektu tworzy się pusty .gitkatalog (np. mkdir -p myproject/.git)

2. zsynchronizuj .gitkatalog w Dropbox. Jeśli używasz aplikacji Dropbox: przejdź do Preferencji, Synchronizuj i „wybierz foldery do synchronizacji”, gdzie .gitkatalog musi zostać niezaznaczony. Spowoduje to usunięcie .gitkatalogu.

3. uruchom git initw katalogu projektu

Działa to również, jeśli .gitjuż istnieje, wykonaj tylko krok 2. Dropbox zachowa kopię plików git na stronie internetowej.

Krok 2 spowoduje, że Dropbox nie zsynchronizuje struktury systemu git, co jest pożądanym rezultatem tego podejścia.

Dlaczego warto korzystać z tego podejścia?

• Nieprzesłane zmiany będą miały kopię zapasową Dropbox i zostaną zsynchronizowane na różnych urządzeniach.

• W przypadku, gdy Dropbox coś spieprzy podczas synchronizacji między urządzeniami, git statusi git diffprzydadzą się to rozwiązać.

• Oszczędza miejsce na koncie Dropbox (cała historia nie będzie tam przechowywana)

• Pozwala to uniknąć obaw wyrażonych przez @dubek i @Ates w komentarzach do odpowiedzi @ Dan oraz obaw przez @clu w innej odpowiedzi .

Istnienie pilota gdzieś indziej (github itp.) Będzie działało dobrze z tym podejściem.

Praca w różnych branżach wiąże się z pewnymi problemami, którymi należy się zająć:

• Jednym z potencjalnych problemów jest synchronizacja przez Dropbox (niepotrzebnie?) Potencjalnie wielu plików podczas sprawdzania różnych gałęzi.

• Jeśli dwa lub więcej zsynchronizowanych urządzeń Dropbox ma wyewidencjonowane różne gałęzie, niezatwierdzone zmiany na obu urządzeniach mogą zostać utracone,

Jednym ze sposobów obejścia tych problemów jest git worktreeprzechowywanie transakcji w oddziałach w osobnych katalogach.

W przypadku moich 2 centów Dropbox robi tylko użytek osobisty, gdzie nie chcesz zawracać sobie głowy centralnym hostem repo. W przypadku jakiegokolwiek rozwoju zawodowego prawdopodobnie stworzysz więcej problemów niż do rozwiązania, jak już wspomniano kilka razy w wątku, Dropbox nie jest przeznaczony do tego przypadku użycia. To powiedziawszy, całkowicie bezpieczną metodą zrzucania repozytoriów na Dropbox bez żadnych wtyczek i narzędzi innych firm jest użycie pakietów. Mam następujące aliasy, .gitconfigaby zapisać pisanie:

[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 #"

Przykład:

# 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

Napotkałem podobny problem i stworzyłem mały skrypt dla tego samego. Chodzi o to, aby używać Dropbox z Git tak prosto, jak to możliwe. Obecnie szybko zaimplementowałem kod Ruby i wkrótce dodam więcej.

Skrypt jest dostępny pod adresem https://github.com/nuttylabs/box-git.

Bez korzystania z narzędzi integracji innych firm mógłbym nieco poprawić ten stan i korzystać z DropBox i innych podobnych usług dyskowych w chmurze, takich jak SpiderOak z Git.

Celem jest uniknięcie synchronizacji w środku tych modyfikacji plików, ponieważ może przesłać stan częściowy, a następnie pobrać go z powrotem, całkowicie niszcząc twój stan git.

Aby uniknąć tego problemu:

1. Spakuj mój indeks git w jednym pliku, używając git bundle create my_repo.git --all.
2. Ustaw opóźnienie monitorowania pliku, np. 5 minut, zamiast natychmiastowego. Zmniejsza to szanse DropBox synchronizuje stan częściowy w trakcie zmiany. Pomaga również znacznie podczas modyfikowania plików na dysku w chmurze w locie (na przykład w przypadku aplikacji do natychmiastowego zapisywania notatek).

Nie jest idealny, ponieważ nie ma gwarancji, że nie zepsuje ponownie stanu git, ale pomaga i na razie nie mam problemu.

W systemie MacOS możesz także zatrzymać Dropbox, wprowadzić zmiany, a następnie ponownie uruchomić Dropbox. Korzystam z następującej kombinacji i jestem z tego całkiem zadowolony:

Zarówno (lokalny katalog projektu zarządzanego przez git, jak i zdalne repozytorium git znajdujące się na Dropbox) uruchom następujące polecenie, aby wyłączyć automatyczne pakowanie (co jest głównym problemem z synchronizacją Dropbox)

git config --global gc.auto 0

Następnie od czasu do czasu kompresuj repozytoria z wyłączonym Dropbox. Na przykład robię następujące rzeczy w moim skrypcie bash-build-script, kiedy robię nowe wersje moich aplikacji.

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