Qual è il flusso di lavoro con 2 persone su un progetto

Vengo da te come programmatore principiante che sta lavorando al suo progetto (che sta procedendo bene). Il mio co-fondatore ha anche imparato a programmare e ha raggiunto un punto in cui probabilmente potrebbe iniziare a sistemare alcune cose e far accadere alcune cose.

Ha fatto un'ottima domanda, che era "come funzionerà". Qualcosa di cui potrei teorizzare solo perché non ho mai programmato con qualcun altro. Potresti consigliarmi sul miglior flusso di lavoro. Usiamo git.

Dovremmo possedere parti specifiche del sistema? Codice di accesso in? Revisione del codice?

Come lavori con> 1 sviluppatore?

Lavoro in un team che utilizza git, dove oltre 40 sviluppatori lavorano su più repository di codice (100+) in un dato 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 indispensabile. Nel tempo migliorerai il tuo git fu, scoprendo potenti funzionalità.

1. Avrai bisogno di un posto dove ospitare il tuo codice. Valuta di usare github o gitorious . Entrambi sono gratuiti, ma i tuoi repository saranno pubblici e visibili agli altri. Se desideri repository privati , puoi ospitarli gratuitamente su github o installare e ospitare il tuo server gitorious .
2. All'inizio è meglio non preoccuparsi dei flussi di lavoro avanzati che comportano il fork, richieste pull. Puoi iniziare usando git in modo centralizzato (brivido!). Tratta la tua copia ospitata come la copia autorevole del tuo codice sorgente. Chiamiamo questo repository upstream.
3. Uno di voi impegna tutto il codice in un repository git locale e lo spinge in questo upstreamrepository.
4. L'altro membro del team può clonare questo repository.
5. Un insieme di comandi minimo avrete bisogno di imparare sono clone, pull, push, add, commit, log, status, diff, branch, stash, apply, reset, format-patch, branch. Scopri di più su di loro da gittutorial .
6. Ognuno di voi ora può lavorare su qualsiasi parte del codice. Non preoccuparti di cosa succede quando entrambi modificate lo stesso file. Git è davvero bravo a gestire le fusioni e risolvere i conflitti.
7. Effettua piccoli commit atomici e scrivi buoni messaggi di log . Usa il tempo presente per i registri di commit. Puoi eseguire un numero qualsiasi di commit nella tua copia locale, poiché ciò non influisce sul lavoro dell'altra persona.
8. Quando ritieni che il tuo codice sia pronto per essere condiviso con altri, pubblicalo nel upstreamrepository. Una buona pratica è quella di tirare sempre prima di spingere . In questo modo mantieni il tuo repository sincronizzato con le altre modifiche.
9. Ripetere i passaggi 7e 8.

Una volta che ti senti a tuo agio con questo flusso di lavoro, puoi passare a cose più avanzate come: rami d'attualità, biforcazione, richieste di pull, fusione, riassegnazione interattiva di commit ecc.

Se vuoi davvero recensioni di codice, è fattibile solo con git ed e-mail. Quando la dimensione della tua squadra supera i 10+, ciò è idealmente fatto meglio con un qualche tipo di strumento online. Quindi in pratica ci sono molti modi per farlo, e questo è solo un modo semplice:

1. Creare una serie di commit con cui rivedere git format-patch. Questo genererà una serie di file patch. Invia per email 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 invia nuovamente un'email con i suggerimenti.
4. Ripeti 1-2-3 fino a che non è soddisfacente.
5. Il revisore conferma che è possibile spingere le patch upstream.

Uso github e tutte le sue funzionalità per questo. dai un'occhiata a http://www.github.com/ Quindi puoi usare filiali, forchette, problemi, tirare richieste per lavorare con il tuo partner.

La prima cosa che vorrei fare è esaminare un repository di codice centrale in modo che le modifiche possano essere unite e mantenute sincronizzate tra i due progetti. SVN è una buona semplice che ho usato in passato ed è stato intorno abbastanza a lungo che è abbastanza maturo SVN .

Dopodiché vorrei identificare tra voi due i ruoli che entrambi ricoprirete, ad es

1. Hai intenzione di scrivere la funzionalità del codice in modo casuale o una persona farà correzioni di bug mentre l'altra continua con le funzionalità.
2. Desideri creare un set di standard di codifica di base, ad es. Posizione del controvento, denominazione delle variabili dei membri privati, convenzione di denominazione delle variabili e dei metodi (CamelCase ecc.)
3. Quante volte devi effettuare il check-in. Suggerirei almeno una volta al giorno di assicurarti che entrambi vedano cosa sta facendo l'altro in particolare all'inizio. Anche se assicurati sempre prima di un check-in il codice è costruibile.
4. È il capo, ma diventerai il capo della programmazione?

In bocca al lupo!