Sto lavorando in un'istituzione governativa. La tecnologia utilizzata qui e i metodi per lo sviluppo del software sono piuttosto vecchi.

Hanno tonnellate di spazio di archiviazione, ma non c'è spazio adeguato per conservare e mantenere le applicazioni utilizzate per automatizzare la maggior parte del lavoro qui.

L'istituzione non mi consentirebbe di utilizzare software SCM come GIT o SVN.

Quale sarebbe l'approccio migliore per mantenere la qualità del codice e poter aggiungere successivamente nuove funzionalità nelle app?

Come posso ricordare le modifiche che ho apportato al codice senza romperlo?

EDIT: ho dimenticato di menzionare, hanno unità di rete per ciascuno dei computer e in qualche modo queste unità di rete eseguono o salvano backup in periodi. Tuttavia, se non creo il mio piano che consente di salvare il mio lavoro e di poter aggiungere nuove funzionalità senza rompere il codice esistente, non vi è alcun vantaggio rispetto a una soluzione SCM.

EDIT: Poiché molte persone hanno suggerito Git portatile, devo aggiungere ulteriori informazioni. Ho provato a installare il server Visual SVN, ma non è riuscito perché non ho i privilegi di amministratore da installare. Ho anche provato a scaricare la normale shell Git, ma il firewall o le impostazioni di rete non mi hanno permesso di accedere alla pagina di download di Git. Ho anche provato, inviando Git portatile alla mia e-mail che è Gmail. Google ha rilevato il file exe nel pacchetto e anche questo non mi ha permesso di scaricare la versione portatile di Git sul mio computer di lavoro. Un'altra cosa che devo menzionare, la politica di rete applicata ai computer attraverso l'istituzione non consente l'utilizzo di dispositivi di archiviazione USB. È possibile utilizzare le porte USB per caricare smartphone o alimentare alcuni gadget come piccoli altoparlanti. Inoltre, come alcune persone hanno menzionato, ci sono computer su cui non è consentita nemmeno Internet.

Puoi replicare liberamente il ruolo svolto dal controllo del codice sorgente con tre semplici strumenti:

• Software di backup (commit / check-in)
• Cartelle (rami)
• Esecuzione di una fusione di directory tra due directory usando uno strumento come KDiff3 (Unione di rami)

Fondamentalmente il tuo flusso di lavoro diventa:

1. Crea una nuova cartella (nuovo ramo)
2. Copia i file nella nuova cartella (nuovo ramo) da una cartella esistente (ramo esistente)
3. Crea un backup di quella cartella (termina la creazione del nuovo ramo)
4. Fai del lavoro
5. Crea un backup della nuova cartella (commit)
6. Unire una directory da una cartella a un'altra (unire)
7. Esegui un altro backup nell'altra cartella (esegui il commit dell'unione)

I sistemi di controllo della fonte più monolitici, come SVN o TFS, lo fanno praticamente dietro le quinte.

Ora, la realtà è che è come una compagnia di autobus che dice ai suoi conducenti che non possono guidare autobus che hanno una batteria, costringendo i conducenti a spingere l'autobus giù per la collina e poi a tirare la frizione per avviare l'auto ... questo è terribile e indica che l'attuale gestione non sa nulla sull'esecuzione di un garage per autobus. Le mie condoglianze.

Ma almeno puoi far partire l'autobus.

Anche se il consenso sarebbe certamente quello di non lavorare per questa società , non credo che risponda davvero alla tua domanda.

Non puoi davvero sostituire SCM .

Potresti non aver bisogno delle solite campane e fischietti di un sistema completo. Ad esempio, la società può rifiutare una richiesta per un server, ma consentire l'uso di un SCM locale. Potrebbero non piacere a Git, ma consentire la sovversione (o qualche altro sistema di versioning).

C'è ovviamente una domanda: che cosa usano i tuoi colleghi o qualsiasi altro lavoratore precedente? Se sei il primo sviluppatore di software che hanno, allora è il momento di spingere molto forte per le risorse di cui hai bisogno.

