Miglior flusso di lavoro con Git & Github

Question

Sto cercando alcuni consigli su come strutturare correttamente il flusso di lavoro per il mio team con Git & GitHub.

Siamo recenti convertiti in svn ed è un po 'di confusione su come impostare al meglio il nostro flusso di lavoro quotidiano.

Ecco un piccolo background: mi sento a mio agio con la riga di comando e il mio team è piuttosto nuovo ma può seguire i comandi di utilizzo. Stiamo tutti lavorando allo stesso progetto con 3 ambienti (sviluppo, messa in scena e produzione). Siamo un mix di sviluppatori & designer quindi alcuni usano la GUI git e alcuni la CLI.

nostra messa a punto in svn andato qualcosa di simile:

• Abbiamo avuto un ramo di sviluppo, staging e produzione.
• Quando le persone erano sicure del codice, si impegnavano e quindi si univano alla messa in scena.
• Il server si aggiornerebbe da solo e in un giorno di rilascio (settimanale) faremmo una diff e inseriremo le modifiche sul server di produzione.

Ora ho impostato questi rami e ho ottenuto il processo con il server in esecuzione ma è il flusso di lavoro effettivo che mi sta confondendo.

Sembra eccessivo che ogni volta che qualcuno apporta una modifica a un file, creerebbe un nuovo ramo, eseguirà un commit, unirà ed eliminerà quel ramo. Da quello che ho letto sarebbero in grado di farlo su un commit specifico (usando l'hash), ho ragione? È un modo accettabile per fare cose con Git?

Qualsiasi consiglio sarebbe molto apprezzato.

Answer 1

È possibile copiare il flusso di lavoro da svn verbatim. Git può fare tutto svn can (ma può fare di più!). Ma il tuo flusso di lavoro potrebbe essere migliorato nonostante il CVS usato.

Se si desidera mantenere un numero minimo di rami (che nel caso in cui si è nuovi a git semplificherebbe di fatto le cose) nel flusso di lavoro che hai descritto suggerirei di avere (invece di un ramo di sviluppo) tre per rami -sviluppatore: devel-John, devel-mary, ecc:

devel-john >--\ 
       \ 
devel-mary >------> staging ---> production 
      /
devel-peter >-/ 

Questo è conveniente: tutti i cambiamenti di sviluppo sarebbero stati spinti al repository centrale (che spesso è una buona cosa anche per Git) senza conflitti e fusi in qualsiasi momento da chiunque sia disposto/obbligato a fare la fusione (ad esempio nel ramo di staging).

Answer 2

A seconda del flusso di lavoro, è possibile avere alcuni "importanti" rami nel proprio archivio centrale (ad es. Su github) che le persone possono clonare localmente. Questi corrisponderebbero a "stabile", "beta", "sviluppo", ecc. Un buon articolo su una possibile serie di diramazioni è this.

Una volta fatto, è possibile consentire alle persone di utilizzare la propria strategia. Preferisco mantenere i rami degli argomenti per i grandi progetti e ne ho uno chiamato "soluzioni rapide" per le cose veloci che devo fare. Se hai una squadra che lavora su un grande progetto che vogliono mantenere su un ramo separato tagliato fuori dal repository principale, puoi lasciarglielo fare senza alcun intervento. Se le persone preferiscono avere molti piccoli rami per provare cose ecc., Possono farlo anche loro.

Per quanto riguarda il test automatico e l'integrazione nella produzione dalla gestione temporanea, è possibile configurare i git git per farlo o avere un sistema in esecuzione che lo farà a intervalli regolari e segnala problemi.

Answer 3

Le idee da tenere a mente quando si lavora con un DVCS sono:

• distribuzione: anche se si dispone di un centro GitHub, il developper non si limitano a pubblicare (push) solo per che Repository GitHub. Possono: fork the repo e pubblicare nella propria versione (durante il recupero dal repository GitHub centrale ufficiale - denominato "a monte").
  Il vantaggio è che possono riscrivere la cronologia (reset, rebase --onto, rebase -i, ...) tutte le volte che vogliono, alla fine eseguiranno una richiesta di pull, consentendo a un integratore di gestire le proprie modifiche.

• uno dei publication: nel proprio repository locale, è possibile impostare come molti rami, come si vuole (non uno per ogni modifica del file, ovviamente, ma uno per ogni nuovo compito o un insieme di attività che è necessario sviluppare).
  Ma è anche possibile impostare i rami pubblici che verranno inviati ("pubblicati") al repository remoto.
  Vedere questa domanda su Git workflow, e anche articoli di JC Hamano sulle filiali remote:
  o Fun with remote branches (1)
  o Fun with remote branches (2)
  La frase "Quando le persone erano sicuri con il codice che avrebbero impegnarsi e quindi unire nella messa in scena" non si dovrebbe applicare con un DVC: commetti presto, commetti spesso, ma spinge ("pubblica") solo quando vuoi.

Answer 4

ci sono anche alcuni flussi di lavoro dei progetti descritti nel ProGit book che mostrano i comandi di Git sviluppatori utilizzeranno per seguire quotidianamente.

c'è un modello ben considerato Git ramificazione descritto http://nvie.com/git-model

Answer 5

Great post on GitHub Workflow da uno creatori GitHub Scott Chacon e autore del citato Pro Git book: P