Il modo migliore per utilizzare il controllo del codice sorgente per un progetto (1-3 persone)

Con gli SCM distribuiti come git o mercurial (che è quello che usa bitbucket), la ramificazione è ancora possibile ma spesso non necessaria. Quello che fai invece è (flusso di lavoro di base):

• Configura un repository in una posizione accessibile a tutti gli sviluppatori (una condivisione di rete, un server sul quale le persone possono eseguire ssh, un servizio di terze parti come github o bitbucket). Questo sarà il tuo autorevole repository.
• Clona questo repository sul computer di ogni sviluppatore e fai tutto ciò che è necessario per creare un ambiente di sviluppo adatto.
• Lavora sulla tua copia locale; commetti quando vuoi. I commit sono locali, quindi non farai del male a nessuno. Assicurati di prelevare dal repository centrale di volta in volta, in modo che la tua copia locale non vada fuori sincrono.
• Quando hai qualcosa che pensi sia pronto per la produzione, spinga dal tuo clone locale al repository centrale.
• Sul repository centrale, ogni volta che si ha una versione che si desidera contrassegnare come release candidate, taggala. In questo modo, è possibile aggiornare successivamente un determinato clone alla versione esatta.

Poiché gli SCM distribuiti consentono cloni illimitati al proprio repository e ogni clone può fungere da master, è possibile creare flussi di lavoro più complessi da questa base. Ad esempio, puoi avere diversi repository centrali: uno per lo sviluppo, uno per il QA, uno per la produzione. È possibile utilizzare un clone dedicato solo per un server di build. Puoi usare più di un clone localmente; invece di ramificare, basta creare un altro clone e, se non funziona, lo si elimina semplicemente.

Un altro vantaggio è che se il repository centrale va oltre le riparazioni, ne avrai ancora diverse copie; tutto quello che devi fare è clonare il repository di uno sviluppatore sul server centrale e tutto va bene (perdi le modifiche senza commit sul server centrale, ma idealmente, nessuno dovrebbe apportare modifiche direttamente lì comunque, quindi l'unica cosa che rimane da fare è per tutti spingere di nuovo le ultime modifiche).

Il monitoraggio dei database è difficile; normalmente, si desidera tracciare la struttura, ma non i dati: i dati cambiano molto, non sono rilevanti per il codice e possono contenere informazioni sensibili che non è possibile rendere accessibili in questo modo. Un approccio comune consiste nel creare uno script che configura il database nella sua forma attuale e forse un altro che lo popola con i dati di test tipici. In alternativa, puoi tenere traccia degli script di modifica incrementale: avrai uno script che crea il database come progettato il primo giorno, e poi un gruppo di script che, se applicati in ordine, modificano il database fino a quando non si finisce con l'attuale stato delle cose. Tuttavia, sono meno affidabili delle modifiche al codice di tracciamento e richiedono più lavoro manuale, quindi qualunque cosa tu faccia, vuoi avere un buon piano di backup / ripristino per il tuo database di produzione.

Penso che le tue preoccupazioni riguardo al git siano state ben trattate. Il miglior VC per i database che ho visto è DB Ghost , o in almeno il suo concetto. Stiamo cercando di adattarlo a come vC anche il nostro database in un modo preferibilmente gratuito.

Puoi utilizzare mysqldump per tenere traccia dello stato del database in git . Qualsiasi cosa che il tuo progetto utilizza (immagini e altri dati binari) non dovrebbe essere escluso (al di fuori dei file compilati, come * .pyc). Se le risorse di sistema sono un problema, guarda usando bitbucket invece di git. Puoi ospitare una quantità illimitata di piccoli progetti privati gratuitamente (< = 5 sviluppatori credo).

In un'altra nota, io raramente vedo qualcuno che usa più rami (è soooo SVN;)). La maggior parte delle persone non fa che dare suggerimenti e taggano quando sono contenti di ciò che hanno.

In un'esperienza simile per quanto riguarda il monitoraggio delle modifiche del database, gestiamo semplicemente la struttura del database. Utilizzando un ORM come NHibernate puoi preoccuparti dei mapping HBM altrimenti puoi sempre mantenere gli script della struttura del database.

Ecco un semplice script php (l'ho chiamato dbschema.php) che restituisce lo schema del database in un formato semplice.

Eseguilo come: ./dbschema db name db user db pass > schema.txt

Quindi metti l'output schema.txt sotto controllo di versione e hai una soluzione.

Ogni volta che cambi lo schema, riesegui lo script.

Il codice è:

#!/usr/bin/php -q
<?
if (!isset($_SERVER["argv"][1])) die("ERROR: Need arguments\n");
if (!isset($_SERVER["argv"][3])) die("ERROR: Too few arguments\n");
$db_name=$_SERVER["argv"][1];
$db_user = $_SERVER["argv"][2];
$db_pass = $_SERVER["argv"][3];
mysql_connect('localhost', $db_user, $db_pass) or die ("ERROR: Could not connect to the database server\n"); 
$use_query="Use $db_name";
$use_result=mysql_query($use_query) or die("Error using " . $db_name . " | " . mysql_error());

// show the tables of the currently selected database    
$table_query="show tables";
$table_result=mysql_query($table_query) or die("ERROR: Error getting a list of tables from " . $db_name . " | " . mysql_error());
while($table_row=mysql_fetch_row($table_result))
{
    $table_name=$table_row[0];
    echo "\n"."TABLE NAME " . $table_name . "\n";
    // now describe the selected table
    $field_query="describe $table_name";
    $field_result=mysql_query($field_query) or die("Error describing the table " . $table_name . " | " . mysql_error());
    while($field_row=mysql_fetch_row($field_result))
    {
        if (strlen($field_row[0]) >= 16){ $tab = "\t";}
        elseif (strlen($field_row[0]) >= 8){ $tab = "\t\t";}
        else{ $tab = "\t\t\t";}
        echo "$field_row[0]". $tab .$field_row[1]. "\n";
        }
}
?>

Mi piace molto la risposta di Tammer!

L'unica cosa che vorrei aggiungere è:

Per affrontare il problema di troppi file tracciati come le immagini, forse queste directory potrebbero essere aggiunte a .gitignore e gestite separatamente. Tuttavia questa non è una grande soluzione. Probabilmente stai meglio acquistando una macchina più potente se pensi che la potenza della macchina sia un problema. Considera sempre il tuo tempo X la tua tariffa oraria in quel calcolo dei costi.