Hoe gebruik je Git en Dropbox samen?

Is het mogelijk om Giten Dropboxsamen?

Antwoord 1, autoriteit 100%

Ik denk dat Git op Dropbox geweldig is. Ik gebruik het de hele tijd. Ik heb meerdere computers (twee thuis en één op het werk) waarop ik Dropbox als centrale kale repository gebruik. Omdat ik het niet op een openbare dienst wil hosten en ik geen toegang heb tot een server waar ik altijd naar kan SSH-en, zorgt Dropbox hiervoor door op de achtergrond te synchroniseren (zeer snel).

Setup is ongeveer als volgt:

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

Vanaf daar kun je gewoon die map ~/Dropbox/git/project.gitklonen (ongeacht of deze bij je Dropbox-account hoort of door meerdere accounts wordt gedeeld) en al het normale Git-bewerkingen: ze worden automatisch gesynchroniseerd met al uw andere machines.

Ik heb een blogbericht geschreven “On Version Control” waarin ik de redenering achter mijn omgevingsconfiguratie behandel. Het is gebaseerd op mijn Ruby on Railsontwikkelingservaring, maar het kan eigenlijk op alles worden toegepast.

Antwoord 2, autoriteit 10%

De juiste manier om dit te doen is door git-remote-dropbox te gebruiken: https://github.com/anishathalye/git -remote-dropbox

Het maken van je eigen kale repo in Dropbox veroorzaakt veel problemen. Anish (de maker van de bibliotheek) legt het het beste uit:

De hoofdoorzaak van deze problemen is dat het Dropbox-bureaublad
client is ontworpen voor het synchroniseren van bestanden, niet voor Git-repositories. Zonder
speciale behandeling voor Git-repositories, het onderhoudt niet hetzelfde
garanties als Git. Bewerkingen op de externe repository zijn niet langer
atomaire en gelijktijdige operaties of ongelukkige timing met
synchronisatie kan resulteren in een beschadigde repository.

Traditionele Git-afstandsbedieningen voeren code uit aan de serverzijde om dit te laten werken
goed, maar dat kunnen we niet.

Oplossing: Het is mogelijk om dit goed op te lossen. Het is mogelijk om te gebruiken
Git met Dropbox en hebben dezelfde veiligheids- en consistentiegaranties
als een traditionele Git-afstandsbediening, zelfs als er meerdere gebruikers zijn en
gelijktijdige bewerkingen!

Voor een gebruiker is het net zo eenvoudig als het gebruik van git-remote-dropbox, een Git-afstandsbediening
helper die fungeert als een transparante bidirectionele brug tussen Git en
Dropbox en behoudt alle garanties van een traditionele Git-afstandsbediening.
Het is zelfs veilig om te gebruiken met gedeelde mappen, dus het kan worden gebruikt voor:
samenwerking (yay onbeperkt privé repo’s met onbeperkt
medewerkers!).

Met de externe helper is het mogelijk om Dropbox als Git-afstandsbediening te gebruiken
en blijf alle reguliere Git-commando’s gebruiken, zoals git clone, git
pull, en git push, en alles zal gewoon werken zoals verwacht.

Antwoord 3, autoriteit 6%

Dit antwoord is gebaseerd op Mercurial-ervaring, niet Git, maar deze ervaring zegt dat het gebruik van Dropbox op deze manier vraagt ​​om corrupte repository’s als er een kans is dat je dezelfde op Dropbox gebaseerde repository op verschillende tijdstippen vanaf verschillende machines bijwerkt (Mac, Unix, Windows in mijn geval).

Ik heb geen volledige lijst van de dingen die fout kunnen gaan, maar hier is een specifiek voorbeeld dat me beet. Elke machine heeft zijn eigen idee van regeleindtekens en hoe hoofdletters en kleine letters worden verwerkt in bestandsnamen. Dropbox en Git/Mercurial gaan hier iets anders mee om (ik herinner me de exacte verschillen niet). Als Dropbox de repository achter Git/Mercurial’s back, presto, kapotte repository bijwerkt. Dit gebeurt onmiddellijk en onzichtbaar, dus je weet niet eens dat je repository kapot is totdat je er iets van probeert te herstellen.

