Il nuovo sviluppatore non può tenere il passo con le fusioni di filiali

Suppongo tu stia usando git. Se è così, usa git rebase -i (il -i significa interattivo). Rendilo un compito quotidiano (anche più frequentemente, se necessario) per rebase il tuo ramo contro il ramo di sviluppo. Questo apporta le modifiche in modo incrementale ogni giorno (almeno) per mantenere aggiornato il tuo ramo delle funzionalità. Se ci sono conflitti durante il tuo rebase giornaliero, devi parlare con il tuo team su chi sta lavorando su cosa.

Se lo esegui quotidianamente, probabilmente non avrai bisogno della parte interattiva. Lascia che faccia la sua cosa.

Sono uno sviluppatore abbastanza esperto e mi ci vuole ancora un po 'di tempo per iniziare a lavorare su un nuovo progetto. Nel tuo caso, sembra che tu abbia diverse persone che lavorano sullo stesso progetto contemporaneamente, quindi è un progetto molto grande, o un nuovo progetto che si sta evolvendo rapidamente. In entrambi i casi, non preoccuparti se ti occorrono diversi mesi per entrare nel flusso. Se cambio i progetti per 2 o 3 settimane e poi torno indietro, posso impiegare alcune ore (o anche un giorno o due) per ottenere completamente "di nuovo" un progetto che ho scritto al 100% da solo!

In breve, non preoccuparti di essere lento in questo momento. Il modo migliore per continuare a praticare. Non aver paura di chiedere ad altri sviluppatori su aspetti dei progetti che non capisci.

Questo potrebbe essere un segno di cattiva ingegneria del software da parte dell'azienda. Troppe interdipendenze, problemi diversi con funzioni sovrapposte, tentativi di affrontare problemi nell'ordine sbagliato ecc. Possono causare la situazione che stai descrivendo. Suggerisco di unire regolarmente develop al tuo ramo durante lo sviluppo

Le risposte accettate credo siano più di natura tecnica "come usare Git better", penso che questo sia più un problema di squadra che un problema di ingegneria o di strumenti.

Se stai incontrando molti conflitti di unione significa che tu e qualcun altro del team state calpestando le altre dita dei piedi.
Tu o loro dovrebbero mirare a sviluppare uno spazio personale durante la codifica ed evitare di lavorare in aree già occupate.

Nel mio team, tendiamo verso un alto grado di proprietà delle attività.
Solitamente prendo la proprietà completa e completa di due o tre file alla volta e lavoro su di essi in un ramo per un giorno o due al massimo.
In genere, se qualcun altro tocca questi file è solo se assolutamente necessario per le proprie attività, in genere non lavoriamo insieme nello stesso blocco di attività!

Se stai scoprendo che devi unire un po 'tutto il codice di tutte le tue squadre è in un posto (che è qualcosa da evitare di per sé) o tutte le tue attività sono.

Tutto ciò che ho detto, come nuovo dev non sei probabilmente in grado di far valere, richiedere o addirittura suggerire davvero qualche tipo di ristrutturazione.
Quello che mi aspetterei è che i tuoi compiti siano stati assegnati come roba da "imparare le corde" che dovrebbe essere ragionevolmente accessibile al tuo livello di abilità, al fine di farti entrare nella squadra. Probabilmente sono stati selezionati dai compiti di un collega che sta ancora lavorando nella stessa area, quindi i tuoi conflitti di fusione.
La soluzione a questo è quindi di collegarlo, risolvere i problemi, affrontare i conflitti di fusione nel miglior modo possibile e non preoccuparti troppo, a patto che tu stia facendo del tuo meglio è compito del tuo manager preoccuparsi di i tuoi progressi.
Ti sentirai più veloce e più sicuro mentre vai, ei tuoi colleghi ti daranno più autonomia e ti metteranno meno di conseguenza.

La cosa più importante della fusione è che più a lungo si attende, più diventa doloroso. E il problema cresce più che lineare. Tre volte più conflitti sono nove volte più lavoro. Ci sono alcune strategie:

Unisci con il ramo di sviluppo ogni volta che cambia, così sei sempre vicino ad esso e non hai mai un numero enorme di conflitti.

Se impieghi molto tempo, potrebbe essere perché passi la maggior parte del tempo a capire quali sono le modifiche, e quindi a implementare le modifiche per un po 'di tempo. In tal caso, fondersi con il ramo di sviluppo prima di iniziare le effettive modifiche al codice.

