Passaggio da SVN a Git: aiuto necessario

Naviga le tue risposte
4

Sono uno sviluppatore di software recentemente responsabile di tutto il progetto (project manager). Il progetto su cui sto lavorando (con altre 6 persone) è una complessa applicazione basata su Java che viene sviluppata da oltre 5 anni. L'intero periodo in cui stavamo usando SVN, senza diramazioni. Ora, vorrei passare a Git perché credo che Git fornirà una ramificazione superiore e faciliterà lo sviluppo.

Ad ogni modo, prima di passare, devo parlarti dell'attuale flusso di lavoro che stiamo avendo con SVN, devo ascoltare l'opinione delle persone esperte con Git e dirti quali sono le cose che mi aspetto da Git. Per favore dimmi se Git può fornire le cose di cui ho bisogno nel modo in cui ho bisogno di loro, perché se cambio l'intero progetto in Git e poi si scopre che devo ripristinarlo in SVN (per qualsiasi motivo) , Sarei morto :).

Il principio che seguiamo con SVN è:

  • Ogni membro del team sta lavorando su una singola funzione. Al termine di tale funzionalità, una copia locale del codice dello sviluppatore viene aggiornata rispetto al master SVN e la funzionalità viene distribuita per il test. Se la verifica da parte dei client è passata, la persona che sviluppa il codice lo spinge al nostro ramo principale (e solo) con un messaggio di commit appropriato che spiega la funzione, il numero di ticket e così via.

  • Se, durante "aggiornamento prima della distribuzione per il test", il membro del team entra in conflitto, seleziona i file in conflitto riga per riga.

  • Quando arriva il momento in cui distribuiamo nuove funzionalità alla produzione, carico il codice di produzione da una particolare cartella sul disco (come "ramo fisico"), sincronizzo quel codice allo stato corrente di SVN, andando classe per classe , revisione del commit cambiata e presa del codice pensato per quella particolare implementazione. Di solito, accade che su 230 classi che abbiamo nel repository (e non nello spazio di lavoro di produzione) tra 30 e 50 classi sono in conflitto a causa delle caratteristiche che non abbiamo ancora bisogno di produzione. A volte, i clienti chiedono le ultime funzionalità prima che desiderano alcune funzionalità meno recenti. Se entrambe le funzionalità vogliono e le funzionalità non influenzano lo stesso file, devo saltare manualmente un determinato file dalla versione di commit 3 per eseguire il commit della versione numero 6 senza prendere qualsiasi modifica dai commit 4 o 5 Ora, se anche un altro file è interessato, succede che un altro file dalla versione, diciamo, 35, devo aggiornare alla versione 40 senza prendere alcuna modifica tra 35 e 40. Con SVN, è facile, sincronizzo un particolare file e seleziono solo le righe di codice ignorando tutte le altre. Ci vuole tempo, ma sono in grado di dire ai clienti "rimandiamo questo per X giorni".

Inoltre, se due sviluppatori stanno lavorando su diverse funzionalità che influenzano in gran parte lo stesso sottosistema o il grosso numero degli stessi file, al fine di evitare brutti conflitti e collisioni di solito dico ai clienti "non possiamo sviluppare entrambe le cose nello stesso tempo, posticiperemo la funzione B finché la funzione A non sarà terminata e testata "e uno degli sviluppatori si metterà al lavoro su qualcos'altro.

Ora, da Git l'unica cosa di cui ho fondamentalmente bisogno è:

  • Nice Windows GUI (per SVN stiamo usando il plugin "Subclipse" per Eclipse). Non ho intenzione di investire molto tempo solo imparando o ricordando come spingere un ramo o visualizzare la cronologia o fare qualcosa di simile se può essere fatto con un clic di un pulsante. Per me, il sistema di controllo della versione dovrebbe essere solo uno strumento, non qualcosa che i miei sviluppatori dovrebbero dedicare più di un giorno a imparare come utilizzare a causa della CLI e cose avanzate che non useremo o non richiederemo. Con SVN utilizziamo solo 4 comandi: commit, update, synchronize (per vedere le differenze) e "history". Ok, a volte usiamo "confronta con la versione X da repo", ma non così spesso.
  • La possibilità di ottenere una buona memorizzazione del codice usando solo pochi comandi di base (clic del pulsante per essere precisi: D): push / pull, fetch / commit, branch / merge, visualizza cronologia. Niente di stravagante o avanzato che richiederebbe molto tempo per imparare o capire.
  • La capacità di prendere parzialmente i commit. Ad esempio: commit consiste di 10 file. Prendo tutte le modifiche da 8 file, ma per due file eseguo il cherry-pick in modo che dalla versione 5 di produzione corrente prendo due righe di codice dalla versione 7 del commit del file e poche righe dalla versione 9 del commit del file (mantenendo effettivamente quelle due file in "versione non definita" in modo che possa fornire ai miei clienti le modifiche più recenti senza tutte le modifiche al codice che precedono quella funzionalità più recente che desidero). Per raggiungere questo punto, per me non è un problema allocare un'intera giornata a scavare nella storia e commettere indipendentemente dal fatto che si tratti di SVN o Git. Quella è la mia giornata di "preparazione":)
  • Avere versioni di commit numeriche, non quelle basate su HASH!

È possibile con Git? Ho un'esperienza limitata con Git, solo su alcuni piccoli progetti e non posso permettermi di spostare l'intero codice da un sistema all'altro :( Per favore, dammi un consiglio.

    
posta guest86 29.06.2017 - 17:25
fonte

