Quale controllo del codice sorgente ho bisogno per un grande progetto in un'azienda media? [chiuso]

Question

Quale controllo del codice sorgente ho bisogno per un grande progetto in un'azienda media? [chiuso]

#1 da (29 voti)
#2 da (4 voti)
#3 da (4 voti)
#4 da (3 voti)
#5 da (3 voti)
#6 da (2 voti)
#7 da (2 voti)
#8 da (2 voti)
#9 da (0 voti)

10

So che Git è ottimo per i progetti open source. Ma mi stavo chiedendo: per un'azienda con 20 programmatori che lavorano su un progetto di un anno, quale sistema di controllo del codice sorgente è desiderabile? Da quello che ho sentito, Git usa tirare; non sarebbe meno che desiderabile avere bisogno di passare attraverso qualcun altro per ottenere i cambiamenti nel bagagliaio principale? Soprattutto quando tutti lavorano allo stesso tempo?

Questo è solo un esempio di cui mi stavo chiedendo. So come usare SVN, ma anche nel mio ultimo lavoro non l'abbiamo usato sui nostri progetti, poiché tutto è stato fatto in PHP e quelli erano in genere progetti standalone di 1 settimana. Ho appena avuto SVN per il mio codice locale e non ho avuto bisogno di usarlo con gli altri.

Quindi quali sono i buoni controlli sorgente e in particolare perché è utile?

version-control

posta Martin Maat 19.11.2010 - 17:10

fonte

9 risposte

Leggi altre domande sui tag version-control

C'è qualche differenza nell'apprendimento OOP su diversi linguaggi di programmazione? [chiuso] Rilavorazione di una funzione che restituisce un codice intero che rappresenta molti stati diversi

score 29 · Answer 1

Usa qualsiasi cosa con cui la tua squadra è a tuo agio. Tutti i sistemi di controllo versione eseguono all'incirca la stessa cosa in modi simili; non c'è motivo di reinventare la ruota perché "potrebbe funzionare meglio". Se la tua squadra non è a suo agio con nulla, scegli l'opzione che ha l'integrazione più semplice con l'IDE standard del tuo team.

score 4 · Answer 2

4

Mercurial è eccellente, distribuito e gratuito.

risposta data 19.11.2010 - 20:40

fonte

score 4 · Answer 3

Penso che dipenda dal livello di supporto di cui hai bisogno.

Uso git a casa per i miei progetti divertenti quando avere un problema mi costa tempo, ma posso passare il tempo a imparare ciò che mi serve per sistemarlo.

Al lavoro usiamo Perforce perché avere un supporto tecnico 24 ore su 24 è indispensabile. Abbiamo persone che lavorano sul codice a New York, in Germania, in Irlanda e in Giappone tutto il tempo. Se c'è un problema, dobbiamo ottenere una risposta il più presto possibile. Nella mia esperienza, le persone di Perforce sanno davvero cosa stanno facendo e sono ricettivi ai suggerimenti.

score 3 · Answer 4

Anche se penso che questa domanda sia ampia e debba essere indirizzata su base per azienda, sulla base del framework IT e delle strutture di rete / sviluppo, ritengo che l'aspetto più importante della scelta del controllo sorgente / versione non sia quale applicazione tu usi, ma se è utilizzato è praticamente strutturato e applicato.

La struttura e l'applicazione dell'uso sono gli aspetti più importanti del controllo della versione.

Pianifica in anticipo e coinvolgi tutti. Imponi l'utilizzo. Non solo con i programmatori, ma con tutto ciò che riguarda i progetti (documenti, immagini, ecc.).

SVN è una bella applicazione e può essere integrata con molti componenti aggiuntivi (incluso bug / tracciamento delle attività), non ha bisogno di un server separato ed è gratuita!

Ci sono anche altre buone applicazioni per il controllo del codice sorgente, come ha detto @EricBoersma:

Use whatever your team is comfortable with.

Devi solo disporre di procedure e best practice e acquistare da quelli che possono applicarle.

score 3 · Answer 5

Hai dei grossi equivoci su come funziona git. L'invio di una richiesta di pull a un gatekeeper è solo un modo per farlo. Ci sono molti altri modi per configurarlo, tra cui praticamente esattamente come svn, che è esattamente il numero di persone che iniziano prima di essere abbastanza constrongvoli da personalizzare. Con un git di tipo DVCS, hai abbastanza opzioni per strutturare il controllo del codice sorgente sul tuo flusso di lavoro, piuttosto che il contrario.

score 2 · Answer 6

Avevo l'impressione che il controllo del codice sorgente fosse solo uno strumento e che ciascuno dei prodotti facesse più o meno la stessa cosa. E poi il punto di questi sistemi di controllo della versione distribuita ha fatto clic su di me.

Il controllo della versione distribuita consente di avere più di un repository centrale. Immaginate le modifiche al codice che migrano dal repository di sviluppatori locali, al repository di funzionalità, al repository del prodotto, nel repository QA e infine nel repository rilasciato.

Personalmente uso un prodotto commerciale chiamato Kiln, basato su Hg, ma la funzione chiave è il controllo della versione distribuita . Rivoluziona il flusso del nuovo codice dallo sviluppatore in un prodotto rilasciato.

score 2 · Answer 7

Sai come usare SVN, quindi usa SVN - migra solo su un DVCS se c'è qualcosa in loro di cui hai bisogno.

Ciò che è veramente importante è che usi qualcosa che ti piacerà usare, che sia facile da usare. Martin Fowler ha fatto un semplice sondaggio sui VCS, il results sono molto interessanti.

score 2 · Answer 8

Ho creato git al mio ultimo lavoro in cui stavamo lavorando a un progetto di dimensioni simili (15 sviluppatori, 18 mesi di progetto) e ha funzionato bene.

Il modo in cui lo abbiamo impostato era:

Avevamo un server git che era il nostro autoritativo server git centralizzato. I membri del team sono stati scoraggiati dal tirare l'uno dall'altro direttamente in modo che tutte le modifiche andassero nel server centrale.

Abbiamo utilizzato il ramo principale come ramo di produzione principale, con tag per ogni versione. Ogni modulo del progetto era un sottomodulo git. Ogni sottomodulo aveva rami per ogni membro della squadra. Un manutentore (di solito l'autore originale) è stato assegnato a ciascun sottomodulo, ed erano responsabili della gestione delle richieste di pull da parte di altri membri del team e per l'invio di richieste di pull al lead del team che aggiornava il sottomodulo nel ramo principale quando era pronto per essere integrato nel ramo di produzione. Abbiamo utilizzato i tag per identificare i commit che hanno completato una funzione specifica o che corrispondevano a un rilascio.

score 0 · Answer 9

Darei a Team Foundation System (TFS) di Microsoft almeno una buona occhiata. Prendo dai tuoi commenti che non sei un negozio Microsoft. Tuttavia, la mia comprensione è che c'è un plug-in Eclipse abbastanza robusto se si utilizza quell'IDE per lo sviluppo.

I meccanismi di fusione e ramificazione funzionano come tutti gli altri sistemi di controllo del codice sorgente (meglio di svn, nella mia esperienza, e altrettanto efficaci di perforce), ma ciò che veramente brilla sono gli aspetti di monitoraggio del progetto e di gestione del progetto prodotto e l'automazione integrata per le build e le distribuzioni.

Se stai scrivendo un'applicazione basata sul Web, dai un'occhiata al framework di test dell'interfaccia utente automatico e al framework di testing del carico che puoi costruire e configurare in un ordine abbastanza breve. Una funzione elegante: simula i browser mobili integrati nel test di carico.