Parla con i tuoi colleghi delle strategie per evitare conflitti. Si verificano conflitti se due persone modificano lo stesso codice. Non solo lo stesso file, ma lo stesso codice. Quindi ho bisogno di una nuova funzione functionA e hai bisogno di una nuova funzione functionB, e la aggiungiamo entrambi alla fine dello stesso file, abbiamo un conflitto. Se lo aggiungiamo in luoghi diversi, nessun conflitto. Se lo aggiungiamo entrambi in un posto nel file in cui logicamente appartiene, è probabile che non abbiamo alcun conflitto.

Se hai conflitti, ottieni uno strumento di confronto, in modo da poter confrontare il ramo di sviluppo prima della fusione, il codice prima dell'unione, il codice originale e il codice unito e unire per mano.

Peggiore caso: non butti via il tuo lavoro, ma usa uno strumento di differenziamento buono per scoprire esattamente quali modifiche hai apportato, diramarti nuovamente dallo sviluppo e applicare tutte le modifiche apportate manualmente invece di ridigitarle.

By the time I'm ready to merge my branch back into develop (emphasis mine)

Gestire i conflitti in git merge è spesso più semplice di git rebase . In Git si può vedere l'intero elenco di file che sono stati modificati contemporaneamente. Indipendentemente dal numero di commit compiuti da altri colleghi, dovrai unire una volta . Con il flusso di lavoro di rebase, potresti finire per ottenere sempre gli stessi conflitti e doverli rivedere manualmente. Puoi finire per correggere il 13 ° commit e sentirti non puoi vedere la luce fuori dal tunnel .

In base alla mia esperienza, quando ho tentato di risolvere in modo ingenuo i conflitti rebase ripetuti, ho finito per perdere le modifiche di qualcuno o con un'applicazione che non si è nemmeno compilata. Spesso io e colleghi abbiamo lavorato molto ma siamo rimasti così sopraffatti dalla complessità dei conflitti ripetuti che abbiamo dovuto abortire e perdere il nostro lavoro precedente dopo una manciata di commit di rebase.

Ti suggerirò alcune tecniche, ma possono solo aiutare l'unione a diventare più facile che automatizzare l'attività.

