Best practice per il 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 lo stiamo facendo bene. Sono interessato a sapere come gli altri utilizzano questo flusso di lavoro all'interno dei loro progetti.

Come lo usiamo: Ramifichiamo prima di ogni modifica, ci ricolleghiamo al master, ci impegniamo localmente e spingiamo al nostro repository github. Quindi ssh nel nostro ambiente di test e estraiamo il ramo master del repository github. Non abbiamo ancora capito abbastanza rebase , fetch o tagging .

Come vorrei usarlo: Vorrei poter accedere ai diversi server e estrarre una versione specifica taggata, come "fase 1" nel server. È possibile o avrei bisogno di due diversi repository github?

Dovresti git pull un ramo specifico nei server web o creare un nuovo alias da git push a?

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

Se tirare è la soluzione, puoi estrarre un tag specifico?

Answer 1

Fondamentalmente, puoi benissimo funzionare con uno "centrale" Repository GitHub.

• I tag essendo puntatori immutabili, possono essere utilizzati (e inviati) in qualsiasi momento, per essere estratti in qualsiasi ambiente di test o produzione. Ciò consente di eseguire alcune convalide, ma di solito non serve allo sviluppo.
• Tirare un ramo significa che puoi fare alcune evoluzioni all'interno di quel ramo (a causa di alcuni bugfix e aggiustamenti da apportare una volta che il codice è su un ambiente di produzione) e rimandarlo indietro per tutto il repository degli altri sviluppatori affinché possano ritirarlo e prenderlo in considerazione.

Quindi dipende da cosa stai facendo su quei server: solo la 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 specifici commit nella cronologia, ma i rami sono necessari ogni volta che è necessario isolare uno sforzo di sviluppo.

Answer 2

Leggi il libro Pro Git . Puoi leggere le pagine man di git 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 usarli.

Answer 3

Su GitHub, utilizzo un account per la mia azienda, dove è dove "benedetto" codice vive; Quindi 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 master sia il codice benedetto (e spinga sull'account aziendale), mentre tutti gli altri rami sono per il mio fork. Ecco 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

Dato che ho i permessi di commit per il repository aziendale, posso semplicemente unire (o cherry-pick) i commit da un ramo all'altro e spingerlo nella posizione appropriata. Ora, i repository separati non sono certamente necessari, ma poiché si tratta di un progetto open source, mi piace mantenere il "quot" ufficiale repository privo di 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.), Il che è particolarmente vantaggioso perché Github crea automaticamente tarball dei file su ogni tag, adatto per trasferire una versione specifica su una macchina che non necessita della cronologia completa.

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