3 risposte

5

IMHO ti stai avvicinando dal lato sbagliato. Probabilmente hai bisogno prima di tutto di un flusso di lavoro migliore, utilizzando i rami e non necessariamente un altro strumento . Perché non iniziare a utilizzare i rami delle funzionalità con SVN ? Se hai intenzione di sviluppare due funzioni principali in parallelo, crea solo rami individuali per le funzionalità e assegnale come "spazio di lavoro" temporaneo per la parte del team che implementerà le funzionalità.

Questo è un modello di ramificazione abbastanza semplice e facile da comprendere, SVN supporta questo bene, e fintanto che il modello di repo centralizzato di SVN non è un problema per il tuo team, potrebbe essere tutto ciò che serve. Lo sviluppatore "principiante" continuerà a utilizzare "commit, update, synchronize, history" sul ramo che gli hai assegnato (e una "unione dal tronco al mio ramo di funzionalità"), solo la persona che reintegrerà le funzionalità in un giorno il bagagliaio dovrà conoscere altri comandi SVN. Questo passaggio di integrazione diventerà molto più semplice rispetto al tuo attuale approccio "cherry picking", dal momento che non è necessario selezionare quale modifica di codice appartiene a una determinata funzione in seguito nel modo ingombrante e soggetto ad errori che hai descritto.

Quando segui questo percorso e raggiungi il punto in cui tu e il tuo team volete fare rami più complessi e notate che SVN non è più sufficiente, ad esempio quando avete bisogno di uno strumento per fare rami locali distribuiti, allora è il momento di passare a Git. Ma al momento, sembra che tu non ci sia ancora.

    
risposta data 30.06.2017 - 14:27
fonte
1

Dal tuo post mi sembra che tu non stia facendo il miglior uso del controllo del codice sorgente.

Inoltre dichiari di non avere molta esperienza nell'uso di git.

Penso che sia abbastanza ben accettato che git sia diventato il software di controllo sorgente dominante. Forse potresti sostenere che la strategia di branching del git flow è la strategia più popolare e robusta da adottare per i principianti.

Tuttavia, non sembra probabile che sarai in grado di ottenere un aumento della produttività se proverai a passare a git senza aiuto.

Mi sembra che sarà piuttosto un cambiamento organizzativo e culturale per passare a un uso migliore del controllo del codice sorgente e dovrebbe essere tentato solo da una persona esperta con un sacco di acquisti dagli altri sviluppatori

    
risposta data 29.06.2017 - 18:59
fonte
1

•Nice Windows GUI (for SVN we're using "Subclipse" plugin for Eclipse). •The ability to achieve nice code storage by using only a few basic commands (button clicks to be precise :D ): push / pull, fetch / commit, branch / merge, view history.

È disponibile un plug-in di integrazione Git per Eclipse disponibile dal repository Eclipse ufficiale che consente tutte queste operazioni (in "Collaborazione" nella schermata "Installa nuovo software ..."). Questo plugin è già incluso in molti pacchetti ufficiali di Eclipse, quindi potresti già averlo.

Il Git per Windows ufficiale include anche una GUI indipendente. Non espone l'intero set di funzionalità di Git, ma consente le operazioni più comuni.

•The ability to partially take commits. For example: commit consists of 10 files. I take all changes from 8 files, but for two files I do cherry-pick in a manner that from current production version 5 I take two lines of code from file commit version 7 and few lines from file commit version 9 (effectively keeping those two files in "undefined version" so that I can supply my clients with the newest changes without all code changes preceding that newest feature I want). To achieve this point, for me it's not a problem to allocate an entire day digging through history and commits regardless if it's SVN or Git. That's my "preparing deploy" day anyway :)

In generale, Git ti incoraggia a utilizzare molti rami (di solito un ramo per caratteristica) e commetti spesso su ciascun ramo. I commit non dovrebbero mai contenere due modifiche non correlate. Questo dovrebbe consentire di cherry-pick le caratteristiche che vuoi per il commit di cherry-picking. Consente inoltre di creare una versione con solo le funzionalità richieste dai clienti unendo le diramazioni che corrispondono a queste funzionalità.

Quindi, se hai questo requisito, stai usando Git errato.

Tuttavia, se ti trovi nella situazione in cui devi unire solo parti di un commit, dovresti creare un nuovo commit sul ramo delle caratteristiche che ripristina le modifiche che non vuoi e quindi unire il ramo. Se vuoi continuare a lavorare sulle funzionalità che non vuoi unire in mainline, creerai quel commit su un nuovo ramo che unisci e continua a sviluppare sul vecchio ramo.

•Having numerical commit versions, not HASH-based ones!

Ci dispiace, ma Git non lo fa. Git incoraggia lo sviluppo parallelo decentralizzato su più filiali con più commit per ramo, quindi l'incremento dei numeri di commit non rientra nella filosofia di Git. Tuttavia, puoi utilizzare tag in Git per assegnare manualmente numeri (o altri descrittori) ai commit. Puoi farlo sul tuo ramo principale dopo la fusione dai branch delle caratteristiche.

    
risposta data 30.06.2017 - 14:51
fonte

Leggi altre domande sui tag

Dove dovrebbe essere effettuato il debouncing dell'evento, nell'emettitore o nel consumatore? OOP: attivazione di tipi polimorfici e mantenimento dello stato in tutto il flusso di lavoro