Share
Git offre numerosi vantaggi allo sviluppatore solista, ma è anche molto utile quando si parla di collaborazione di gruppo.
La chiave per stabilire un grande flusso di lavoro di squadra con Git è la comunicazione. Git è versatile, flessibile e può ospitare una varietà di modelli di utilizzo. Decidere il flusso di lavoro "regole della strada" in anticipo contribuirà ad eliminare l'attrito e la confusione e consentire a un team di sfruttare ciò che Git fa meglio: aumentare la produttività.
Detto questo, questo non sarebbe molto di un tutorial se non fornisse un tangibile flusso di lavoro per il team basato su Git da revisionare. Il seguente esempio si basa su un flusso di lavoro Git molto popolare realizzato da Vincent Driessen chiamato Git-Flow, sebbene differisca in alcuni modi chiave. Esistono diversi popolari flussi di lavoro Git che fluttuano nel Web: ti suggerisco di leggerne il più possibile in modo che il tuo team possa scegliere un set di regole che si adatti meglio.
Diamo inizio alla tua ricerca con il seguente flusso di lavoro:
Il maestro il ramo è sempre dispiegabile. Sempre.
A schierabile maestro il ramo è importante per molte ragioni. Innanzitutto, consente a chiunque di un nuovo progetto di creare e creare immediatamente senza errori. Niente è così frustrante come non essere in grado di costruire un progetto sconosciuto.
Secondo, maestro mostra lo stato attuale di produzione e / o il prodotto spedito. Se è necessario effettuare gli hotfix, è chiaro da dove si diramano.
Infine, un dispiegabile maestro è una rete di sicurezza. Se maestro è sempre dispiegabile, quindi possiamo distribuire senza preoccupazioni. La preoccupazione causa stress e lo stress causa indigestione. Nessuno ne ha bisogno.
Il sviluppare ramo dovrebbe essere il ramo principale dello sviluppo in corso. I rami feature vengono creati e uniti in sviluppare, e sviluppare rappresenta il bordo sanguinante della nostra base di codice.
Da entrambi maestro e sviluppare sono filiali permanenti e altamente trafficate, non dovrebbero mai essere lavorate direttamente. Invece, tutto il lavoro dovrebbe essere svolto nei rami delle funzionalità. Quando si implementa una nuova funzione, derivare da sviluppare e incidere la funzionalità.
Non ci sono regole rigide sulla denominazione delle filiali, specialmente per i rami delle funzionalità. Se un ramo è una correzione, è probabilmente meglio anteporre "fix-" ad esso. Se una succursale è una release, in genere è consigliabile che il ramo segua questo formato: "release-X.X.X".
In generale, i nomi delle filiali dovrebbero essere descrittivi. E forse divertente. Il gioco di parole occasionale e puntuale non andrebbe male.
Una volta che la tua nuova fantastica funzionalità è codificata, è tempo di riportarla in un ramo condiviso (supponiamo che ci stiamo unendo sviluppare). Ma prima di fonderci sviluppare, assicurati che il tuo branch di funzionalità abbia le ultime modifiche da sviluppare perché potrebbero esserci conflitti.
Tutte le risoluzioni dei conflitti dovrebbero avvenire nel tuo ramo delle funzionalità. Se si diramano per fare una piccola modifica / correzione e non hai spinto il ramo verso il telecomando, rebase sviluppare nel tuo branch funzionalità e quindi unisci il tuo branch feature in sviluppare. Spingi e poi sentiti libero di cancellare il tuo ramo di funzionalità locale.
Se hai spinto il tuo ramo verso il remoto, prima unisci sviluppare nel tuo ramo (risoluzione dei conflitti), quindi unisci il tuo ramo in sviluppare. Spingi e sentiti libero di eliminare sia la funzionalità locale che quella remota.
Quando si ridefinisce, tenere presente che è un distruttivo azione. Significato ... stai attento! Il rebasing è davvero utile per ripulire le cronologie dei commit, ma non vuoi riscrivere la cronologia su tutto ciò che è stato condiviso con qualcun altro.
Ecco un paio di regole per mantenerti al sicuro durante la ridefinizione:
Accentsconagua
sviluppare è un ramo condiviso. my-impressionante di funzionalità è una filiale locale. Ora sono pronto per unire my-impressionante di funzionalità in fase di sviluppo, ma voglio essere sicuro che qualsiasi cambiamento sia avvenuto in sviluppare vengono prima incorporati nel mio branch di funzionalità:git checkout my-awesome-feature git rebase sviluppare git checkout sviluppare git merge my-awesome-feature
Diciamo che abbiamo diramato, abbiamo codificato, ci siamo uniti / risistemati da sviluppare, e ora siamo pronti per unire nuovamente il nostro nuovo codice sviluppare. Ma dovremmo? Forse qualcuno dovrebbe rivedere prima le nostre modifiche ...
Le recensioni del codice sono una buona cosa! Ti permettono di ottenere preziosi feedback sul lavoro che hai svolto e, se non altro, aumentano la probabilità che gli errori vengano catturati e risolti.
È qui che le richieste pull di Git (e l'interfaccia di Bitbucket) sono utili. (Per un aggiornamento sull'apertura e sulla gestione delle richieste di pull in Bitbucket, controlla la seconda parte di questa serie, usando le richieste di pull come recensioni di codice.) Le richieste di pull possono essere molto più di una semplice revisione del codice modificato. Poiché le richieste pull sono basate sul marchio, possono diventare thread per la discussione e la collaborazione su singole funzionalità. Puoi incorporare foto per condividere disegni, commentare direttamente linee di codice e persino usare GIF ed emoji per divertirti un po '.
Quando si tratta di unire le richieste pull, è preferibile che l'unione venga creata dalla stessa persona che ha aperto la richiesta pull, perché è probabile che sia la persona che ha scritto il nuovo codice. Per ottenere ciò, i revisori devono lasciare un commento che approva il nuovo codice, ma in realtà non premere il pulsante di unione. Una volta che un compagno di squadra dà al codice un "pollice in su" (in senso figurato, o letteralmente con a :pollice su: emoji), l'apri richiesta di pull può quindi procedere e fondersi. Revisione tra pari e registri puliti: una cosa meravigliosa!
Una volta sviluppare è pronto per un rilascio, unire in maestro:
git checkout master git merge --no-ff sviluppo
Notare che --no-ff bandiera? Questo assicura che l'unione non sarà un avanzamento rapido, quindi creerà un nuovo commit. Perché lo vogliamo? Quindi possiamo taggarlo! Tag che commuta come nuova versione:
git tag -a vX.X.X -m 'Versione X.X.X'
Quindi unire maestro di nuovo in sviluppare così che sviluppare ha la versione commit.
A proposito di versioni, dovremmo usare il versioning semantico. Quello si rompe in Major.Minor.Patch. In generale, MAGGIORE è un numero intero di versione, viene utilizzato per modifiche massicce e / o pietre miliari. È consentito interrompere la compatibilità all'indietro. MINORE è usato per nuove funzionalità. Non dovrebbe rompere alcuna retrocompatibilità. PATCH è per piccole modifiche e correzioni, e non dovrebbe rompere alcuna retrocompatibilità. Dovremmo essere in una pre-release (0.x.x) fino al momento del lancio.
Non dovremmo mai spedire errori.
... ma quando lo facciamo, è meglio sistemarli velocemente. Da sviluppare potrebbe includere funzionalità non completate, gli aggiornamenti rapidi dovrebbero essere derivati dalla versione corrente, ovvero maestro (perché maestro è sempre dispiegabile!).
Per creare un hotfix, diramarlo maestro, fare la correzione, quindi fare a non fast-forward fondersi in maestro. Taggalo, quindi unisci maestro di nuovo in sviluppare (perché vorremmo sviluppare avere anche la correzione). Sentiti libero di cancellare il ramo dell'hotfix.
Parliamo dei messaggi di commit Git. Aderire a un formato comune renderà molto più facile esaminare i nostri registri. Ecco alcune buone regole:
Se vuoi leggere qualcosa di più sulla corretta scrittura dei messaggi di commit Git, dai un'occhiata al post di Tim Pope.
Consentitemi di notare ancora una volta che il flusso di lavoro delineato sopra vuole essere una linea guida, non regole rigorose che dovreste implementare rigorosamente per i vostri team. Se ti piacciono tutti, usali! Se qualcosa non funziona per te, ritagliati!
La cosa più importante è che il tuo team è d'accordo su un flusso di lavoro Git definito e quindi si attiene a questo. Una volta che ciò accadrà, la collaborazione seguirà e trarrai vantaggio dai vantaggi che Git ha da offrire lavorando come una squadra.
Scopri alcune alternative al flusso di lavoro Git-Flow nella guida ai flussi di lavoro di Atlassian Git.