• File di risorse / lingua . Se hai modifiche additive in un file di risorse, assicurati di spostarle sempre alla fine del file in modo da poter facilmente ricordare le tue modifiche rispetto a altri 'modifiche. Potresti essere in grado di copiare e incollare le modifiche nella parte inferiore o semplicemente rimuovere i contrassegni di conflitto
• fare. Non. ASSOLUTAMENTE. RE-formato . Né tu né i tuoi colleghi sviluppatori dovrete eseguire un "massive reformat di codice" durante il lavoro quotidiano. Il codice reformat aggiunge un numero eccessivo di falsi positivi nella gestione dei conflitti. Il codice reformat può essere fatto
  • Incrementalmente, ad es. da ogni sviluppatore su ogni commit, non appena utilizzano uno strumento automatico (ad esempio, Eclipse ha un'opzione per riformattare al salvataggio, vanilla Visual Studio non ne ha). Assolutamente ogni sviluppatore deve utilizzare gli stessi standard di formattazione del codice, codificati in un file di formato che viene mangiato dal tuo IDE. Per darti un'idea, se sono 4 spazi o 2 schede non ha importanza, ma conta davvero se tutti usano lo stesso.
  • Poco prima del rilascio, da un capo squadra. Se un commit "code reformat" si verifica quando le persone non lavorano sui branch, cioè prima che si diramano, le cose andranno più facilmente
• Rivedi la divisione del lavoro tra i colleghi. Questa è la parte in cui viene la maggior parte dell'ingegneria. Come sottolineato da altre risposte, è l'odore del design se più sviluppatori che svolgono compiti diversi devono toccare le stesse risorse. Potresti dover discutere con il tuo team leader su quale parte deve essere modificata da ogni sviluppatore concorrente.

Ho anche visto alcune cattive abitudini nei flussi di lavoro Git nei miei team. Spesso le persone superano le loro filiali. Ho assistito personalmente a uno sviluppatore aggiungendo da 10 a 20 commit etichettati come "fix", ognuno dei quali impegnava una o due linee. La nostra politica prevede che i commit siano etichettati con i biglietti JIRA per darti un'idea.

@JacobRobbins suggerisce di rendere git rebase un'attività giornaliera. Vorrei spingere il suo approccio in avanti.

Per prima cosa, usa una volta rebase per ridurre il numero di commit a una manciata. E rebase solo sul ramo di sviluppo originale , che è il commit da cui hai diramato. Quando dico manciata, potrei dire 3 o 4 (ad esempio tutto front-end, tutto back-end, tutte le patch del database) o qualsiasi figura umanamente ragionevole. Dopo averli consolidati, utilizzare fetch e lavorare il rebase sul ramo upstream. Questo non ti salverà dal conflitto a meno che il tuo team non riveli il proprio approccio, ma renderà la tua vita meno dolorosa.

Se hai altre domande sulle attività specifiche, sentiti libero di cercare e chiedere su Stackoverflow.

[Modifica] sulla regola no-reformat e boy scout. Ho leggermente riformulato RE-format per evidenziare che quello che sto intendendo è il compito di formattare da zero l'intero file sorgente, incluso il codice che non è stato toccato da te. Al contrario, per formattare sempre il tuo codice, che è perfettamente boy-scouty, un certo numero di sviluppatori, incluso me stesso, sono usati per riformattare l'intero file con le capacità dell'IDE. Quando il file viene toccato da altri, anche se le linee interessate non vengono modificate nei loro contenuti e semantica, Git lo vedrà come un conflitto. Solo un editor molto potente e in grado di riconoscere la lingua può suggerire che il conflitto riguarda solo la formattazione e l'unione automatica del frammento meglio formattato. Ma non ho prove di uno strumento del genere.

Dopotutto, la regola del boy scout non ti obbliga a ripulire il casino degli altri. Solo tuo.

I conflitti di merge si ottengono se le modifiche apportate nel ramo sono vicine alle modifiche fatte dai tuoi colleghi nel ramo develop nel frattempo, ovvero se tu e i tuoi colleghi avete cambiato le stesse linee di codice o righe adiacenti in lo stesso file.

Quindi, per ridurre la probabilità di conflitti di unione, puoi provare a unire in precedenza in modo che i tuoi colleghi abbiano modificato meno righe nel frattempo, oppure puoi provare a modificare un numero inferiore di righe.

Per modificare un numero inferiore di righe, assicurati di apportare solo modifiche correlate all'attività.

Se hai bisogno di sperimentare diversi modi per raggiungere il tuo obiettivo, forse alcuni dei tuoi esperimenti hanno cambiato le linee che non hanno davvero bisogno di essere cambiate? Annulla queste modifiche prima di unire.

Esistono anche alcuni comandi Git che possono aiutarti a modificare il minor numero possibile di righe:

• git diff e git diff --staged per vedere quali linee sono state cambiate.
• git add -p per aggiungere solo alcune delle tue modifiche in un file.
• git commit --amend e git rebase -i da ritoccare vengono commessi già nel tuo ramo di funzione locale prima di essere trasferiti ad altri repository Git.

(Modificare il minor numero possibile di righe può anche facilitare il controllo del tuo lavoro o utilizzare strumenti che funzionano sulle differenze tra commit come git cherry-pick , git rebase , git bisect e git blame .)

Tuttavia, anche se riduci la probabilità di conflitti di unione, a volte continuerai a eseguire conflitti di unione. Quindi non aver paura di loro, ma impara come risolvere i conflitti.

Per prima cosa, non pensare di scartare le tue modifiche. Perderai le opportunità per imparare il processo di fusione.

In secondo luogo, trova una persona che ha lavorato sui file che causano conflitti. Puoi vedere la storia. Parla con la persona e risolvi i conflitti in quei file. Fai lo stesso per altri conflitti.

Se ci sono troppi conflitti, il tuo compito potrebbe essere minore, ma ripetitivo. Prova a trovare un modello. Ciò aiuterebbe a risolvere i conflitti con gli strumenti client dell'interfaccia utente Git. Io uso TortoiseGit. Aiuta a unire.

E per evitare in futuro

• È un'ottima pratica unire regolarmente il ramo di sviluppo al tuo branch di funzionalità.

• Se hai CI abilitato, verifica se lo strumento CI fornisce una build di ramo. Questo dovrebbe basarsi su ogni controllo che fai nel tuo branch di funzionalità, ma dopo lo sviluppo del ramo.

Dovresti eseguire regolarmente (giornalmente) il comando 'git fetch' (non git pull) dal tuo ramo di sviluppo. Ciò consentirà ad altre persone di apportare modifiche e inserirle nel ramo delle funzionalità senza tentare di integrare le modifiche nel ramo.

Questo è qualcosa su cui dovresti parlare con lo sviluppatore principale (non necessariamente il tuo manager), perché la tua azienda potrebbe avere i propri standard o metodi consigliati per gestire questo problema; è molto comune Non aspettare fino alla prossima settimana: scopri ora il processo e chiedi se puoi eseguire qualche lavoro banale (come la formattazione del codice o l'aggiunta di commenti) in modo da poter testare il processo.

Ovviamente la prima cosa è evitare che più persone lavorino sugli stessi file in primo luogo, almeno in un modo che porta a conflitti difficili. Aggiungere elementi alle enumerazioni non è un problema finché viene utilizzato un buon formato di codice. Cambiare il flusso di controllo in modi diversi e spostare il codice è molto più difficile. A volte questo è inevitabile comunque. Dovrai porre domande quando risolvi conflitti veramente complessi.

Detto questo, vedo molte risposte che raccomandano di unire / rebase a svilupparsi regolarmente. Sarei molto meno entusiasta di questo tipo di consiglio. Il tuo obiettivo a questo punto è di rendere il processo di risoluzione dei conflitti il più semplice e sicuro possibile. Una cosa che aiuterà moltissimo con questo processo è quella di avere immediatamente a disposizione tutti i test di regressione, compresi quelli nuovi che fanno parte della tua nuova funzionalità. Se si sincronizza il ramo molto regolarmente con lo sviluppo, invariabilmente finirai per dover risolvere i conflitti mentre per metà hai effettivamente implementato la tua funzione. Ciò significa che sarà molto più difficile cercare di capire che cosa dovrebbe fare il codice, perché non lo hai fatto. Prima di tentare di unire, assicurati che il tuo ramo sia un'unità coerente di cambiamento. Ancora meglio, rebase in un singolo commit prima di unire.

Ho cercato di non entrare nel merito di rebase su merge che è probabilmente per un'altra domanda. In questo contesto gli strumenti non contano davvero.

By the time I'm ready to merge my branch back into develop the others have made so many changes that resolving the conflicts is overwhelming

Sembra uno scenario ideale per programmazione coppie !

Maggiori informazioni sui vantaggi e gli approcci di base:
link

Naturalmente con il tempo accelererai nel tuo lavoro, ma può essere scoraggiante fino a quel momento, ed è anche a lungo termine. Inoltre, mentre le persone possono imparare rapidamente ad essere in un ambiente stressante, sempre sotto pressione per recuperare il ritardo, gli altri che non imparano bene sotto costante pressione saranno ostacolati.

Invece di lavorare su un ramo da soli e cercare di stare al passo con altri sviluppatori che sono ovviamente molto più veloci di te, dovresti invece lavorare direttamente (stesso PC) con un altro dev. In questo modo ottieni un consiglio immediato e probabilmente raccogli consigli su come accelerare ecc.

Avresti trovato l'approccio migliore per il codice particolare nel tuo progetto, dato che la programmazione di coppie non ha sempre senso per alcuni progetti - anche se probabilmente ha sempre senso per l'apprendimento anche se ti siedi e guardi qualcuno di più esperto di te (purché sia un buon dev, l'esperienza non significa necessariamente che usano buone pratiche).

Stare seduti con uno sviluppatore più veloce e più esperto può aiutarti:

• È probabile che riduca i conflitti di fusione poiché lavorare con qualcuno più esperto aumenterà il tempo di completamento rispetto al tuo lavoro da solo
• Dato che ti insegneranno è probabile che saranno più lenti di quanto non lavorerebbero da soli, quindi potrebbero esserci ancora conflitti di fusione e quindi è possibile superarli con qualcuno esperto e quindi forse raccogliere alcuni suggerimenti su come risparmiare tempo etc
• Aiuta a vedere i potenziali trucchi e modi per essere più rapidi (anche se essere lenti a volte è semplicemente una mancanza di esperienza piuttosto che una mancanza di buone pratiche)
• Può fare domande immediatamente quando qualcosa non ha senso o non è chiaro al 100%
• Lavorare 1: 1 è prezioso per l'apprendimento perché la persona che chiederai aiuto già comprenderà il codice esatto e lo scenario mentre ci lavorano, senza programmazione di coppie devi spiegare il codice e lo scenario, che spesso finisce un problema e quindi perdi il loro tempo / attenzione per ottenere davvero un consiglio molto utile
• Conoscere il processo di pensiero di qualcuno più esperto e esperto, e con buone comunicazioni imparerai sicuramente cose nuove

Is there a tactic I can use other than 'be better at coding'? I intend to bring this up with my supervisor next week.

Il mio consiglio è di discutere la programmazione delle coppie con gli altri sviluppatori e poi avvicinarmi al tuo supervisore. Se sono decenti apprezzeranno la tua iniziativa che ha più possibilità di lanciare i pro della programmazione pair (se ne hanno bisogno, la maggior parte delle persone lo sa ed è noto perché aiuta).

Qui ci sono alcuni problemi di fondo. I tuoi problemi di fusione sono molto probabilmente non la tua colpa e sono più comunemente un sintomo di cattive pratiche.

1) Idealmente dovresti fondere il tuo ramo in uno sviluppo ogni giorno. Cerca di avere un codice funzionante almeno una volta al giorno che superi tutti i test in modo da poterli unire allo sviluppo.

2) Se non hai un codice funzionante in qualsiasi momento durante la tua normale giornata di lavoro, probabilmente hai troppi pezzi di codice su cui lavorare. È necessario suddividere l'attività in attività più piccole che possono essere completate (idealmente indipendentemente l'una dall'altra) più rapidamente in modo da poterle unire.

3) I tuoi file di progetto sono probabilmente troppo grandi. Se ci sono molti conflitti di unione per un file ci sono troppe persone che lavorano su un file. Idealmente qualcosa su cui una persona sta lavorando dovrebbe essere separato da quello su cui stanno lavorando gli altri.