Alla fine, se la tua azienda non rispetta il tuo ruolo ed esperienza e non ti consente gli strumenti di cui hai bisogno, allora incontrerai problemi ancora peggiori (e più stressanti) di una mancanza di controllo del codice sorgente.

Fondamentalmente, c'è un problema di gestione (la tua organizzazione non capisce le basi del processo di sviluppo del software , ad esempio il modello V ) che si condensa nella apparente incapacità di utilizzare un flusso di lavoro, una metodologia e strumenti minimi dell'era attuale. Questo è comune (leggi sul principio di Pietro ).

^{A proposito, immagino che il recente incidente ferroviario della SNCF a Parigi alla fine del 2017 abbia una causa simile (totale mancanza di cultura del software ad alto livello di gestione, quindi blocco di una grande stazione ferroviaria di Parigi per più di un giorno; ovviamente ci sono molto competenti Team IT presso SNCF, ma non vengono consultati sulle decisioni più importanti). Posso nominare diverse industrie europee con una totale mancanza di cultura del software e sono sicuro di riuscire a trovare cose simili anche negli Stati Uniti.}

Il problema principale è: stai lavorando da solo sulla tua base di codice o lavori con i colleghi?

Se lavori da solo, puoi usare git localmente sul tuo computer e fare .gitperiodicamente il backup del tuo codice (e probabilmente anche del tuo repository) (su quello spazio di archiviazione esterno). Assicurati di non perdere mai più di mezza giornata di lavoro (quindi esegui il backup dei dati periodicamente e in modo affidabile).

