Siamo un gruppo di sviluppatori, senza leader e penso che abbiamo un problema con la gestione dei progetti a un livello fondamentale. Quando abbiamo dei compiti (legati a storie o errori), abbiamo due opzioni:
- Crea un ramo volatile per ogni problema:
- Pull master
- apportare modifiche
- invia al nuovo ramo remoto
- attendi che qualcuno si unisca / selezionalo per masterizzarlo.
Lo svantaggio è che sorgono molti rami, la cui fusione richiede più lavoro del master master.
o
- Utilizza un ramo di sviluppo permanente per utente:
- Unisci master al mio ramo dev
- apportare modifiche
- spingerlo su remoto mio dev
- attendi che qualcuno unisca il mio dev con il master.
Lo svantaggio è che ci sono molti commit contenenti solo merge master per dev e unisci dev to master.
I veri problemi si verificano quando modifichiamo simultaneamente gli stessi file - a volte git non si accorge che le modifiche sono contraddittorie e causano errori imprevedibili.
Spesso cambiamo gli stessi file, cambiamo nome, spostiamo, cancelliamo, ne creiamo di nuovi, allo stesso tempo, perché dobbiamo eseguire un sacco di refactoring del vecchio codice c ++.
Quale di queste due opzioni è migliore? Che ci danno un bel log di git per errori di cattura efficienti in edizioni parallele e si incolpano facilmente l'un l'altro?
Come evitare la duplicazione delle ciliegie e l'eccesso di commit e, allo stesso tempo, assicurare che le filiali degli sviluppatori privati siano sempre aggiornate?