4) La tua squadra potrebbe essere troppo grande. Se trovi più semplice buttare via un'intera funzione e ricominciare da capo, è probabile che ci siano troppe persone che impegnano il codice nello stesso repository.

5) Potresti non avere standard di formattazione del codice coerenti. Se non si utilizza costantemente la stessa formattazione del codice, si otterranno molti conflitti diversi per lo stesso codice. A seconda di come è impostato il tuo git, questi potrebbero anche arrivare a conflitti di spazi bianchi (fine della linea, rientro, tabulazioni vs spazi).

6) Le persone potrebbero spingere le proprie modifiche direttamente al ramo di sviluppo.

Ecco cosa può tu fare: 1) Se non riesci a unirti allo sviluppo ogni giorno, unisci / rebase si sviluppi nel tuo ramo ogni giorno (o più spesso).
2) Prova ad avere il tuo codice separato dal codice di ogni altro.
3) Parla con il resto del team di funzionalità più piccole, standard di codifica coerenti e organizzazione del codice migliore (file più piccoli, funzioni più piccole).

It actually seems easier to scrap my work and start over on the task, which of course is not a sustainable solution)

Il più delle volte, questo è quello che faccio, la prima volta che correggo un bug o apporto una modifica al sistema, sto imparando come farlo. La prossima volta che riparerò lo stesso bug, mi ci vorrà solo l'1% delle volte poiché ora capisco il problema.

