Ho letto dello Integration Manager Workflow e sembra molto adatto per il nostro processo di sviluppo (uno sviluppatore principale del progetto, che rivede il lavoro degli altri sviluppatori prima che sia impegnato nel repository del progetto).Flusso di lavoro Git Integration Manager: uno o più repository?
Tuttavia, una cosa non mi è chiara. In questa visualizzazione dal libro Pro Git sembra come se ogni sviluppatore ha una propria repository (telecomando) per spingere a:
In this chapter (sezione "piccolo team privato"), però, sembrano utilizzare i rami per ottenere lo stesso tipo di flusso di lavoro.
È corretto? Quale tattica dovremmo usare; filiali o più repository? Suppongo che sia più difficile mantenere una sequenza temporale di commit se si estrae il lavoro da un altro repository?
Ma è anche possibile avere un repository centrale, con gli sviluppatori non manutentori che spingono solo a rami aggiuntivi, che il maintainer si fonde quindi nel master? – Rijk
Ah, il tuo esempio è molto chiaro, grazie. Questo flusso di lavoro presenta degli svantaggi rispetto al fare tutto questo in un unico repository (ad esempio, la cronologia dei commit persa, ecc.)? – Rijk
La cosa è con git, non hai mai un solo repository :) Gli sviluppatori avranno sempre un repository per conto proprio. È solo una questione di come si desidera che il DAG del repository assomigli, cioè chi spinge cosa a quale repo, o chi tira cosa da quale repo ecc. Ha senso? – ralphtheninja