Gli sviluppatori di un team hanno mai un controllo di versione "personale"?

La risposta breve è, dipende dai sistemi di controllo della versione in questione, dal tuo ruolo nel team su cui stai lavorando e dalla politica dell'azienda.

Alcune aziende hanno politiche molto rigide su cosa puoi usare e probabilmente sarai bloccato con qualunque software di controllo della versione sia lo standard aziendale. In altri negozi scoprirai che gli sviluppatori hanno un po 'più di flessibilità, quindi se il tuo strumento di scelta può interagire bene con qualunque sia il sistema di controllo della versione standard, allora puoi usarlo.

È importante che, se si utilizza un DVCS per mantenere un repository locale e quindi si spinga / spinga il codice in un sistema di configurazione della versione centralizzata, è necessario assicurarsi di continuare a impegnarsi regolarmente (tenere a mente "regolarmente" per qualcosa come svn è ancora meno spesso che con, ad es. git, ma assicurati di aver commesso il tuo codice abbastanza frequentemente, probabilmente ogni giorno, almeno una volta alla settimana). Non vuoi accumulare una tonnellata di cambiamenti nel tuo repository locale e quindi commettere enormi commit dal nulla.

Se ritieni che il tuo VCS preferito sia davvero migliore per le esigenze dei team rispetto a quello che usi attualmente, non esitare a menzionarlo e spingere (leggermente) la squadra a cambiare. Ciò avrà maggior successo se lo spingerai prima dell'inizio di una nuova versione o all'inizio di un nuovo progetto. Se il team è a metà del ciclo di rilascio, realisticamente qualcosa di più del semplice menzionare a mano che ti piace una differenza VCS rischia di irritare i membri del tuo team, dal momento che il passaggio dei sistemi di controllo delle versioni a metà progetto è una pessima idea indipendentemente da qualsiasi VCS che stai usando al momento.

Dall'esperienza personale, nel mio posto di lavoro corrente, prima che iniziassi tutto era basato sulla sovversione. Da quando sono stato assunto per avviare un nuovo progetto, ho detto che mi è piaciuto git e ho suggerito di utilizzare il nuovo progetto come pilota per vedere se git sarebbe adatto per il resto dell'azienda. Ho passato molto tempo a guidare gli altri membri del team su come usare git, e gradualmente li ho fatti diventare subito operativi. Nel frattempo, quando avevo bisogno di lavorare su alcuni dei vecchi progetti che erano ancora in sovversione, ho semplicemente usato svn e non ho fatto storie. Quando il progetto è stato completato e tutti hanno avuto la possibilità di vedere i vantaggi dell'utilizzo di un DVCS nessuno si è opposto al mio utilizzo di git-svn per interagire con il vecchio codice di base.

Se avessi iniziato e semplicemente insistito sul fatto che tutti dovevano passare a git, o insistito a usare git localmente per tutto e lamentarsi di dover interagire con svn, avrei probabilmente avuto meno successo, dato che si sarebbe rivelato meno "hey, ecco questa cosa carina", e più come "penso meno a te perché hai fatto una scelta sbagliata per usare quello strumento".

È certamente possibile utilizzare la nuova generazione di DVCS insieme a qualsiasi altro sistema di controllo sorgente. Lo faccio con Git quando devo.

Quando lavori con Subversion, Git ha un supporto client integrato che funziona molto bene.

Ho l'occasione di usare Git insieme ad altri sistemi di controllo del codice sorgente. È possibile creare un repository Git ovunque, quindi crearne uno nella directory di lavoro dell'altro sistema di controllo del codice sorgente. Quello che faccio è un ramo che riflette lo stato esatto del sistema di controllo della fonte estera - chiama quel qualcosa, ma master funziona bene. Fai il tuo sviluppo in qualche altro ramo.

