Questo documento è stato scritto per unificare le regole GitFlow interne all'azienda. Questo metodo non introduce GitFlow puro, ma è un mix di GitFlow e GitLab Flow, con le migliori pratiche aziendali adottate da molti anni. Aiuta a mantenere una cronologia pulita e leggibile del repository e a controllare meglio le modifiche e i cambiamenti. progetto cicli di vita.

Inizializzazione del repository

Dopo aver inizializzato il repository, creare un file sviluppare e maestro se non è stato incluso per impostazione predefinita. Il ramo develop dovrebbe contenere un ramo di sviluppo codice che è un mirror del ramo master con nuove funzionalità incluse. Il master contiene una versione stabile del codice, che rappresenta lo stato di produzione. Entrambi hanno una durata di vita infinita e, rispetto ad altri rami in Git Flow, non verranno mai rimossi. Impostare regole di protezione adeguate: richiedere la revisione delle richieste di pull prima dell'unione e richiede che i controlli di stato siano superati prima dell'unione. Si può anche prendere in considerazione l'idea di consentire solo a persone scelte squadra per unire le modifiche al master.

$ git init
$ git commit --allow-empty -m "Commit iniziale"
$ git checkout -b develop master

NOTA: A volte è importante per il progetto aggiungere più rami infiniti, ad esempio per rappresentare gli ambienti disponibili. Tuttavia, se possibile, mantenete la "regola del due".

Rami caratteristici

Quando si inizia a lavorare con una determinata funzione, bisogna innanzitutto assicurarsi di avere il proprio sviluppare ramo sincronizzato.

 $ git checkout develop && git pull --rebase

Quindi, eseguire il checkout nel ramo delle funzionalità. Nominarlo in base allo schema indicato: caratteristica-JIRA-TASK-ID oppure si può infrangere la regola e assegnare un nome diverso. In questo caso, assicuratevi che non sia in conflitto con gli schemi riservati a release, hotfix, bugfix, sviluppo o al ramo master. Mantenere gli ID dei task di JIRA vi aiuterà a gestire i rami di funzionalità in modo più efficace.

$ git checkout -b feature-JIRA-TASK-ID sviluppare

Questo ramo deve esistere finché la caratteristica in questione viene sviluppata e poi unita al ramo principale. Per eseguire il commit nel proprio ramo locale, seguire questo comando:

 $ git add .
 $ git commit -m "JIRA-TASK-ID: Descrizione attività"

Si consiglia di aggiungere altri commit al ramo locale, seguendo la regola "Impegnarsi presto e spesso". Tuttavia, alla fine, devono essere schiacciati in un unico commit che rappresenta un'attività JIRA. Impegnarsi spesso aiuta a gestire la cronologia dello sviluppo. Quando la funzionalità è pronta, è il momento di aprire una richiesta di pull per sviluppare un ramo. Per prima cosa, si può spingere il proprio ramo locale, se non è stato spinto troppo lontano:

 $ git push origin feature-JIRA-TASK-ID

Quando il ramo è pronto, aprire la cartella richiesta di pull su GitHub, seguendo questo articolo: https://help.github.com/en/articles/creating-a-pull-request

Prima di aprire una richiesta di pull, accertarsi di quanto segue:

• a descrizione corretta è stato dato - di solito, si collegare l'attività JIRAma si possono anche includere alcune informazioni utili relative al codice corrente.
• CircleCI i passaggi sono stati superati con successo
• il tuo I membri del team sono stati assegnati - è buona norma includere tutti i membri del team come assegnatari
• il sono stati selezionati i revisori - il numero di revisori dipende dal team
• il vostro codice è effettivamente pronto per la revisione - date un'ultima occhiata al vostro codice, ripensate se c'è ancora qualcosa da rifattorizzare, testatelo localmente e assicurarsi che sia pronto per le fasi successive.
• ci sono non ci sono conflitti di fusione e un ramo è aggiornato con develop - se ce ne sono, risolverli prima

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # usare il flag -i per squash
$ git push -f origin feature-JIRA-TASK-ID 1TP63Utilizzarlo con attenzione perché il flag -f sovrascrive il repository remoto

• mantenere solo i commit importanti - ogni commit dovrebbe essere rappresentato da un task JIRA, ad esempio, JIRA-TASK-ID: Configurazione di una nuova funzione; altri dovrebbero essere schiacciato durante il rebase il vostro ramo con il ramo di sviluppo
• avete il ramo di destinazione corretto selezionato
• non dimenticate di modificare lo stato dell'attività JIRA

Unione del ramo di funzionalità

È il momento di unire le modifiche al ramo di sviluppo quando:

• la richiesta di pull è stata approvata da alcuni membri del team
• tutti i test sono stati completati con successo
• non ci sono conflitti di fusione e la cronologia dei commit sembra a posto

