Utilizzo di Git per la collaborazione su un progetto a 4 persone

Question

In uno dei miei progetti universitari sono in un gruppo di 4 sviluppatori incaricato di sviluppare un'applicazione web da zero. Abbiamo tutti una conoscenza di base di Git e abbiamo deciso di utilizzarlo per la collaborazione basata su codice, abbiamo creato un repository e tutti collaborano su GitHub.

Negli ultimi due mesi abbiamo semplicemente clonato e effettuato il commit dal/al master, e questo ha funzionato bene. Ultimamente però, ci sono stati momenti in cui due o più persone lavorano contemporaneamente alla base di codice e spesso finiamo con alcune persone che sono in ritardo sul commit e che devono clonare il pronti contro termine prima di impegnarsi, il che a volte finisce con il cambiare perduto.

Oggi, uno dei membri del gruppo ha parlato di avere un ramo "di sviluppo", che tutti noi cloniamo e ci impegniamo, e quindi ci uniamo al ramo master alla fine di ogni sprint. L'abbiamo provato, ma in realtà non abbiamo visto alcun miglioramento visto che stiamo ancora lavorando tutti dalla stessa base di codice, quindi si verifica lo stesso problema di prima.

Qualcun altro ha avuto l'idea di biforcarsi (questo è qualcosa di nuovo per me) il repository principale, lavorando su di esso e poi inviando richieste di pull al repository principale, che può quindi essere unito. Questo in pratica suona come un buon piano, perché le modifiche possono essere riviste e risolte se si rompe il codice. È così che lo capisco, comunque.

Ma come ho detto, siamo tutti abbastanza nuovi a Git e abbiamo una conoscenza molto basilare dell'intera idea. Qual è il modo standard di organizzare un team di 4 sviluppatori che lavorano su un repository Git? Ho dato un'occhiata alla documentazione di Git, ma è tutto piuttosto confuso per qualcuno che sa davvero solo come clonare e impegnarsi in un ramo master.

Grazie per qualsiasi aiuto!

Answer 1

Parlare di cose "standard" nelle metodologie di sviluppo è pericoloso perché non c'è quasi nulla di simile. I gruppi di sviluppatori tendono a organizzarsi in modi che funzionano per loro (o nel modo in cui il management dice loro di organizzarsi autonomamente).

Tutti gli approcci identificati sono modi validi per utilizzare i sistemi di controllo versione distribuiti. Ti suggerirei di non vedere enormi benefici dalle alternative perché stai lavorando a un progetto di campo verde universitario con un piccolo gruppo di persone nella stessa posizione geografica, parlando la stessa lingua, con abilità simili e con idee altrettanto chiare su quale dovrebbe essere il risultato. Git tende a brillare quando nessuno di questi non è il caso.

Per i progetti distribuiti in cui si desidera veramente che una persona funga da guardiano della versione canonica del progetto, le richieste di pull funzionano molto bene. Quando vuoi che tutti abbiano effettivamente uguale l'accesso al commit, un ramo di sviluppo è una buona soluzione. Le persone tendono a utilizzare i rami di sviluppo in modo che possano avere una versione sempre funzionante in giro per le persone da utilizzare. Presumo che tu non abbia al momento utenti, motivo per cui è improbabile che tu veda molto beneficio da questo approccio.

Continuerò come sei a meno che non parli tra loro e decidi che qualcosa non funziona per te come squadra, nel qual caso puoi decidere se uno degli altri modi di lavorare sarà migliore per tu.

Answer 2

È necessario esaminare Git Workflow e/oi modelli di ramificazione. Ci sono molti, e qui è uno per iniziare:

A successful git branching model

È necessario pensare al concetto di stampa, messa in scena, la produzione e così via, perché questo può essere facilmente rappresentato. Fondamentalmente riguarda l'organizzazione.