Migliori pratiche del flusso di lavoro con git e github?

Question

Ho usato git e github con il mio piccolo team di sviluppatori per i nostri progetti. Non posso fare a meno di pensare che non stiamo facendo bene. Mi interessa sapere come gli altri usano questo flusso di lavoro all'interno dei loro progetti.

come le usiamo: Ci ramo prima di ogni modifica, si fondono nuovamente dentro il maestro, si impegnano a livello locale e spingere al nostro repo github. Quindi eseguiamo l'ssh nel nostro ambiente di test ed estraiamo il ramo master del repository Github. Non abbiamo ancora abbastanza afferrato rebase, fetch o tagging.

Come vorrei usarlo: Vorrei essere in grado di SSH nel server diversi e tirare una specifica tag di versione, come "fase 1" nel server. È possibile o dovrei avere due repository Github diversi?

Si suppone che sia necessario un ramo specifico nei server Web o creare un nuovo alias su git push?

È possibile controllare i candidati o gli ambienti di rilascio (testing, sviluppo, produzione) all'interno di un repository git? o hai bisogno di più?

Se tirare è la soluzione, puoi prendere uno specifico tag?

Answer 1

Fondamentalmente, si può benissimo funzionare con un repository GitHub "centrale".

• Tag essendo puntatori immutabili, essi possono essere utilizzati (e spinto) in qualsiasi momento, per essere estratto in qualsiasi test o ambiente di produzione. Ciò consente di convalidare alcune convalide, ma di solito non serve per lo sviluppo.
• Estrarre un ramo significa che è possibile apportare alcune evoluzioni all'interno di quel ramo (a causa di alcuni bugfix e regolazioni da apportare una volta che il codice è in un ambiente di produzione) e spingerlo indietro per tutti gli altri repository dello sviluppatore affinché possano ritirarsi e riprendere in considerazione.

Quindi dipende da ciò che si sta facendo su quei server: solo convalida (con uno stato accettato o rifiutato), o anche ulteriori sviluppi.
In ogni caso, un tag con una convenzione di denominazione appropriata è utile per tenere traccia di commit specifici nella cronologia, ma i rami sono necessari ogni volta che è necessario isolare uno sforzo di sviluppo.

Answer 2

Su GitHub, io uso un account per la mia azienda, che è dove vive il codice "benedetto"; Poi mantengo un fork personale, dove lavoro su cose che non sono ancora abbastanza stabili. Sul mio computer locale, gestisco entrambi in un repository, in modo che il master sia il codice benedetto (e spinga all'account aziendale), mentre tutti gli altri rami sono per la mia fork. Ecco la parte del mio .git/config:

[remote "origin"] 
     fetch = +refs/heads/*:refs/remotes/origin/* 
     url = git@github.com:xiongchiamiov/fourU.git 
[branch "hacking"] 
     remote = origin 
     merge = refs/heads/hacking 
[branch "editor"] 
     remote = origin 
     merge = refs/heads/editor 
[branch "problem-utils"] 
     remote = origin 
     merge = refs/heads/problem-utils 
[branch "tests"] 
     remote = origin 
     merge = refs/heads/tests 

[remote "trunk"] 
     fetch = +refs/heads/*:refs/remotes/trunk/* 
     url = git@github.com:xyztextbooks/fourU.git 
[branch "master"] 
     remote = trunk 
     merge = refs/heads/master 

Dal momento che ho impegnarsi autorizzazioni per il repo società, posso solo unire (o cherry-pick) impegna da un ramo in un altro, e spingerla fino alla appropriata Posizione. Ora, i repos separati non sono certamente necessari, ma dal momento che questo è un progetto open-source, mi piace mantenere il repository "ufficiale" libero da rami casuali creati dalle mie tangenti. Una volta raggiunto il punto in cui otterrà il versioning, ci sarà un ramo 0.x, con tag per ogni versione (0.1, 0.1.1, 0.2, ecc.), Che è particolarmente vantaggioso perché github crea automaticamente i tarball dei file ad ogni tag, ben adattato per tirare giù una versione specifica di una macchina che non ha bisogno della cronologia completa.

Dovresti leggere il blog di github; hanno avuto dei bei post che descrivono il loro flusso di lavoro di implementazione, che ovviamente coinvolge pesantemente git.

Answer 3

Leggi Pro Git book. Puoi leggere git man pages per un anno e ancora non capirlo: provare a imparare git leggendo le pagine man è come cercare di imparare una nuova lingua leggendo un dizionario, si può fare. Il libro ti insegnerà una manciata di flussi di lavoro che puoi avere con git, e quali comandi git usare e in quale contesto utilizzarli.