Questa operazione può essere eseguita dal project manager o dallo sviluppatore di funzioni. Per eseguire l'unione, seguire i seguenti passaggi:

 $ git checkout develop
 $ git merge feature-JIRA-TASK-ID
 $ git push origin develop
 $ git branch -d feature-JIRA-TASK-ID
 $ git push origin :feature-JIRA-TASK-ID

Ora è possibile modificare lo stato delle attività di JIRA.

Comunicati

I rami di release devono essere creati da una persona responsabile della release corrente. Di solito, i rilasci vengono creati periodicamente, per esempio, in base al sprint ciclo di vita.

Versioni semantiche

Dare a un ramo di release un nome appropriato e un tag corrispondente non è un compito facile all'inizio. È buona norma iniziare a usare il versioning semantico (https://semver.org/) che consente un migliore controllo e rende più facile la lettura della cronologia di git. La stringa di versione è costruita secondo lo schema MAJOR.MINOR.PATCH:

• MAJOR - modifica che rappresenta modifiche incompatibili dell'API
• MINORE - aggiunta di nuove funzionalità in modo compatibile con le versioni precedenti
• PATCH - aggiunta di correzioni di bug compatibili con le versioni precedenti

Si possono anche usare suffissi speciali, come quelli che rappresentano i rami beta o legacy, o creare delle pre-release. In questo caso, è necessario assegnare un nome appropriato, ad esempio 1.1.0-beta.4, 1.1.0-beta.5 o 1.1.0-alpha.

Realizzazione di una liberatoria

Il ramo di rilascio dovrebbe essere un figlio di develop e potrebbe contenere solo commit legati alla correzione di bug.

Il nome del ramo deve essere basato sulla versione della release, con il prefisso release-: release-MAJOR.MINOR.PATCH. Il ramo di rilascio dovrebbe essere completamente testato sia automaticamente che manualmente sul ambiente di staging. Se si verificano dei bug, questa è l'ultima opportunità per spingere le correzioni corrette e rieseguire l'intero processo, a patto che non sia verificato positivamente e pronto per ulteriori elaborazioni. Quindi, il commit di rilascio dovrebbe essere spinto, con le modifiche della stringa della versione corrente del rilascio nei file, come package.json. Dovrebbe anche avere un impatto sul file CHANGELOG.md. Questo aiuterà a tenere traccia di tutte le modifiche prima di un rilascio vero e proprio e a preparare il contenuto per il rilascio su GitHub quando il processo di fusione sarà completato. Il singolo file di aggiornamento deve contenere tutte le modifiche al rilascio raggruppate in tre categorie: funzionalità, correzioni e manutenzione.

Per prima cosa, però, assicuratevi di avere entrambi i rami develop e master aggiornati.

 $ git checkout master && git pull --rebase
 $ git checkout develop && git pull --rebase
 $ git merge master
 $ git checkout -b release-M.M.P
 $ git add .
 $ git commit -m "Prodotto Nome rilascio M.M.P"
 $ git push origin release-M.M.P

A questo punto, si può decidere di creare un'altra richiesta di pull al master con il ramo di rilascio. Potrebbe essere una buona idea eseguire un ulteriore controllo se tutti i test passano bene sulla macchina remota.

 $ git checkout master
 $ git merge release-M.M.P
 $ git tag -a M.M.P # il messaggio di aggiunta può essere impostato tramite il flag -m
 $ git push origin M.M.P
 $ git push origin master
 $ git branch -d release-M.M.P
 $ git push origin :release-M.M.P

Andare quindi alla pagina dei rilasci di GitHub e premere il pulsante "Draft new release". Nel modulo visualizzato, selezionare il tag della versione corrente, impostare il titolo della release simile al commit della release (Product Name M.M.P release) e una descrizione adeguata, basata sul file CHANGELOG.md. Per i progetti pubblici, la descrizione deve contenere un elenco di tutte le PR incluse nella release corrente.

Nel caso in cui alcune correzioni di bug siano state applicate al ramo di rilascio, assicuratevi di aver aggiornato il vostro ramo di sviluppo:

$ git checkout develop && git merge master
$ git push origin develo

Correzioni a caldo e correzioni di bug

La differenza principale tra un bug e una correzione a caldo è il ramo di destinazione.

Correzione di bug

Le correzioni di bug dovrebbero essere applicate ai rami di rilascio come unica forma di aggiornamento del codice prima di unirlo a master. Per prima cosa, creare il ramo dal ramo di funzionalità corrente. Assicuratevi di averlo aggiornato localmente.

 $ git checkout release-M.M.P && git pull --rebase
 $ git checkout -b bugfix-M.M.P

