Dovrei unire il ramo dev al mio ramo della storia utente?

we should not pull down latest changes from dev branch and then merge those changes into the branch for the user story

Questo è probabilmente il risultato di una delle tre situazioni:

• Sviluppatori "pigri" che non desiderano riconciliare potenziali conflitti di unione più di una volta
• Gli sviluppatori che non capiscono come fare git si fondono
• Un codebase che è così poco modulare che nessuno può lavorare senza toccare il codice su cui altri stanno lavorando attivamente

Per il primo, che sembra probabile, è una questione di pigrizia. Se si dispone di un ramo dev attivo, sarà necessario eseguire il pull più volte su una funzione e potenzialmente più volte al giorno. La soluzione sta riconoscendo che risolvere conflitti di fusione di piccole dimensioni spesso è molto più facile di una massiccia fusione alla fine.

Se gli sviluppatori hanno paura della fusione di git, per qualsiasi ragione, potrebbero semplicemente fare qualcosa di orribilmente hacky. Full disclosure: le mie prime esperienze con git non avevo idea di cosa stavo facendo (ora lo faccio) e per le unioni, di solito ho fatto un "manuale" unione senza nemmeno risolvere le differenze di fusione. Se la tua squadra è altrettanto ingenua di come funziona git, potrebbe farlo per disperazione.

E per ultimo, se la base del codice è la causa principale, potresti essere sfortunato. In questo tipo di situazione è difficile mantenere aggiornato il tuo locale perché ricevi continuamente modifiche al tuo codice. Il refactoring potrebbe essere l'unico modo.

In definitiva però, scopri perché i tuoi sviluppatori vogliono farlo. Renderà più facile la vita in generale a fare pratica con questo.

La mia regola è che non unisci alcun ramo nel ramo dev se ci sono conflitti di fusione. La conseguenza logica è che è necessario unire il ramo dev al ramo prima unire il ramo feature in dev.

Da un punto di vista pratico: se unisci dev in branch o branch in dev, il risultato sarà esattamente lo stesso. Se unisci prima dev in branch, allora l'unione di un ramo in dev sarà banale, quindi questo è uno sforzo extra zero. Ma cosa succede se qualcosa va storto? L'unione può essere senza conflitti ma causare problemi. Molto meglio se questo accade solo nel tuo ramo e non influisce su tutti. O ci sono conflitti. Meglio risolvere i conflitti e quindi risolvere eventuali problemi che potrebbero essere stati causati, quindi tutti devono affrontare questo problema.

Quindi il risultato dell'unione dello sviluppo in filiale è che si può essere sicuri (se si usa tutta la cura necessaria) che la fusione in dev procederà senza intoppi e con un buon risultato.

Mettendo da parte l'angolo della storia (soprattutto dal momento che il nostro team non usa Bitbucket, quindi non posso parlare a quel punto), ci può essere un angolo di controllo di qualità / test da considerare.

Nella nostra azienda, in circostanze normali, QA effettua il test iniziale della funzione nel ramo della funzione, prima viene unita per lo sviluppo. Eseguono il "tutto funziona bene nella sandbox insieme" la convalida tramite alcune regressioni automatiche e regressione RC. Pensavamo che questo fosse l'approccio migliore, per consentire loro di testare da soli. Se altri sviluppatori hanno fatto il check-in per sviluppare e influenzare il comportamento del tuo codice e sono uniti al tuo ramo delle funzionalità, questo potrebbe avere un impatto sull'isolamento.

Non è perfetto e probabilmente dice qualcosa sulla nostra organizzazione / scomposizione / pianificazione di user story o feature, ma sto divagando:)

Detto questo, se notiamo che ci sono conflitti di fusione nella richiesta pull tra il nostro branch e il ramo sorgente prima di darlo a QA, noi andremo avanti e risolveremo quei conflitti (da unendo il ramo sorgente al ramo della caratteristica), per evitare che il QA testasse il lavoro più volte (in quegli scenari di conflitto particolarmente sgradevoli).