Trovo anche che quando rifaccio un po 'di lavoro, scrivo codice migliore .....

Quindi non c'è niente di sbagliato nel creare un nuovo ramo dal master, rifare il tuo lavoro in esso, mentre usi il tuo "ramo privato" per ricordarti cosa devi fare.

È anche possibile che tu abbia scoperto un modo per suddividere le tue modifiche in parti logiche e corrette, ciascuna delle quali viene unita al ramo principale una volta completata. Ad esempio, i test unitari e le modifiche al codice back-end possono essere eseguiti e uniti. Quindi, in un'operazione separata, è possibile eseguire le modifiche all'interfaccia utente che ne fanno uso, con conseguente minore rischio che qualcuno modifichi lo stesso file dell'interfaccia utente.

Se non vuoi unire il ramo di sviluppo nel tuo ramo troppo spesso, puoi ottenere un flusso di lavoro che è più simile a svn usando git pull --rebase . Questo tirerà i nuovi commit e ridicherai il tuo commit su di loro. Ciò significa che quando unisci il tuo ramo in via di sviluppo, sarà una fusione rapida (come se avessi aggiunto tutti i tuoi passati commit contemporaneamente uno dopo l'altro) e non avessi conflitti di fusione, perché li hai risolti tutti durante %codice%.

Ma più impegni esegui prima di unire il tuo ramo in via di sviluppo o di sviluppo nel tuo ramo, più complicato sarà il successivo rebase e sovverte un po 'il senso dei rami di funzionalità, poiché il tuo ramo esiste solo fino a quando è immerso.