Processo di revisione del codice quando si utilizza GIT come repository?

6

Qual è la procedura migliore per la revisione del codice quando si utilizza GIT? Abbiamo un provider GIT esterno (Unfuddle) e abbiamo un limite all'utilizzo delle risorse, quindi non possiamo avere repository remoti dedicati per ogni dev.

Processo corrente:

  • Abbiamo un server GIT con un ramo master a cui tutti si impegnano
  • Gli sviluppatori lavorano sul mirror locale master o su un ramo di funzione locale
  • Dev push al master branch del server
  • Esegui la revisione del codice di richiesta sull'ultimo commit

Problema:

  • Qualsiasi bug nella revisione del codice è già in fase di master nel momento in cui viene rilevato.
  • Peggio, di solito qualcuno ha bruciato alcune ore cercando di capire cosa è successo ...

Quindi, vorremmo

  • Per eseguire la revisione del codice PRIMA della consegna nel "master".
  • Avere un processo che funzioni con un team globale (nessuna recensione oltre la spalla !)
  • qualcosa che non richiede che un singolo dev sia alla sua scrivania / macchina per essere acceso in modo che qualcun altro possa remotizzare (rimuovere la dipendenza umana, gli sviluppatori vanno a casa in fusi orari diversi)

Usiamo TortoiseGIT per una rappresentazione visiva di un elenco di file modificati, diff'ing file ecc. Alcuni di noi inseriscono una shell GIT quando la GUI non è sufficiente, ma idealmente vorremmo che il flusso di lavoro fosse semplice e basato su GUI (voglio lo strumento per sollevare qualsiasi carico, non i miei sviluppatori).

    
posta DeepSpace101 28.11.2012 - 23:52
fonte

2 risposte

13

Un modello semplice ma efficace è il richiesta di pull GitHub , dove il file dei contributori "si fonda per favore in il mio codice "richiede. Un maintainer esamina i changeset e decide se hanno bisogno di più lavoro o se sono adatti per la fusione. Potrebbe quindi fondersi nel ramo principale. Generalmente i committer non sono autorizzati a inviare direttamente al master branch (questo può essere personalizzato in base ai propri gusti, consentiamo ai commit "minori" di entrare direttamente in).

    
risposta data 29.11.2012 - 00:28
fonte
1

Git è un sistema di controllo della versione distribuito: non hai un solo repository con un ramo!

Puoi configurare più repository - uno per ogni sviluppatore - e un altro che è il repository principale. Quando una delle loro filiali è pronta per essere unita, lo sviluppatore richiede un'unione e le loro modifiche vengono estratte dal loro branch / repo nel master.

Prima che avvenga l'unione, il revisore può inserire le modifiche nel loro ambiente e rivederle prima di inviarle al master.

I vantaggi aggiunti sono che in questo modo uno sviluppatore può avere tutte le filiali che desidera, chiamato qualunque cosa vogliano, senza interferire tra loro o anche dover vedere il bucato sporco a vicenda.

Inoltre, impara il gergo: per "Devs commit al master branch del server" vuoi dire che spinge le loro modifiche al master?

    
risposta data 29.11.2012 - 00:41
fonte

Leggi altre domande sui tag