^{(Suppongo che tu sappia almeno entrambi gite svnche tu conosca la superiorità tecnica di git; se non ti è nemmeno permesso installare alcuni strumenti come gitsul tuo computer di lavoro, devi avere una conversazione seria con il tuo capo su quel problema: devi la capacità e l'autorizzazione di installare strumenti open source esterni (e ciò spetta a te scegliere, configurarli e installarli con saggezza e attenzione e senza vulnerabilità note )}

Se stai lavorando con diversi colleghi (immagino meno di una dozzina di loro), devi convincerli tutti a utilizzare un sistema di controllo della versione e probabilmente dovrai parlarne al tuo capo immediato (e comune). Potrebbe (probabilmente) decidere (o semplicemente accettare implicitamente) che una macchina (forse anche un vecchio desktop, forse persino il tuo desktop) sia usata come server git. È assolutamente necessario configurare quel server in modo tale che venga eseguito il backup del repository git almeno ogni ora; non puoi permetterti (e devi parlare con il tuo capo) di perdere più di un'ora di lavoro della tua squadra.

^{A proposito, adoro Linux e consiglierei di installare Linux sulla macchina che funge da gitserver; quindi l'installazione gite la configurazione di backup periodici (con alcuni crontablavori) è molto semplice; notare che un gitserver potrebbe eseguire Linux con client Windows che lo utilizzano. Ti suggerirei persino di cambiare la tua macchina di sviluppo su Linux, se puoi. È "più economico" e molto più adatto agli sviluppatori}

Ma devi usare un SCM. Potresti porre al tuo capo una domanda diversa: il tuo team dovrebbe usare un SCM esistente o dovrebbe reinventare la ruota e creare il tuo SCM? I boss sono generalmente contrari all'idea di reinventare la ruota. Se ti è permesso reinventare la ruota, dì al tuo capo che è un lavoro a tempo pieno per almeno un anno (che probabilmente farà piangere il tuo capo, quindi accetterà il modo ovvio) e divertiti a creare il tuo SCM. In questo caso improbabile, assicurati di studiare i sistemi SCM esistenti e chiedi di rendere il tuo sistema SCM uno strumento software gratuito (che verrà utilizzato e migliorato da altri team).

Potrebbe essere necessario preparare (per parecchi giorni) una precisa e specifica argomentazione per la necessità di uno SCM : prima per i vostri colleghi, quindi per il tuo capo immediato. Assicurati di suggerire anche soluzioni concrete (come eseguire qualche server git su un desktop o un server "vecchio" e eseguirne il backup ogni ora attraverso un crontablavoro)

Non installare alcun software (dall'esterno, anche open source) sul tuo computer di lavoro senza autorizzazione (nella maggior parte dei paesi, specialmente per lavori IT sensibili per lo Stato, l'installazione di un software senza autorizzazione è legalmente un crimine e potresti perdere il tuo lavoro o andare in prigione se lo fai .... quindi assicurati di essere autorizzato a farlo; forse copriti il ​​culo chiedendo un'autorizzazione per iscritto, o almeno via e-mail).

^{(o dovrai chiedere caso per caso o devi ottenere la fiducia della tua organizzazione per poter installare sul tuo computer di lavoro qualsiasi software legale , principalmente open source o software gratuito).}

PS. Come costruire tecnicamente, configurare, installare e quindi utilizzaregit (dal suo codice sorgente software gratuito) o la maggior parte degli altri software gratuiti VCS su una macchina (anche senza l'autorizzazione dell'amministratore ) è una domanda molto diversa (da chiedere altrove). Ed è possibile installare quindi utilizzare gitsenza alcuna autorizzazione di amministratore, a condizione che tu abbia abbastanza risorse (tempo, spazio su disco, un compilatore C, ecc ...) per quello.

Ho provato a installare il server Visual SVN, ma non è riuscito perché non ho i privilegi di amministratore da installare.

Questo è risolvibile con una specifica configurazione e compilazione del tuo gito svndal codice sorgente del software libero di gito SubVersion -non solo un pacchetto binario- (e anche il codice sorgente delle dipendenze ); come fare tecnicamente questa è una domanda diversa (ma tali domande tecniche dovrebbero andare in qualche altro posto). Ovviamente dovresti chiedere il permesso (al tuo capo) di compilare il codice sorgente gitprima di farlo. Ti dirà, o discuterai con lui, dei dettagli pratici (se accetta una tale soluzione) riguardo al trasferimento di quel codice sorgente dall'esterno sul tuo computer di lavoro.

La prima cosa che vorrei fare è identificare in modo specifico ciò a cui l'agenzia governativa (presumibilmente il dipartimento IT) si oppone. Se dispongono di spazio di archiviazione, ma non c'è modo di ospitare macchine virtuali per server, il problema potrebbe essere che il reparto IT sta dicendo no al server SVN o GIT e questa è una grande distinzione. Se il problema è il paese di origine - ovvero non ci fidiamo degli strumenti creati da entità straniere - questo è un problema diverso.

Puoi eseguire GIT completamente all'interno del file system, cosa che ho fatto su progetti infantili prima di essere pronto a fare qualsiasi cosa con loro. GIT inoltre non richiede i privilegi di amministratore per l'installazione.

Se non puoi assolutamente usare Git per qualsiasi motivo, allora hai un paio di opzioni disponibili:

• Educare: non consentendo il controllo della versione, stanno introducendo un rischio significativo. È necessaria la capacità di uscire dai cambiamenti che si rivelano più problematici. Hai bisogno della capacità di risparmiare tempo e denaro del governo, e SCM lo fa. Devi essere in grado di spiegare chiaramente come. Probabilmente dovrai anche fare un'analisi delle alternative per portare davvero a casa il punto.
  • Un'alternativa sarebbe ospitata Git
  • Un altro filesystem Git
  • Scegli almeno uno, ma non più di altri due strumenti SCM alternativi
  • e infine com'è lavorare senza il controllo della versione
• Vai sviluppo anni'70 era: C'è una ragione per cui patche diffsono state fatte molto tempo fa (anni '80). Erano le tecnologie abilitanti che rendevano possibile il controllo delle versioni.

Che aspetto ha lo sviluppo degli anni '70? Non è carino, ma è come abbiamo iniziato. Le applicazioni erano molto più piccole. Essenzialmente avevano alcune cose in comune:

• C'era il concetto del gold standard . Questo era il codice sorgente principale con funzionalità complete.
• C'era un team di gestione della configurazione (CM). La loro responsabilità era quella di ottenere correttamente i cambiamenti dallo sviluppo al gold standard. È qui che è necessario patche diffin sostituzione del team.
• Hai lavorato da una copia locale del codice sorgente. Finisci una funzione nella sua interezza e la invii al team CM affinché possano integrarla. Di solito c'è un documento di accompagnamento in modo che vengano creati nuovi file e vengano eliminati file obsoleti, ecc.
• Quindi si correggono eventuali errori dal processo di integrazione.
• Prima di poter intrattenere un'altra funzionalità o correzione di bug, si ottiene una nuova copia del gold standard.

In sostanza, si tratta di un processo soggetto a errori con un sacco di potenziale per le cose che vanno male. L'idea di "ramificazione" è facile da implementare, ma un incubo da gestire. Il problema principale è che quando si hanno troppe copie del codice sorgente è difficile capire quale sia la base di riferimento corretta per la produzione. Per praticità devi diventare single thread.

Questo è ciò che devi includere nell'analisi delle alternative.

Dati i vincoli che menzioni nei commenti (ad esempio: impossibile accedere alla pagina di download di Git, alla piattaforma Windows e all'utilizzo di Visual Studio 2005), posso vedere 2 opzioni, entrambe usate in precedenza in una situazione simile:

1. Usa Visual SourceSafe come Emerson suggerisce in un commento. Ho lavorato con un team usando VS 2005 alcuni anni fa, mentre la maggior parte del resto dell'azienda utilizzava il controllo della versione standard in Linux / Unix e hanno usato felicemente Visual SourceSafe per il loro CM. È piuttosto vecchio stile a questo punto, ma meglio di niente.
2. A proposito di meglio di niente, sono stato io stesso in un legame simile. Se non riesci nemmeno a utilizzare VSS (forse il plug-in non è installato?) E poiché dici che c'è molto spazio di archiviazione disponibile, spero che ti sia permesso di usarne un po '. Ho implementato un protocollo di controllo versione manuale basato su file. Alla fine di ogni giornata lavorativa, avrei copiato la mia base di codice in una nuova directory timbrata. Se avessi bisogno di fare riferimento al lavoro precedente (o ripristinare), avrei cercato le directory precedenti per trovare la modifica di cui avevo bisogno. Dato che hai Visual Studio disponibile, entro un paio d'ore, probabilmente potresti usare VS 2005 per scrivere un semplice strumento che ti aiuti ad automatizzare la creazione della directory e la copia dei file.

Hanno tonnellate di spazio di archiviazione

Ti è permesso usarlo su tua decisione?

In tal caso, è possibile creare un repository remoto del file system che è meglio di niente. L' gitaspetto negativo è che la spinta diventa lenta mentre il progetto sta crescendo perché deve scaricare l'intero repository per cercare le modifiche ...

finora i computer si comportano come un normale utente, vietandomi di installare software di terze parti.

gitviene fornito anche come app portatile in modo da poterlo installare nel percorso $ HOME o% USERPROFILE%.

In conclusione: non vorrei che mi vietassero l'uso di un SCM ¹ . Lo userei "in privato". Dopo tutto nessuno può dire se il tuo codice è stato sviluppato con o senza essere verificato da qualche parte ...

¹ ) quando ho iniziato a usare gitalcuni anni fa il mio cliente preferiva un SCM diverso che era piuttosto lento e inaffidabile (che è una specie di NOGO per un SCM dopo tutto (o;). Ho usato git"in privato" sopra l'altro SCM con un "file based" remoto su una condivisione di rete e registrato nel loro SCM solo dopo il rilascio di una nuova versione del prodotto.

Il tuo ambiente

Prima di tutto, non sarei così pessimista come mostrato in molti commenti e risposte. Sì, questa è "l'età della pietra", ma ci sono circostanze molto peggiori. Se il tuo ambiente di lavoro generale (colleghi, sede, retribuzione, lavoro di programmazione interessante ecc.) Va bene e secondo i tuoi gusti, allora atteniti a questo. Per quanto riguarda l'IT, è quello che è. Ciò non accade solo nelle agenzie governative, ma anche nel settore bancario, assicurativo o ovunque vi sia una grande attenzione alla sicurezza o strutture molto vecchie.

L'inserimento di una chiavetta USB e l'esecuzione di alcuni file .exe da lì sarebbe causa immediata di chiusura in altri luoghi, quindi non consiglierei di provare a eludere nulla.

Prova git ancora una volta

Ora a tua scelta. Consiglio vivamente git invece di svn per te. Se stai comunque facendo progetti individuali, allora git è solo una directory locale .gitall'interno della tua radice dell'applicazione, nient'altro.

Non chiedere al tuo capo / IT un "SCM", ma chiedi loro di installarlo gitsul tuo computer in modo da poterlo sviluppare più velocemente e con una qualità superiore. Spiega loro che non desideri spingere il tuo codice da qualche altra parte, che non hai bisogno di un server in esecuzione da qualche parte e che non utilizzerà spazio o tempo di manutenzione significativi.

Git aumenterà la velocità e la qualità per te semplicemente perché puoi lavorare con maggiore sicurezza (perché puoi annullare qualsiasi modifica apportata) e consentirti di lavorare su più filiali contemporaneamente. Ad esempio, se stai lavorando su un'attività di grandi dimensioni e arriva qualcosa che richiede la tua attenzione immediata, puoi semplicemente passare a un nuovo ramo, risolverlo rapidamente e quindi tornare all'attività di lunga durata.

Farlo manualmente

Se proprio non è affatto possibile, ovviamente puoi fare il controllo manuale della fonte. Crea "tag" manuali copiando tu stesso il tuo codice (magari crea una nuova directory con la data / ora e una breve descrizione di ciò che è cambiato). Mantieni un log delle modifiche con elenchi dettagliati non solo delle tue modifiche, ma anche dei file che hai modificato e forse anche di più dettagli.

Crea "rami", ancora una volta, copiando il tuo lavoro e quando è il momento di ricollegarti, diventa creativo usando alcuni strumenti "diff" o "diff3" arbitrari - non so se ne hai a disposizione, dovrai scoprire.

Se tutto ciò ti costa molto tempo, allora dai una buona occhiata se vale davvero la pena emulare un SCM. Se ci si accorge che è valsa la pena, poi parlare con il tuo capo di nuovo. Mostragli i vantaggi del tuo manuale SCM (non solo "Ho una copia di tutto il mio vecchio lavoro" ma "quando si è verificato un bug XYZ sono stato immediatamente in grado di trovare il motivo, 5 versioni fa"). Quindi dì loro quanto più veloce sarebbe git.

Ovviamente, se questo ti sta facendo impazzire, cercare un lavoro è sempre un'opzione.

Penso che a molte persone qui manchi l '"istituzione governativa" di questa domanda. Alcune reti governative hanno norme molto rigide sul software consentito e infrangere tali regole è un reato violento, forse persino criminale. Lo spingerei attraverso la gestione per vedere se riesci a ottenere qualche movimento APPROVATO su come installare il software. Non andrei da cowboy a installare roba da solo. Se stai utilizzando Linux / UNIX, controlla se sono installati RCS (comandi ci / co) o SCCS (comando sccs). Questi sono vecchi strumenti SCM che erano abbastanza standard. Non è carino ma meglio di quello che sto per scrivere qui sotto. :)

Dato che hai "un sacco" di spazio su disco, crea un albero dei sorgenti. Quali sono le basi di SCM su piccola scala? Essere in grado di fare il check-in delle modifiche, guardare cosa è cambiato, etichettare i contenuti e tornare alle versioni precedenti, se necessario. Un livello sopra l'albero dei sorgenti, crea un Makefile o script, a seconda di ciò che hai a disposizione, che fa quanto segue (questi sono basati su Linux / UNIX, i comandi di Windows sarebbero diversi)

make checkin - cp -a source-tree source-tree-date (almeno al minuto, se non al secondo, come source-tree-20171205115433)

make status - diff -R albero-sorgente albero-data-data | meno (ci sarebbe un po 'di logica qui, per impostazione predefinita al backup più recente o dare un argomento per diff contro una versione

make tag - ln -s source-tree-date release1.0 (crea un collegamento a una versione particolare)

make revert - rm -r albero-sorgente && cp -a albero-sorgente-data albero-sorgente

Vendilo a loro

Hai lasciato questo commento :

Hanno un'unità di rete che non so come, ma crea backup in periodi. Sì. Lo uso e memorizzo le mie app lì.

Vai dal tuo superiore e dì qualcosa in questo senso:

Capo, ho notato che abbiamo un sistema in cui inseriamo app sull'unità di rete e un qualche tipo di servizio effettua backup e tiene traccia della cronologia. Mi sembra che stiamo solo implementando il nostro sistema di controllo del codice sorgente in questo modo. Probabilmente potremmo liberare molto spazio e rendere l'intero sistema molto più semplice passando a un sistema di gestione del controllo del codice sorgente dedicato, come SVN o git. Otterremmo molti vantaggi: backup più semplici delle versioni storiche, strumenti per comprendere quali modifiche sono state apportate ai file nel tempo (informazioni molto utili per il debug), modi più semplici per annullare gli errori e modi più semplici per combinare le modifiche delle diverse persone.

Ho usato questo tipo di sistemi prima, e sono molto bravi nel compito che sta eseguendo la nostra configurazione personalizzata. È molto più difficile commettere errori con loro di quanto non sia il nostro sistema attuale. Sono anche tecnologie molto mature e ampiamente utilizzate; questi strumenti sono stati ampiamente utilizzati per oltre 20 anni. E per di più, possiamo usare il software più popolare senza pagare un centesimo in licenza.

Sarei felice di aiutarti a scegliere un client e un server e a configurarli. Mi aspetto che occorrerebbero [insert estimate here]ore per installarlo se riesco a ottenere una macchina. Farebbe qualsiasi macchina, anche un vecchio desktop sta per essere ritirato, purché possiamo accedervi tramite la rete.

Il riassunto di alto livello qui è che è necessario metterlo in termini che possano capire e probabilmente pensano che ne valga la pena:

• Liberare risorse (hardware e persone) per altri scopi
• Minor rischio (errore umano, tecnologia stabile)
• Produttività incrementata
• Piccoli costi di implementazione

I tuoi superiori non sono tecnici e non si preoccupano dei problemi tecnici. Ma se riesci a inquadrare il problema in termini di denaro e cose che costano denaro, le loro orecchie potrebbero rallegrarsi un po '.

Bene, dopo aver letto la tua domanda e molti commenti, ho capito che hai i seguenti vincoli / scenari:

• 1 persona per progetto;
• semplicemente non puoi usare strumenti esterni diversi da Visual Studio 2005 per il tuo progetto; non puoi usare GIT o altri SCM;
• mentre lavori localmente, non puoi lasciare che il progetto si trovi in ​​uno stato non funzionante, perché di tanto in tanto hai dei backup automatici e devi farlo funzionare continuamente;
• hai bisogno di un po 'di cronologia per tenere traccia delle modifiche;

Se non è possibile utilizzare Visual Source Safe (che ha un plug-in per funzionare con VS 2005), è possibile utilizzare un altro approccio.

Sulla base degli elementi precedenti, ti suggerisco di organizzare le cartelle del tuo progetto come di seguito:

trunk           //last functional version of the app. IMPORTANT: YOU DON'T WORK WITH THIS FOLDER
    UnitTests   //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln
temp              //your working folder; has structure similar to trunk; changes will be commited to trunk;
    UnitTests     //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln  
build
    .history    //folder to contain changes in files and your comment (like commits in git)
    build.bat   //calls MSBuild to build temp\YourProject.sln, and run all unit tests
    save_on_trunk.bat   //if build is working, saves info from "diff.bat" in folder within ".history" with timestamp, and also overrides "trunk" with content from "temp"
    diff.bat         //compares files from "temp" and "trunk", using "dir" and "fc" commands
    history.bat  //outputs content from .history folder (contains file changes and comments)

Regole di base da seguire qui:

• il controllo del codice verrà eseguito all'interno della cartella del progetto;
• non lavori mai in "tronco";
• lavori in "temp" , implementa unit test , chiama build.bat e quindi save_on_trunk.bat ;
• IMPORTANTE: implementare test unitari eseguiti in totale isolamento; questo è necessario per garantire che il nuovo codice non rompa il trunk;
• poiché si dispone di backup automatici, le probabilità di perdere il codice saranno minori; pertanto, è sufficiente che il codice "trunk" sia sempre funzionante.

Hai esaurito le soluzioni tecniche. Rimangono solo soluzioni politiche.

1) Unionizzare gli sviluppatori. Se esiste già un sindacato, sfida la loro posizione in quanto non rappresenta in modo equo la classe di dipendenti che è uno sviluppatore. Se la formazione di un'unione di sviluppatori non riesce a ottenere il supporto di metà degli sviluppatori, GO. Sei in forma male.

2) Annuncio di giornale. Se il tuo governo non garantisce la libertà di parola in quanto legge riconosciuta, questo ti farà licenziare.

Git per Windows ha una versione "portatile" . Puoi copiarlo sul tuo PC o tenerlo su una memory stick, senza dover installare nulla. Se il problema è semplicemente l'installazione, questa sarebbe una soluzione alternativa.

Si noti che se si oppongono categoricamente a SCM, è possibile che si desideri porre domande mirate su ISO-9001, DO-178B o altri standard di sviluppo software pertinenti.

Basta eseguire git su una directory vuota, senza alcun server coinvolto. Non importa affatto che nessun altro usi il controllo versione, perché puoi controllare la versione della tua directory. Git è stato progettato esattamente per questo scenario di introduzione SCM canaglia e funziona bene.

Diventerai un eroe quando la seconda persona inizierà a usarlo, anche se devi aspettare che un dinosauro colpisca il secchio affinché si diffonda. Adesso è incompetenza gestire basi di codice di grandi dimensioni senza SCM. È come gestire un'azienda senza controllare nulla, in realtà.

Ci sono in realtà tre cose separate su cui vorresti insistere come sviluppatore professionista: revisioni del codice, cronologia delle versioni e monitoraggio delle richieste di modifica.

Puoi tenere traccia delle richieste di modifica. Non bello come con gli strumenti giusti, ma puoi farlo. La seconda parte è la revisione del codice. Per questo, hai bisogno della copia precedente del tuo codice e di uno strumento diff. Quando ritieni che una modifica sia pronta, la rivedi tu stesso confrontandola attentamente con la versione precedente, quindi sostituisci la versione precedente con una nuova.

Per il controllo della versione, se il tuo posto di lavoro non consente alcuna soluzione decente, è una scatola di DVD scrivibili di cui hai bisogno. Ogni volta che hai una versione che desideri conservare per poter tornare, crei un nuovo DVD.

(Ovviamente tutto ciò non è un consiglio che dovrebbe essere preso a meno che non ci si trovi in ​​un posto di lavoro davvero pessimo come sembra l'OP).