Gestisci il controllo della versione con un server di sviluppo centrale (LAMP)

Sei sulla strada giusta, qui.

Maybe with different directories for each developer.

Sì, directory decisamente diverse per ogni sviluppatore.

La macchina su cui ti trovi è piuttosto poco interessante. Assicurati solo che ogni sviluppatore acceda come se stesso, e controlli una copia del repository git sotto la sua home directory. Ti ritroverai con diverse copie del codice che vivono nel tuo filesystem, ma hey, il disco è gratuito.

È vero che git supporta l'operazione decentralizzata . Ma non lo userai in quel modo nel tuo tipico flusso di lavoro. Assicurati solo che un repository completo sia disponibile su un server conveniente e che tutti possano farlo. Accedilo tramite http, ssh o anche tramite il filesystem, se lo desideri.

Hai citato un'area "tryout" come parte del tuo flusso di lavoro. Fatti un favore Assumi un altro sviluppatore, chiamato Jenkins, che controlla anche il tuo codice usando git. È implementato qui: link (e gira sotto link ). In questo modo ogni spinta verso il repository centrale renderà immediatamente disponibile una versione aggiornata del tuo sito web nella home directory di Jenkins, dove potrai provarlo rapidamente ed eseguire controlli di integrità. Chiamiamo questa integrazione continua e sicuramente migliorerà il tuo flusso di lavoro.

 It's maybe important to say that while it became a factor for us it is still uncommon that multiple developers work on the same part of an application at the same time.

Se poche persone lavorano sulla stessa macchina e sulla stessa base di codice, le cose devono andare storte. A causa della sovrascrittura e perché se uno si rompe qualcosa gli altri devono aspettare fino a quando non risolvono i problemi per testare la loro roba.

Devi distinguere alcuni ambienti. Sembra che tu abbia bisogno di tre (molto comuni):

• Produzione - in cui il progetto viene effettivamente utilizzato dagli utenti finali.
• Staging : luogo in cui lo sviluppatore fonde il suo lavoro con altri sviluppatori, lo mette alla prova e talvolta i clienti possono sbirciare in quest'area.
• Sviluppo - dove ogni sviluppatore lavora da solo, prima di fondersi con altri.

Solitamente l'ambiente di sviluppo significa che lo sviluppatore di macchine lavora. Se vuoi tenerlo su una macchina condivisa puoi farlo anche tu. Ambienti e macchine sono qualcosa di disaccoppiato. Devi solo avere una base di codice diversa per ogni progetto, ogni sviluppatore e ogni ambiente.

Quindi nel caso di Git e 5 sviluppatori in azienda ci sarebbero 5 repository per l'ambiente development . Per l'ambiente staging (codice di unione) perché non è una buona idea spingere verso repository non nudi occorrerebbe un repository per l'unione e un altro per testare il codice e mostrare lo stato corrente del client. Se il server produzione ha Git un altro lì. In caso contrario, trasferirai i file alla produzione tramite FTP dall'ambiente staging . Quindi pochi repository per ogni progetto.

E il flusso di lavoro è così: Lavori nel tuo ambiente sviluppo , quando hai aggiunto una funzionalità o corretto un bug, metti le tue modifiche all'ambiente staging nudo e lo estrai sul lato nudo (un Git hook potrebbe farlo subito), e quando il progetto è pronto per rilasciare una nuova versione, la spingere (o trasferire tramite FTP) alla produzione .

Some times we work on different computers, so when we forget to push our code we have a problem.

Bene, se devi fare l'ambiente development sullo stesso server condiviso puoi sincronizzare i tuoi file dalla macchina locale al server tramite qualcosa come rsync, o mappare un'unità di rete o altro, ma questo sempre sarà un po 'più lento quindi lavorando sulla macchina locale. Lavorare localmente ha tuttavia il problema che hai citato. Anche senza VCS. Come quando si utilizza FTP: se si modifica qualcosa sul proprio computer e si dimentica di trasferirlo, accade la stessa cosa. Ma non vorrai unire il tuo codice dissimulato all'ambiente staging di sicuro. Deve rimanere nello sviluppo finché non raggiunge uno stato di risonanza.

We would have to work with virtual machines because the dev servers should be the same as our live server (This would simply not be enforceable in our environment, believe me it's not possible).

I server wev senza GUI non utilizzano molte risorse. Penso che voi ragazzi potreste lavorare sul codice e testarlo sul proprio computer. Quindi development environment localy e solo staging sul server condiviso. Puoi controllare qualcosa come Vagrant per aiutare a gestire le immagini delle macchine virtuali. Quindi assicurati che ogni progetto abbia le giuste impostazioni. Ciò assicurerebbe che voi ragazzi testate allo stesso modo, siate più sicuri (ora se il server condiviso potrebbe violare nessuno può continuare a lavorare, e avete bisogno di avere un buon backup lì) e più veloce (nessun trasferimento è necessario fino alla fusione). Git è migliore di dieci SVN in questa materia perché mantiene il repository completo su ogni macchina con cronologia e tutto ciò, quindi se un pc si rompe ci sono ancora buone copie da qualche altra parte.

Anche cose come Gitosis possono aiutarti a gestire le impostazioni del repository di ambiente staging e Redmine o altri software di gestione dei progetti spesso hanno modi per integrarsi con VCS.

because git is some sort of becoming the "standard" and there are a lot of "pro git" people among the web users we tend to using git.

Questo non è un buon fondamento per fare scelte nel mondo SCM. Git non è "standard", ma piuttosto "fashion" con molto rumore attorno ad esso. "Pro Git" è più fanboyism, che decisione ragionevole e ragionata in molti casi

work togheter on the same project at the same time without overwriting our codes and simply gives us the advantage of version-control

I rami in qualsiasi SCM ti permetteranno di ottenerlo, anche con Git (parola chiave: "Git-flow")