Il posto in cui lavoro svolge le seguenti operazioni:
Ci viene chiesto di copiare manualmente incollare il codice da una versione all'altra. Quali sono le circostanze in cui i rami git sono considerati dannosi? (Aggiungiamo tutti codice al master)
I rami possono essere difficili da capire per le persone che non sono abituati a loro e possono essere difficili da spiegare ai manager se devi evitare di dire cose come "versioni diverse". Per un manager che utilizza un modello mentale basato su una divisione pulita del lavoro e un processo a cascata, l'idea che si desideri consentire a più di una persona di lavorare su un file alla volta è negativa, per non parlare di uno strumento che è progettato per incoraggiarlo.
Un ulteriore problema è che l'unione manuale può essere problematica e la distribuzione manuale di più. Basta un errore in un nuovo processo per riportare alcune persone a quella familiare. Potresti stare meglio prima automatizzando il processo esistente il più possibile, poi in seguito unendo i repository.
Ho scoperto che i programmatori che sono abituati a strumenti precedenti hanno spesso subito traumi considerevoli con operazioni di branch / merge. Ciò è particolarmente vero per gli utenti del cosiddetto "Visual Source Safe" in cui la fusione era difficile all'impossibile e in alcune versioni di quello strumento utilizzato per essere un modo veramente efficace per corrompere il database. Ma anche gli strumenti migliori spesso hanno difficoltà ad affrontare bene i cambiamenti concomitanti dei singoli file (spesso anche le persone si dibattono, il che è uno dei motivi del passaggio a unità di codice più piccole nel tempo).
Per quei programmatori suggerisco prima di farli usare git, che tu sembri aver fatto, e idealmente uno dei bellissimi front della GUI finisce per questo. I bei front end solitamente presentano le cose in un modo abbastanza familiare. Una volta che hai puoi mostrare loro come usi i rami sul tuo computer locale per gestire il flusso di lavoro. Nello specifico, sono facili da capire e la fusione è al 90% banale. Ho avuto qualche successo nel trasferire gli sviluppatori in questo modo.
Per rispondere alla tua domanda: Questo sembra essere il processo più cerebrale con git. L'intero punto dell'utilizzo di git è dovuto alla facilità di ramificazione e fusione. Copiare / incollare manualmente le modifiche è solo un problema, perché un giorno qualcuno dimenticherà di copiare qualcosa e non avrai traccia di chi l'abbia fatto.
Lavoro in un ufficio che richiede oltre 2 anni (e ancora contiamo) per passare a un modello di flusso di lavoro Git / Branch da uno strumento di gestione della configurazione basato su RCS. Git con gerrit, infatti, è stato installato 2 anni fa, ma le versioni e metà del team usano ancora il vecchio strumento. Il vecchio strumento era uno strumento di gestione della configurazione all'avanguardia nel 1994 e ha caratteristiche che Git / Gerrit non fornisce, ma il controllo di revisione basato su branch non è il suo punto di forza e il copia / incolla manuale è la modalità di gestione dei rami.
I ragazzi che hanno utilizzato questo strumento per 20 anni non hanno consapevolezza dei vantaggi di rami gestiti correttamente e fusione, e sono fermamente convinti che se non si apportano modifiche a tutte le fonti digitandole su una tastiera non è possibile che siano corrette .
Un altro problema con i rami si verifica anche quando i rami di codice divergono al punto che non sono più la stessa base di codice. Questo accade spesso nello scenario sopra visto che mantenere tutto in sincrono è difficile - se non è necessario un cambiamento in un repository, lo sforzo manuale per unirlo è visto come una perdita di tempo. Fatelo un paio di volte in pochi anni e la fusione automatica diventa più difficile da gestire rispetto alla fusione manuale.
Alcune cose semplici da risolvere per una persona sono impossibili da automatizzare. Poiché le unioni non sono state automatizzate, non esiste alcuna comprensione o disiplina attorno a queste cose e la fusione automatica delle filiali di solito non riesce. Un paio di difficili conflitti di unione rinforza la mentalità che non è affidabile. Le modifiche al layout del codice sono un ottimo esempio, come la modifica delle schede nello spazio bianco e l'addestramento dei cambiamenti nello spazio bianco nei file, cose che una persona non vede o non si cura, che fermano una fusione morta nelle sue tracce. Refactoring mentre si effettua una correzione di un difetto di linea, o peggio - facendo più modifiche non correlate in un commit - è facile per una persona dire quali bit sono necessari, ma uno strumento di fusione non può.
Nessuna quantità di formazione tecnica o riferimento alle migliori pratiche attuali cambierà il loro sistema di credenze. Finché non si spostano e iniziano a utilizzare la ramificazione, non si sentiranno a loro agio. Quindi una presa 22. Non si muoveranno perché non hanno fiducia in esso, non diventeranno fiduciosi fino alla mossa.
In parole povere, la maggior parte delle circostanze in cui i rami sono considerati dannosi è quando i dinasti che non sono disposti a cambiare e non li hanno mai usati hanno il controllo.
La mia precedente azienda aveva un processo di distribuzione manuale del codice copia / incolla. Tutti lo adoravano tranne gli ingegneri del rilascio. Non è stato modificato fino a quando un incidente ha cancellato diversi giorni di lavoro e il ripristino dal backup non era un'opzione.
Utilizzare uno strumento di controllo della versione con rami appropriati è stato facile da vendere.
Se puoi dimostrare alla direzione che è più conveniente e meno rischioso usare i rami correttamente, i mantra "i rami sono cattivi" dovrebbero cominciare a dissiparsi.
tldr: Risparmio di denaro > Branches Are Evil
La gente ha paura di cose che non capiscono, ecco perché pensano che il ramo sia malvagio.
Il problema è che decide della politica di controllo delle versioni di una società senza comprenderne la ramificazione ... beh, non molto professionale.
Stai utilizzando un approccio molto simile a quello che lo strumento git-flow ( link ) propone con dev / rami di produzione , la cosa buona di questo strumento è che è molto, molto facile da usare e definisce un modello di ramificazione rigido ma molto facile da capire. Può essere un ottimo modo per introdurre l'uso corretto di git per le persone nuove nello strumento.
Mi sono trovato di fronte a un paio di bruschi dossi che mi hanno sorpreso:
1) dover usare git dalla riga di comando (sono sempre stato fortunato e abbastanza pigro da eseguirlo attraverso una GUI o un'altra: P)
2) un negozio in cui il flusso di sviluppo dipende strongmente dalla ridefinizione anziché dalla fusione.
Dopo aver staccato le dita dei piedi un paio di volte, alla fine ho montato un "libro di ricette git" che uso per tenere traccia di come devo eseguire ogni processo che ho comunemente eseguito e alcuni dei passaggi di ripristino quando qualcosa va avanti whacky. È stato molto utile per me.
Mi ha anche aiutato a identificare i passaggi che sono "facili" e i passaggi che sono utili a conoscere, ma "difficile" o "pericoloso" (come "checkout -" o "push -f", che può causare la perdita di codice.)
Inoltre - e questo va alla tua domanda - ottenere il modello mentale giusto e ramificarlo aggiunge uno strato di complicazione. Quindi ci sono cambiamenti locali, cambiamenti graduali, modifiche commesse localmente e cambiamenti nel repository di origine. E capire dove sono attualmente i tuoi cambiamenti può essere un po 'sconcertante. I messaggi forniti da git possono essere molto oscuri e talvolta c'è una sintassi incoerente nel modo in cui si specificano l'origine e il ramo.
Quindi è come qualsiasi altro adattamento o mal-adattamento: il negozio attuale ha capito come far funzionare un processo estremamente negativo, ma facilitare la curva di apprendimento e passare alle migliori pratiche sarà in gran parte una questione di aiuto per rendere l'apprendimento curva meno ripida, e il lato negativo dell'apprendimento meno rischioso.