Quanto è meglio usare Git quando il mio datore di lavoro utilizza VSS?

Stai dimenticando qualcosa: il flusso di lavoro standard con VSS è:

• verifica la copia di lavoro
• (opzionalmente si lamenta che altri hanno bloccato alcuni file)
• funziona su file
• (trattare opzionalmente i reclami con i file bloccati)
• archivia i file.

Quello che devi capire è che mentre puoi ottenere una copia di sola lettura, non puoi cambiare i file o eseguire il commit delle modifiche a meno che tu non abbia un checkout che blocchi i file in modo che nessun altro possa modificarli. Quindi, mentre il tuo concetto di lavorare in modo indipendente migrando regolarmente una copia di lavoro a git è lodevole, dubito che funzionerà nella pratica. Dovrai eseguire un checkout (che blocca i file) all'ultimo momento, unire questi ultimi file da VSS al tuo repository git e quindi archiviare l'unione risultante in VSS. Se qualcun altro sta lavorando su questi file quando decidi di volere per unire, dovrai aspettare che finiscano. Dovrai inoltre bloccare tutti i file, poiché non potrai (facilmente) sapere quali sono stati modificati da quando hai effettuato la tua ultima copia di sola lettura.

È meglio organizzare il lavoro che stai facendo, o i file su cui stai lavorando, con i tuoi colleghi e utilizzare lo strumento come previsto. La parte importante di questo è comunicare e organizzare il lavoro di sviluppo del team piuttosto che lavorare in modo indipendente come si vuole fare usando git.

Ho intenzione di rispondere, "non farlo." I flussi di lavoro sono molto diversi, e non ne avrai preso in considerazione uno e finirà per causare te stesso, o peggio per la tua squadra, un sacco di dolore. Impara VSS, se non altro per farti apprezzare di più gli altri VCS.

- UPDATE -

Ho utilizzato questo script bash con molto successo:)

Inoltre ora consiglierei 2 directory invece di 2 rami. È molto più pulito:)

Se hai il supporto del tuo amministratore VSS, puoi seguire qualcosa come sotto.

Altrimenti puoi usare git per le tue filiali e il flusso di lavoro generale e usare VSS come previsto, ma in questo caso raccomanderei una separazione netta, non la soluzione di interoperabilità che ho scelto. La mia soluzione è più adatta come fase di migrazione, ma anche in questo caso la userei con cautela.

• Copia di lavoro da VSS
• git init
• crea un ramo "vss_branch"
• dirama un ramo "dev" dal master
• branch dev per ogni singola funzione / bug
• in completamento funzionalità, rebase per ripulire i commenti (se sono stato cattivo)
• unisci in dev quando le funzionalità / bug sono pronte
• test dev
• se tutto è valido unisci dev in master
• Sincronizza il mio ramo principale con VSS
  • passa a vss_branch
  • ottenere una copia funzionante da Visual Source Safe
  • commit in vss_branch con "ss history" come commento
  • tira vss_branch sul master
  • test master Sincronizza VSS con il master
  • "ss checkout" file che ho modificato (non sovrascrivere la copia di lavoro)
  • "ss checkin" I file sono cambiati (aggiungendo git comment as label)
• estrai master in dev

Ho tentato di attenermi al nostro flusso di lavoro VSS ma essere un po 'più robusto con il ramo git VSS separato che non ho mai spinto a.