Che cos'è il flusso di lavoro con 2 persone in un progetto

Lavoro in un team che utilizza git, dove oltre 40 sviluppatori stanno lavorando su più repository di codice (100+) in qualsiasi momento. Abbiamo anche iniziato con pochissimi sviluppatori, aumentando le dimensioni del team in un arco di pochi anni. All'inizio però con poche persone puoi cavartela conoscendo solo un minimo di git. Con il passare del tempo migliorerai il tuo git fu, scoprendo potenti funzionalità.

1. Avrai bisogno di un posto dove ospitare il tuo codice. Prendi in considerazione l'utilizzo di github o generoso . Entrambi sono liberi di usare, ma i tuoi repository saranno pubblici e visibili agli altri. Se desideri repository privati puoi pagarlo a github o installa e ospita il tuo server proprio geniale .
2. All'inizio è meglio non preoccuparsi di flussi di lavoro avanzati che coinvolgono biforcazioni, richieste di pull. Puoi iniziare usando git in modo centralizzato (brivido!). Tratta la tua copia ospitata come copia autorevole del tuo codice sorgente. Chiamiamo questo repository upstream .
3. Uno di voi commette tutto il codice su un repository git locale e lo invia a questo repository upstream .
4. L'altro membro del team può clonare questo repository.
5. Un set di comandi minimi che devi imparare sono clone , pull , push , add , commit , log , status , diff , branch , stash , apply , reset , format-patch , branch . Ulteriori informazioni su di essi da gittutorial .
6. Ognuno di voi può ora lavorare su qualsiasi parte del codice. Non preoccuparti di cosa succede quando entrambi modifichi lo stesso file. Git è davvero bravo a gestire le fusioni e risolvere i conflitti.
7. Apporta piccole comunicazioni atomiche e scrivi buoni messaggi di log . Usa il tempo presente per i registri di commit. Puoi fare qualsiasi numero di commit come preferisci alla tua copia locale in quanto non influisce sul lavoro dell'altra persona.
8. Quando pensi che il tuo codice sia pronto per essere condiviso con altri, pubblicalo nel repository upstream . Una buona pratica è quella di tirare sempre prima di spingere . In questo modo mantieni il tuo repository sincronizzato con le altre modifiche.
9. Ripeti i passaggi 7 e 8 .

Una volta che ti senti a tuo agio con questo flusso di lavoro puoi progredire in argomenti più avanzati come: ramificazioni di attualità, biforcazione, richieste di pull, unione, ribattitura interattiva di commit ecc.

Se vuoi davvero recensioni di codice, è fattibile solo con git e email. Quando le dimensioni della tua squadra superano i 10+, ciò è idealmente meglio con qualche strumento online. Quindi in pratica ci sono molti modi per farlo, e questo è solo un modo semplice:

1. Crea un insieme di commit da rivedere con git format-patch . Questo genererà un set di file di patch. Invia queste patch al revisore.
2. Il revisore può applicare le patch con git apply . Questo applica la patch ma non crea un commit.
3. Rivedi il codice e rispondi con i suggerimenti.
4. Ripeti 1-2-3 fino a quando non è soddisfacente.
5. Il revisore conferma che le patch possono essere inserite upstream .

Uso github e tutte le sue funzionalità per questo. dai un'occhiata al link Quindi puoi utilizzare filiali, fork, problemi, richieste di pull per lavorare con il tuo partner.

La prima cosa che farei è esaminare un repository di codice centrale in modo che le modifiche possano essere unite e mantenute in sincronia tra i due progetti. SVN è un buon facile che ho usato in passato ed è stato abbastanza lungo da essere abbastanza maturo SVN .

Dopo vorrei identificare tra voi due i ruoli che giocherete entrambi.

1. Stai per scrivere la funzionalità del codice in modo casuale o una persona sta per eseguire correzioni di bug mentre l'altra continua con le funzionalità.
2. Vuoi creare una serie di standard di codifica di base, ad esempio posizione di controvento, denominazione di variabili membro private, convenzione di denominazione di variabili e metodi (CamelCase, ecc.)
3. Quante volte hai bisogno di fare il check-in. Ti suggerirei almeno una volta al giorno di assicurarti di vedere cosa sta facendo l'altro, soprattutto all'inizio. Anche se assicurati sempre prima di un checkin il codice è realizzabile.
4. È il capo, ma tu sarai il responsabile della programmazione?

Buona fortuna!