Gestire più persone che lavorano su un progetto con GIT

Se tutti gli sviluppatori hanno accesso al repository, non dovrebbe essere necessario fare qualcosa di speciale. Tireranno le modifiche dal repository, apportano le proprie modifiche, eseguono il commit localmente e poi tornano al repository pubblico quando hanno qualcosa di funzionante.

Se d'altra parte hai uno (o pochi) sviluppatori responsabili del commit sul repository e gli altri forniscono patch a questi. Chiedete a ciascuno di loro di duplicare il repository nei propri account e inviateli a inviare richieste di pull quando hanno un cambiamento che desiderano nel repository principale.

È anche possibile creare cloni specifici per lavorare su caratteristiche specifiche, se lo si desidera. Utilizzare lo stesso flusso di lavoro con le richieste di pull per ottenere modifiche nel repository principale quando la funzione è terminata.

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

Per le tue domande specifiche:

2. No, usa i rami per funzioni, correzioni ecc. che richiedono più di un commit. Più di uno sviluppatore può lavorare sullo stesso ramo.

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

Buona fortuna!

Lavoriamo con 2 sviluppatori e usiamo questo flusso di lavoro:

• Su Github abbiamo un ramo master e un ramo dev
• Il ramo principale è uguale alla produzione o contiene la distribuzione codice pronto
• Il ramo dev è più avanti del master e contiene attualmente tutto il nuovo codice lavorato su
• Localmente lavoriamo entrambi sul ramo dev e passiamo a github quando qualcosa è pronto
• L'altro dev recupera qualsiasi nuova modifica dal ramo dev prima di premere il suo nuovo codice
• Quando il ramo dev è buono, ci uniamo al ramo principale
• A livello locale abbiamo diverse filiali di problemi relativi alle funzioni ecc.

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

• Anche questo flusso funziona bene con la Distribuzione continua.
• Il tuo ramo principale contiene il codice attualmente in esecuzione sul tuo server di produzione.
• Il ramo di sviluppo contiene codice attualmente in esecuzione su un server di staging / testing.

Io lavoro con altri 3 sviluppatori, e ne soffriamo un bel po '. Gli sviluppatori a volte spingono i commit verso la produzione che non sono ancora pronti per il prime time, ma perché inseriranno altri commit nei loro cambiamenti e quindi entreranno in produzione. I rami di versione sembrano funzionare bene per noi. Quindi, se la versione 1.0 è la versione stabile corrente, creeremo un ramo per lo sviluppo v1.1. Gli sviluppatori apporteranno modifiche in questo ramo. Il nostro server di test controlla questo ramo e ritira le modifiche secondo necessità. Quando tutte le funzionalità di v1.1 sono pronte per l'esecuzione e il test viene eseguito, uniremo la v1.1 con master e push. Con le filiali, il team di sviluppo A può lavorare su v1.1 e il team di sviluppo B può lavorare su v1.2. Entrambe le squadre possono lavorare senza impatti l'un l'altro. Se la squadra A sviluppa qualcosa che B può usare, puoi trasformare queste modifiche in B senza incidere sulla produzione (ciò non accade molto spesso).

Usiamo anche un ramo di aggiornamento rapido che viene utilizzato per le modifiche immediate.

Ecco un link a un'immagine di come appare. link