Nadat ik uit een puinhoop heb gegraven om dingen op deze manier te doen, heb ik het volgende recept met groot succes gebruikt en geen teken van problemen. Verplaats eenvoudig je repository uit Dropbox. Gebruik Dropbox voor al het andere; documentatie, JAR-bestanden, alles wat je maar wilt. En gebruik GitHub(Git) of Bitbucket(Mercurial) om de repository zelf te beheren. Beide zijn gratis, dus dit voegt niets toe aan de kosten, en elke tool speelt nu in op zijn sterke punten.

Git/Mercurial gebruiken bovenop Dropbox voegt niets toe, behalve risico. Doe het niet.

Antwoord 4

Ik wilde niet al mijn projecten onder één Git-repository plaatsen, en ik wilde ook niet naar binnen gaan om deze code voor elk afzonderlijk project uit te voeren, dus maakte ik een Bash-script dat het proces automatiseert. Je kunt het op een of meerdere mappen gebruiken – dus het kan de code in dit bericht voor je doen of het kan het op meerdere projecten tegelijk doen.

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

Antwoord 5

Met betrekking tot kleine teams die Dropbox gebruiken:

Als elke ontwikkelaar zijn eigen beschrijfbare kale repository op Dropbox heeft, die alleen pull-onlyis voor andere ontwikkelaars, dan vergemakkelijkt dit het delen van code zonder risico op corruptie!

Als u een gecentraliseerde ‘hoofdlijn’ wilt, kunt u één ontwikkelaar alle push-ups ernaartoe laten beheren vanuit zijn eigen repo.

Antwoord 6

Het is nu 2015, en sinds drie dagen geleden is er een op nieuwe toolgebaseerd op Dropbox API v2is gemaakt om git veilig te gebruiken op Dropbox. Het werkt tegen de API in in plaats van de desktopclient te gebruiken, en verwerkt correct meerdere gelijktijdige pushs naar een repository die wordt gehost in een gedeelde map.

Eenmaal geconfigureerd, kan men een git remote precies instellen zoals elke andere git remote.

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

Antwoord 7

Ik denk niet dat het gebruik van Git en Dropbox de juiste keuze is… Denk eens aan de functies van beide:

Git:

• Hiermee kunt u een centrale opslagplaats hebben
• Hiermee kunt u uw eigen repository hebben met uw eigen wijzigingen
• Hiermee kunt u wijzigingen verzenden en ontvangen vanuit de centrale opslagplaats
• Sta meerdere personen toe om dezelfde bestanden te wijzigen en ze voegen ze samen of vragen je om ze samen te voegen als dit niet mogelijk is
• Heeft web- en desktopclients om toegang tot de centrale repository toe te staan

Dropbox:

• Bewaart alles in een centrale repository
• Hiermee kunt u uw eigen versies van de bestanden op de server hebben
• Dwingt u om wijzigingen te verzenden en te ontvangen vanuit de centrale repository
• Als meerdere personen dezelfde bestanden wijzigen, wordt het eerste vastgelegde bestand vervangen door latere vastleggingen en vindt er geen samenvoeging plaats, wat lastig is (en zeker het grootste nadeel)
• Heeft web- en desktopclients om toegang tot de centrale repository toe te staan.

En als u zich zorgen maakt over het delen van sommige van uw bestanden, waarom zou u ze dan niet coderen? En dan zou je het grootste voordeel van Dropbox to Git kunnen krijgen, namelijk om openbare en privébestanden te hebben…

Antwoord 8

Ik gebruik Mercurial (of Git) + TrueCrypt + Dropbox voor gecodeerdeexterne back-ups.

Het coolste is dat Dropbox NIET de hele TrueCrypt-container synchroniseert als je een klein deel van je code aanpast. De synchronisatietijd is ongeveer evenredig met het aantal wijzigingen. Ook al is het versleuteld, de combinatie van TrueCrypt + Dropbox maakt uitstekend gebruik van blokcijfer + blokniveausynchronisatie.

Ten tweede voegt een monolithisch versleutelde container niet alleen veiligheid toe, maar verkleint het ook de kans op repository corruptie.

