sicurezza del controllo della versione

non andare con Git solo perché è "abbastanza bello", usalo perché risolve il tuo problema in un modo che si adatta al tuo flusso di lavoro.

Come per TFS ... Martin Fowler ha effettuato un piccolo sondaggio .

In ogni caso, devi definire "sicurezza": vuoi proteggere la fonte da utenti non autorizzati, o mettere un flag di sola lettura su alcune aree, o addirittura impedire ad alcune persone di guardare alcune aree. È possibile farlo facilmente in SVN, utilizzare VisualSvn Server ed è possibile applicare i controlli di sicurezza r / rw su qualsiasi cartella nell'albero. TFS è lo stesso. Git, d'altra parte .. non è progettato per questo. Git funziona secondo il principio che tutta la sorgente viene "copiata" sulla workstation di ogni sviluppatore, in modo da ottenere tutto il tempo. Fa parte di ciò che rende git speciale - nel senso che una volta che hai tutta la fonte a livello locale, puoi unirle e diramarti rapidamente e facilmente, ma significa che non riesci a mettere le restrizioni aziendali su di esso.

La scelta del back-end non ha senso. Utilizzare un sistema basato su file o un sistema basato su SQLServer .. lo stesso, il livello di accesso di sicurezza dipende da ciò che lo strumento consente (e le politiche di amministrazione sui dati di back-end, un SQLServer con una password sa ' sa 'o anche l'autenticazione di Windows senza restrizioni consentirebbe a chiunque l'accesso al database).

He told me it's much more secure to use an SQL Sever based tool

Definisci (o chiedi al tuo capo) "sicuro": sicurezza dalla perdita di dati o dal controllo degli accessi?

Quest'ultimo è certamente più facile in TFS (e sospetto che sia ciò che lui / lei vuole). Quindi la domanda è: chi vuoi bloccare dall'accesso?

L'utilizzo di più repository Git con utenti limitati che eseguono richiami da altri nel "master" designato (da dove verranno rilasciati i rilasci) offrirebbe gran parte dello stesso controllo, contribuendo nel contempo a garantire che vengano eseguite le revisioni del codice.

(Ho usato la sicurezza TFS per bloccare alcuni sviluppatori ¹ dal check-in. Questa è stata una reazione alla terribile qualità ² del loro codice. per ottenere il codice, modificarlo ma non per effettuare il check-in, piuttosto hanno dovuto inviare un set di scaffalature per me o un altro per rivedere e controllare (per loro tramite la riga di comando). La maggior parte, soprattutto inizialmente, le proposte sono state respinte).

Aggiornamento Potrebbe esserci una terza via. TFS sul server e Git sul client. Dipende da TFS2012 (proprio per RTM). Vedi il Annuncio di Git di Harry Harry che annuncia l'integrazione di Git con TFS .

¹ Outsourcing anti-pattern: qui ci sono 6 grandi sviluppatori, molti reclami sui loro CV, quindi devono essere buoni, non c'è bisogno di intervistare / convalidare; ora faranno la maggior parte dello sviluppo.

² Pensa link ai candidati alla presentazione ...

I progetti open source usano git per accettare migliaia di contributi da sviluppatori completamente non fidati. Nessuno nella gestione ha mai smesso di chiedersi come riescono a farlo senza introdurre continuamente malware? O perché le persone con i contributori più non fidati effettivamente preferiscono git?

Se non ti puoi fidare dei tuoi sviluppatori con accesso in lettura, hai un'intera serie di problemi. Tuttavia, è facile anche con git. Basta inserire un codice di accesso limitato sul proprio server. È ancora più facile da proteggere rispetto alle autorizzazioni su un singolo server.

Il prossimo argomento che le persone fanno è, "Sì, ma con git copi l'intera storia, non solo l'ultima versione." Ho una notizia per te. Se hai accesso in lettura a qualsiasi VCS, hai abbastanza accesso per creare un repository git che nessuno conosce. Le persone lo fanno sempre quando la gestione inserisce su di loro un VCS subparente. Non lo sai perché in realtà non crea i problemi dell'incubo che temi che facciano.

Ci sono molte ragioni per cui un'impresa potrebbe scegliere un altro VCS su git. La sicurezza non è uno di questi. Probabilmente il motivo principale è che git è più un componente di un VCS che un sistema integrato. Devi aggiungere la tua autenticazione e autorizzazione, integrazione con CI e tracciamento dei bug, ecc. Inoltre, git ha un sacco di energia, ma con questo c'è la necessità di bloccare i server per prevenire l'uso accidentale di quella potenza e più allenamento. Se non conosci o non vuoi, flussi di lavoro più avanzati, git sembra una versione inutilmente complicata di svn.