Per ripristinare le modifiche a monte, passa prima al ramo master e ottieni le ultime modifiche a monte, confermando a master . Quindi unisci le tue modifiche dal tuo ramo di sviluppo. Speriamo che il sistema di controllo sorgente che stai utilizzando non richieda di contrassegnare in modo specifico ogni file per la modifica prima di cambiarlo, ma se lo fa (ad esempio Perforce), dovrai farlo manualmente. (Nel caso specifico di Perforce, c'è git p4 che già fa questo, ma nel caso generale non sarà pre-scritto.)

Dopo aver unito lo sviluppo in master , trasferisci le modifiche al sistema di controllo del codice sorgente estraneo come faresti normalmente.

Con git svn e git p4 (tra gli altri sono sicuro), questi connettori fanno alcune o tutte le seguenti cose per te:

• Mappare un commit nel sistema remoto a un commit in Git (in modo da ottenere tutti gli stessi messaggi di commit e quant'altro)
• Verifica automaticamente i file per la modifica (come p4 edit )
• Conferma le tue modifiche al sistema di controllo del codice sorgente estraneo

Di solito raccomando le procedure di cui sopra solo per coloro che sono esperti di Git (o di qualsiasi DVCS di scelta).

Dipenderà dalla situazione e dalla quantità di sovversione tollerata.

Nella maggior parte dei casi, è meglio usare ciò che il team ha deciso di utilizzare. C'è però un avvertimento: se la squadra ha scelto un sistema di controllo delle versioni affidabile (leggi Git, Mercurial, Subversion ecc.), Non dovresti avere problemi a usare quello scelto dal team al posto del tuo. Bisogna tentare di mettere da parte i propri gusti e antipatie a scopo di collaborazione.

Tuttavia, ci sono stati momenti in cui sono stato costretto a fare i conti con sistemi e pratiche di controllo delle revisioni scadenti. Hai mai provato a utilizzare VSS 6.0 (nel 2008)? Tramite un'interfaccia utente basata sul Web di origine (che accetta file singolari che richiedono 5 minuti ciascuno)? Ciò meriterebbe una storia a parte, ma mi sono trovato molto più produttivo quando ho replicato il repository su Subversion e ho eseguito il commit delle modifiche, senza rompere la build . Sottolineo l'ultima parte, perché non sarebbe facile sviare l'accusa di non essere un giocatore di squadra ; assicurandoti che la build non si interrompa, aggiungerai un tocco di affidabilità nei tuoi commit.

Gestisco un VCS personale ogni volta che non posso liberamente o facilmente diramarti nel repository ufficiale.

Mi piace commettere modifiche molto frequentemente, in modo da poter apportare modifiche sostanziali senza rischiare il mio lavoro in corso.

Questa è una pratica molto comune. DVCS come Git e Mercurial sono progettati per funzionare in questo modo.

Ho utilizzato un DVCS in cima al VCS centrale della mia azienda da un anno a questa parte e non guarderò mai indietro. I frequenti impegni locali portano via molto peso mentale. Durante i periodi di instabilità delle build nelle aree su cui non sto lavorando direttamente, ho sempre una base di riferimento stabile per fare il mio sviluppo personale e testare contro. Ho una filiale per i miei compiti a lungo termine, ma posso rapidamente passare a triage un problema urgente. Posso creare una nuova filiale per continuare a lavorare mentre il mio precedente compito viene sottoposto a peer review. I principali inconvenienti sono una certa complessità in più quando si spinge o si tira dal VCS centrale e si ha la necessità di resistere consapevolmente alla tentazione di allontanarsi troppo a lungo dal farlo.

Il mio flusso di lavoro è che il mio ramo master tiene sempre traccia del controllo della versione centrale, e faccio tutto il mio lavoro sui rami delle funzionalità, ricominciando dal master solo quando sono pronto a condividere le mie modifiche. In questo modo tutto si fonde con le mie modifiche locali con git, e se qualcuno upstream ha apportato una modifica incompatibile, posso integrarlo nella mia pianificazione invece di qualsiasi ora scomoda in cui si sono verificate le modifiche.

Per quanto riguarda il fatto che non ho accesso locale alla cronologia completa del progetto, la maggior parte delle volte mi occupo in primo luogo di cosa è cambiato dall'ultima volta che funzionava. Poi vado al controllo della versione centrale quando ho bisogno di sapere chi e perché . Non elimina la necessità di essere competente nel VCS ufficiale, ma può rendere più semplici le attività.