Gestire più persone che lavorano su un progetto con GIT

Sono molto nuovo di GIT / GitHub (come nuovo a partire da ieri). Vorrei sapere qual è il modo migliore per gestire più persone che lavorano allo stesso progetto con Github. Attualmente gestisco un progetto con quattro sviluppatori.

1. Come posso procedere con il flusso di lavoro e assicurarmi che tutto sia sincronizzato?

   (Nota: tutti gli sviluppatori avranno un account universale.)

2. Ogni sviluppatore deve trovarsi in un ramo diverso?

3. Sarò in grado di gestire 2 persone che lavorano sullo stesso file?

Si prega di inviare una risposta dettagliata, non sono un timido lettore. Ho bisogno di capirlo bene.

Se tutti gli sviluppatori hanno accesso al repository, non dovresti fare nulla di speciale. Prenderanno le modifiche dal repository, apporteranno le proprie modifiche, si impegneranno a livello locale e quindi riporteranno nel repository pubblico quando qualcosa funziona.

Se d'altra parte hai uno (o pochi) sviluppatori responsabili di impegnarti nel repository, e gli altri stanno fornendo patch a questi. Chiedi a ciascuno di loro di clonare il repository nei propri account e di inviare richieste pull quando hanno una modifica che desiderano nel repository principale.

È anche possibile creare cloni specifici per lavorare su funzionalità specifiche, se lo si desidera. Utilizzo dello stesso flusso di lavoro con pull-request per ottenere modifiche al repository principale al termine della funzione.

Se per "Tutti gli sviluppatori avranno un account universale" intendi che tutti gli sviluppatori condivideranno un account GitHub e appariranno come lo stesso committer nel repository, questa è una cattiva idea. Crea account separati e configurali come collaboratori se desideri che tutti abbiano accesso commit.

Per quanto riguarda le vostre domande specifiche:

2. No, usa i rami per funzionalità, correzioni ecc. Che richiederanno più di un commit. Più di uno sviluppatore può lavorare sullo stesso ramo.

3. Sì, git gestisce i conflitti davvero bene, quindi non ci sono problemi a far lavorare le persone sullo stesso file. Nessun problema tranne, la risoluzione dei conflitti potrebbe non essere sempre banale se ci sono cambiamenti fondamentali in un file che è stato modificato da più di un membro. Questo, tuttavia, non può essere superato parlando insieme. Il controllo della versione non sostituisce la comunicazione.

In bocca al lupo!

Lavoriamo con 2 sviluppatori e utilizziamo questo flusso di lavoro:

• Su Github abbiamo un ramo master e un ramo dev
• Il ramo principale è uguale alla produzione o contiene codice pronto per la distribuzione
• Il ramo dev è in testa al master e contiene tutto il nuovo codice su cui si sta attualmente lavorando
• A livello locale lavoriamo entrambi sul ramo di sviluppo e spingiamo su github quando qualcosa è pronto
• L'altro sviluppatore prende tutte le nuove modifiche dal ramo di sviluppo prima di inviare il suo nuovo codice
• Quando il ramo dev è buono, ci uniamo al ramo principale
• A livello locale abbiamo diversi rami di emissione di rami funzione ecc.

Vedo qui solo le risposte testuali, quindi ho pensato di pubblicare una foto di un bel gitflow per cominciare. Un'immagine descrive più di mille parole:

• Questo flusso funziona bene anche con la distribuzione continua.
• La filiale principale contiene il codice attualmente in esecuzione sul server di produzione.
• Il ramo di sviluppo contiene codice attualmente in esecuzione su un server di gestione temporanea / test.

Lavoro con altri 3 sviluppatori, e lottiamo un po 'con questo. Gli sviluppatori a volte spingono gli impegni nella produzione che non sono ancora pronti per la prima serata perché attireranno altri impegni nelle loro modifiche e poi spingeranno nella produzione. I rami di versione sembrano funzionare bene per noi. Quindi, se la versione 1.0 è l'attuale versione stabile, creeremo un ramo per lo sviluppo v1.1. Gli sviluppatori apporteranno modifiche in questo ramo. Il nostro server di test controlla questo ramo e apporta le modifiche necessarie. Quando tutte le funzionalità della v1.1 sono pronte per l'uso e il test è terminato, uniremo la v1.1 con master e push. Con le filiali, il team di sviluppatori A può lavorare su v1.1 e il team di sviluppatori B può lavorare su v1.2. Entrambe le squadre possono lavorare senza influenzarsi a vicenda. Se il team A sviluppa qualcosa che B può usare,

Utilizziamo anche un ramo hotfix che viene utilizzato per le modifiche immediate.

Ecco un link a un'immagine di come appare. http://nvie.com/img/git-model@2x.png