Quindi eseguire il commit delle modifiche necessarie. Al termine del processo, creare una richiesta di pull e indirizzarla al ramo di rilascio. Seguire le indicazioni della sezione sul ramo delle caratteristiche. Il titolo finale del commit deve corrispondere allo schema indicato: "Bugfix M.M.P: Problem essence fix". Quando la richiesta di pull è approvata, è il momento di unirla alla release corrente.

 $ git checkout release-M.M.P
 $ git merge bugfix-M.M.P
 $ git push origin release-M.M.P

Correzione a caldo

Per eseguire una hotfix sul ramo master, si devono seguire passi molto simili a quelli di una bugfix, tenendo presente che il ramo di destinazione è ora il ramo master.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P rappresenta la release corrente

Quindi, seguire i soliti passi di sviluppo e, una volta terminato il processo, creare una richiesta di pull con il ramo master come target. Tenere presente che il commit finale deve corrispondere allo schema dato "Hotfix X.Y.(Z + 1): Problem essence fix". Quando ogni checkpoint è stato superato con successo, eseguire un merge a master. Questi passaggi differiscono da quelli presentati per la correzione di un bug, poiché è necessario aggiornare la versione corrente del rilascio.

 $ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # il messaggio di aggiunta può essere impostato tramite il flag -m
 $ git push origin X.Y.(Z+1)
 $ git push origin master
 $ git branch -d hotfix-X.Y.(Z+1)
 $ git push origin :hotfix-X.Y.(Z+1)
 $ git checkout develop && git merge master
 $ git push origin develop

Scheda informativa

Deposito init

 $ git init
 $ git commit --allow-empty -m "Initial commit"
 $ git checkout -b develop master
 $ git push origin develop
 $ git push origin master

Caratteristiche

$ git checkout develop && git pull --rebase
$ git checkout -b feature-JIRA-TASK-ID develop

Avviare lo sviluppo e i commit

$ git add .
$ git commit -m "IRA-TASK-ID: Descrizione attività" #initial commit
$ git push origin feature-JIRA-TASK-ID

Aprire la richiesta di pull

Rebase e preparazione per la richiesta di pull

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # usare il flag -i per squash
$ git push -f origin feature-JIRA-TASK-ID 1TP63Utilizzarlo con attenzione perché il flag -f sovrascrive il repository remoto

Unire le modifiche e cancellare il ramo

$ git checkout develop # il ramo dovrebbe essere sincronizzato con il ramo develop in questa fase
$ git merge feature-JIRA-TASK-ID
$ git push origin develop
$ git branch -d feature-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID

Comunicati

$ git checkout master && git pull --rebase
$ git checkout develop && git pull --rebase
$ git merge master
$ git checkout -b release-M.M.P

Creare un commit di rilascio

$ git add .
$ git commit -m "Nome prodotto M.M.P release" #initial commit
$ git push origin release-M.M.P

Aprire la richiesta di pull

Unire le modifiche, rilasciare ed eliminare il ramo

$ git checkout master # il ramo dovrebbe essere sincronizzato con il ramo master a questo punto
$ git merge release-M.M.P
$ git tag -a M.M.P # il messaggio di aggiunta può essere impostato tramite il flag -m
$ git push origin M.M.P
$ git push origin master
$ git branch -d release-M.M.P
$ git push origin :release-M.M.P

Correzione di bug

$ git checkout release-M.M.P && git pull --rebase
$ git checkout -b bugfix-M.M.P

$ Impegnare le correzioni
$ git add .
$ git commit -m "Bugfix M.M.P: Problema essenza fix" #initial commit
$ git push origin bugfix-M.M.P

Aprire la richiesta di pull

Unire le modifiche e cancellare il ramo

$ git checkout release-M.M.P Il ramo # dovrebbe essere sincronizzato con il ramo di rilascio corrente in questa fase.
$ git merge bugfix-M.M.P
$ git push origin release-M.M.P
$ git branch -d bugfix-M.M.P
$ git push origin :bugfix-M.M.P

Correzione a caldo

$ git checkout master && git pull --rebase
$ git checkout -b hotfix-X.Y.(Z+1) # M.M.P rappresenta la release corrente

$ Impegnare le correzioni
$ git add .
$ git commit -m "Hotfix M.M.P: Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Aprire la richiesta di pull

Unire le modifiche, rilasciare ed eliminare i rami

$ git checkout master # il ramo deve essere sincronizzato con il master corrente in questa fase
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # il messaggio di aggiunta può essere impostato tramite il flag -m
$ git push origin X.Y.(Z+1)
$ git push origin master
$ git branch -d hotfix-X.Y.(Z+1)
$ git push origin :hotfix-X.Y.(Z+1)
$ git checkout develop && git merge master
$ git push origin develop

Per saperne di più:

• Le buone pratiche di Codest per la creazione di software: CircleCI
• Come creare estensioni per Google Chrome utilizzando lo styler dei sottotitoli di Netflix?
• React: la struttura JavaScript più diffusa