Qual è il processo migliore per la revisione del codice quando si utilizza GIT? Abbiamo un provider GIT esterno (Unfuddle) e abbiamo limiti sullutilizzo delle risorse, quindi non possiamo avere repository remoti dedicati per ogni sviluppatore.

Processo corrente:

  • Noi avere un server GIT con un ramo master a cui tutti si impegnano
  • Gli sviluppatori lavorano dal mirror master locale o da un feature branch locale
  • Devs invia al server “s master branch
  • Devs richiede revisione del codice sullultimo commit

Problema:

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

Quindi, vorremmo

  • eseguire la revisione del codice PRIMA della consegna nel “master”.
  • Avere un processo che funzioni con un team globale (niente recensioni sopra le spalle !)
  • qualcosa che non richiede che un singolo sviluppatore sia alla sua scrivania / macchina essere acceso in modo che qualcun altro possa remotare i n (rimuovi la dipendenza umana, gli sviluppatori tornano a casa in fusi orari diversi)

Usiamo TortoiseGIT per una rappresentazione visiva di un elenco di file modificati, diff “file ecc. Alcuni di noi cadono in un GIT shell quando la GUI non è sufficiente, ma idealmente vorremmo che il flusso di lavoro fosse semplice e basato sulla GUI (voglio che lo strumento allevi qualsiasi peso, non i miei sviluppatori).

Commenti

  • Stai eseguendo un test unitario prima di impegnarti?
  • @GuyCoder: per lo più lo facciamo.
  • Se lhost non fornisce la revisione del codice capacità, ottieni un host migliore. Dai unocchiata a Gerrit e vedi se riesci a trovare un host che lo fornisce.

Rispondi

A Il modello semplice ma efficace è il modello GitHub pull request , in cui il file dei contributori “si prega di unire il mio codice” richiede. Un manutentore rivede i changeset e decide se hanno bisogno di più lavoro o se sono adatti per la fusione. Quindi può fondersi nel ramo principale. I commit generalmente non sono autorizzati a eseguire il push direttamente al ramo master (questo può essere personalizzato in base ai tuoi gusti, consentiamo ai commit “minori” di entrare direttamente).

Commenti

  • Abbiamo un team ristretto di 7 sviluppatori professionisti (rispetto a contributori anonimi) a livello globale, quindi è sicuro che ognuno di loro invii direttamente il push al nostro master remoto. Anche se ' è un link + intro rispetto a risposte autonome che preferisco, in questo caso ha senso. Ottimo commento al link, grazie!
  • @Sid Con un team di 3 persone non ' lascerei che tutti si spingano al master.
  • Le richieste pull sono disponibili anche in Rhodecode e Atlassian Stash
  • @Andrew: Perché no? Ci sono molti problemi che possono essere generati incanalando lintero team che lavora anche se un punto di strozzatura. Questi possono essere tutti mitigati, ma una struttura di comando e controllo a punto singolo è più adatta ad alcune situazioni rispetto ad altre.

Risposta

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

Puoi configurare più repository – uno per ogni sviluppatore – e un altro che è il repository principale. Quando uno dei loro rami è pronto per essere unito, lo sviluppatore richiede ununione e le sue modifiche vengono estratte dal suo ramo / repository nel master.

Prima che quellunione avvenga effettivamente, il revisore può trasferire le modifiche in il loro ambiente e rivederli prima di spingerli a padroneggiarli.

I vantaggi aggiuntivi sono che in questo modo uno sviluppatore può avere tutti i rami che desidera, nominati come vuole, senza interferire luno con laltro o addirittura per vedere a vicenda i panni sporchi così tanto.

Inoltre, impara il gergo: con “Devs commit to server” s master branch “intendi che spingere le modifiche al master?

Commenti

  • sì, loro push il loro lavoro. Non possiamo ' avere repository remoti univoci sul server GIT perché paghiamo un hoster GIT e addebitano per repository. Volevi dire avere più rami remoti per sviluppatore? E quando dici the reviewer can pull the changes into their environment quali esatti comandi GIT (o flusso TortoiseGIT) intendi?
  • No, intendo avere più repository; uno per sviluppatore e su quel repository possono avere tutti i rami che vogliono. Per quanto riguarda pull, non ' so quale sarebbe il comando in TortoiseGIT, ma il comando è git pull . ' è lopposto di un push: esegui il pull delle modifiche dal repository remoto per aggiornare il tuo ambiente con il lavoro che altri sviluppatori potrebbero aver svolto.
  • Lo so git pull 🙂 …Chiedevo la sintassi completa per ispezionare il sistema repo / branch / tag per push / pull a cui ti riferivi. In questo momento facciamo git pull comunque, ' è appena fuori remote: master, che causa i problemi. Comunque, i link di Steven ' erano fantastici. Grazie
  • A tutti gli effetti pratici in questo caso un ramo nel repository ospitato è esattamente lo stesso di un altro repository.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *