Implementazione di Good Git usando la strategia dei rami con Heroku?

Question

Qual è una buona strategia di implementazione da utilizzare con Git + Heroku (Ruby on Rails)?

Attualmente il modo in cui lavoro con la mia origine repository Git: Tutte le funzionalità (o 'storie') vengono prima controllate come succursali, quindi vengono unite con il master e inviate all'origine.

Qualsiasi elemento inviato all'origine/master attiva uno script che estrae il nuovo codice di rails nell'area di gestione temporanea (semplice server di gestione delle rotaie).

Quando arriva il momento di spingere una nuova versione di produzione su Heroku, dovrei creare un nuovo ramo (chiamato qualcosa come production_version_121) e spingerlo in qualche modo a Heroku?

Idealmente mi piacerebbe scegliere e scegliere le funzionalità delle precedenti versioni di sviluppo che dovrei includere nel ramo di produzione ... testarlo e inviare a Heroku.

Ad esempio, potrei non volere che tutto il codice più recente venga spinto alla produzione. Potrei desiderare che la caratteristica "a" su cui avevo lavorato e la caratteristica "c" si siano fuse in qualche modo nella produzione, senza includere la funzione sperimentale "b" che ha bisogno di più debug.

N.B. Cercherò di evitare capistrano all'inizio e ottenere qualcosa che funzioni manualmente per ora.

Pensieri? Migliori pratiche?

Answer 1

Nel progetto Gemcutter abbiamo semplicemente un ramo production.Tutte le modifiche che vogliamo vedere sul sito di produzione vengono fusi in quel ramo, e poi distribuiti con:

git push heroku production:master 

Il ramo staging ha uno scopo simile per il sito di staging (anche su Heroku)

Answer 2

Ci sono molti modi per farlo e dipende molto dalle tue preferenze.

Ti darò una strategia possibile in cima alla mia testa: Dato che hai già una configurazione di gestione temporanea automatica che utilizza il master, ti suggerirei di creare un ramo 'produzione'. Quando vuoi promuovere una correzione/funzionalità per la produzione, devi semplicemente unire il ramo dell'argomento al tuo ramo 'produzione'.

git checkout production 
git pull . my-topic-branch 
(resolve any conflicts) 

Quando si è pronti a realtà spinta quel codice al server di produzione, si dovrebbe tag il ramo utilizzando un nome univoco (probabilmente con un timestamp). Quindi spingere semplicemente il ramo di produzione in Heroku.

git checkout production 
git tag release-200910201249 

Io suggerirei di creare uno script o git alias per automatizzare la marcatura per i timestamp, dal momento che utilizza uno schema di denominazione coerente è importante. Io uso qualcosa di simile:

git config alias.dtag '!git tag release-`date "+%Y%m%d%H%M"`' 

che mi permette di fare basta digitare git dtag quando voglio etichettare un rilascio con un timestamp.

È possibile visualizzare i tag utilizzando git tag e visualizzarli utilizzando git show release-1234. Per ulteriori informazioni sui tag, eseguire git help tag. È inoltre possibile trovare questo Github guide sul tagging utile. Raccomando anche di leggere i flussi di lavoro di altre persone (qui è a nice writeup) e scegliere cosa scegliere per te.

Answer 3

mai da quando ho letto Vincent Driessen's A successful Git branching model, sono stato agganciato. La mia intera azienda (8 di noi) ora si è standardizzata su questo modello e alcuni altri posti che ho consultato hanno anche iniziato a usarlo.

Quasi tutti quelli a cui ho mostrato di dire che stavano già facendo qualcosa di simile e hanno trovato molto facile adattarsi.

In poche parole, si hanno 2 rami permanenti (master e sviluppo). La maggior parte delle volte ti limiterai a sviluppare dei rami e a unirli nuovamente allo sviluppo. Le cose diventano un po 'più complesse quando si inizia a fare rilasci di produzione e hotfix, ma dopo aver letto il post un paio di volte, diventa inciso.

C'è persino uno strumento da riga di comando chiamato git-flow per aiutarti.