Let op:je moet echter heel voorzichtig zijn dat je de container niet aankoppelt terwijl Dropbox actief is. Het kan ook lastig zijn om conflicten op te lossen als 2 verschillende clients verschillende versies van de container inchecken. Het is dus alleen praktisch voor een enkele persoon die het voor back-ups gebruikt, niet voor een team.

Instellen:

• Maak een Truecrypt-container (meerdere Gigabyte is prima)
• Vink onder Truecrypt-voorkeuren het vinkje weg voor preserve modification timestamp*.
• Maak een repo zoals hierboven vermeld door Dan ( https://stackoverflow.com/a/1961515/781695)

Gebruik:

• Dropbox afsluiten
• Bevestig de container, druk op uw wijzigingen, ontkoppel
• Dropbox uitvoeren

P.S. Als je de preserve modification timestampuitschakelt, weet dropbox dat het bestand is gewijzigd en moet worden gesynchroniseerd. Merk op dat het monteren van de container de tijdstempel wijzigt, zelfs als u er geen enkel bestand in wijzigt. Als u niet wilt dat dit gebeurt, koppelt u het volume gewoon als read-only

Antwoord 9

We gebruiken deze methode (een kale repository maken in Dropbox) op een gedeelde map.

Een kleine groep ontwikkelaars kan uit die kale gesynchroniseerde repository halen en een lokale kloon maken. Zodra de werkeenheid klaar is, gaan we terug naar de oorsprong.

Eén ding dat ik mis is een goede manier om een ​​e-mail te sturen met de wijzigingsgegevens zodra er een push to origin plaatsvindt. We gebruiken Google Wave om handmatig wijzigingen bij te houden.

Antwoord 10

Ik ben dol op het antwoord van Dan McNevin! Ik gebruik Git en Dropbox nu ook samen, en ik gebruik verschillende aliassen in mijn .bash_profiledus mijn workflow ziet er als volgt uit:

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

Dit zijn mijn aliassen:

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'

Antwoord 11

Ik heb Mercurial op de aanbevolen manier gebruikt en verzoek u dringend voorzichtig te zijn, vooral als een van de machines verschilt. De Dropbox-fora staan ​​vol met klachten over mysterieuze problemen met bestandsnamen die spontaan opduiken. Hg (en ik neem aan dat Git) zal het niet merken of klagen tijdens routinecontroles en je zult alleen over de corruptie horen wanneer het klaagt over een corrupte repo wanneer je het echt probeert te gebruiken. Slecht nieuws. Ik wou dat ik specifieker kon zijn over het probleem en de oplossingen; Ik probeer zelf nog steeds uit deze puinhoop te graven.

Antwoord 12

Er is ook een open source-project (een verzameling cross-platform [Linux, Mac, Win]-scripts) dat alle details van het repositorybeheer doet met een handvol (3-4) commando’s.

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

Voorbeeld van gebruik is:

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

Waarna normaal git-gebruik:

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

Bekijk de projectwiki en de handleidingen voor volledige opdrachtreferentie en zelfstudies.

Antwoord 13

Ik bewaar mijn niet-Github-repo’s op Dropbox. Een waarschuwing die ik tegenkwam, was het synchroniseren na een herinstallatie. Dropbox downloadt eerst de kleinste bestanden voordat het naar de grotere gaat. Geen probleem als je ‘s avonds begint en na het weekend terugkomt 🙂

Mijn discussie – http://forums.dropbox.com/topic .php?id=29984&replies=6

Antwoord 14

In 2014 gebruik ik Git en Dropbox nu ongeveer anderhalf jaar zonder problemen.
Enkele punten echter:

• Al mijn machines die Dropbox gebruiken, draaien op Windows, verschillende versies (7 tot 8) + 1 mac.
• Ik deel de repository niet met iemand anders, dus ik ben de enige die deze kan wijzigen.
• git pushpusht naar een externe repository, zodat als het ooit beschadigd raakt, ik het gemakkelijk kan herstellen.
• Ik moest aliassen maken in C:\Usersmet mklink /D link targetomdat sommige bibliotheken naar absolute locaties werden verwezen.