Hai studiato i comandi di Git ma vuoi comprendere come avviene realmente l'integrazione continua (Continuous Integration, CI)? O forse desideri ottimizzare le tue azioni quotidiane? Questo corso ti fornirà competenze pratiche sull'integrazione continua utilizzando un repository su GitHub. Non è pensato come un wizard da cliccare semplicemente; al contrario, eseguirai le stesse attività che le persone svolgono realmente al lavoro, nello stesso modo in cui lo fanno. Spiegherò la teoria mentre seguirai i passaggi pertinenti.

Cosa faremo?

Man mano che procediamo, creeremo gradualmente un elenco di passaggi tipici del CI, che è un ottimo modo per memorizzare questo elenco. In altre parole, svolgeremo le azioni che gli sviluppatori compiono durante l'integrazione continua. Utilizzeremo anche un semplice set di test per avvicinare il nostro processo CI alla realtà.

Questa GIF illustra schematicamente i commit nel tuo repository mentre progredisci nel corso. Come puoi vedere, non c'è nulla di complesso, solo l'essenziale.

Affronterai i seguenti scenari standard per il CI:

• Lavorare su una funzionalità;
• Applicare test automatici per garantire la qualità;
• Implementare una task prioritaria;
• Risoluzione di conflitti durante la fusione dei rami (merge conflict);
• Si verifica un errore in ambiente di produzione.

Cosa imparerai?

Sarai in grado di rispondere a domande come:

• Che cos'è l'integrazione continua (CI)?
• Quali tipi di test automatici vengono utilizzati nel CI e quali azioni li attivano?
• Che cos'è una pull request e quando sono necessarie?
• Cos'è lo sviluppo guidato dai test (Test Driven Development, TDD) e come si relazione con il CI?
• Effettuare un merge o applicare modifiche tramite rebase?
• Tornare indietro o correggere nella versione successiva?

Inizialmente traducevo termini come 'pull request', ma alla fine ho deciso di ripristinare alcune frasi in inglese per ridurre l'assurdità del testo. A volte utilizzerò un 'italiano tecnico' come il curioso verbo 'committare' dove le persone lo usano realmente sul lavoro.

Che cos'è l'integrazione continua?

Integrazione continua, o CI, è una pratica tecnica in cui ogni membro del team integra il proprio codice in un repository condiviso almeno una volta al giorno, e il codice risultante deve compilarsi senza errori.

Ci sono interpretazioni diverse di questo termine

Il tema della controversia è la frequenza delle integrazioni. Alcuni sostengono che unire il codice solo una volta al giorno non sia realmente sufficiente per una continua integrazione. Si porta ad esempio un team in cui tutti prendono il codice aggiornato al mattino e si integrano una volta la sera. Anche se questo è un'obiezione ragionevole, si considera comunque che la definizione 'una volta al giorno' sia abbastanza pratica, specifica e appropriata per team di diverse dimensioni.

Un altro obiettivo è che C++ non è più l'unico linguaggio utilizzato nello sviluppo, e la semplice richiesta di una build senza errori come metodo di validazione è debole. Un certo insieme di test (ad esempio, unit test eseguiti localmente) deve anche concludersi con successo. Al momento, la comunità tende a volere che tale richiesta sia obbligatoria, e in futuro "build + test di unità" diventerà probabilmente la norma, se non lo è già.

Integrazione continua differisce da consegna continua (Continuous Delivery, CD) in quanto non richiede un candidato al rilascio dopo ogni ciclo di integrazione.

Elenco dei passaggi che utilizzeremo durante il corso

1. Prendi l'ultima versione del codice. Crea un branch da master. Inizia a lavorare.
2. Crea commit sul tuo nuovo branch. Compila e testa localmente. Passato? Vai al passo successivo. Fallito? Correggi errori o test e riprova.
3. Pusha sul tuo repository remoto o branch remoto.
4. Crea una pull request. Discute le modifiche, aggiungi ulteriori commit man mano che la discussione continua. Fai passare i test sul branch delle funzionalità.
5. Unisci/ribascia i commit da master. Fai passare i test sul risultato della fusione.
6. Distribuisci dal branch delle funzionalità in produzione.
7. Se tutto è a posto in produzione per un certo periodo di tempo, unisci le modifiche a master.

️ Preparazione

Assicurati di avere il software necessario

Per seguire questo corso avrai bisogno di Node.js e Client Git.

Puoi usare qualsiasi client Git, ma fornirò solo i comandi per la riga di comando.

Assicurati di avere installato un client Git che supporti la riga di comando.

Se non hai ancora installato un client Git che supporta la riga di comando, puoi trovare istruzioni per l'installazione. qui.

Prepara il repository.

Dovrai creare una copia personale (fork) del repository modello con il codice per il corso. su GitHub. Chiamiamo questa copia personale repository del corso. Fatto? Se non hai modificato le impostazioni predefinite, il tuo repository del corso probabilmente si chiama.

continuous-integration-team-scenarios-students. Si trova nel tuo account su GitHub, e l'URL appare così:https://github.com//continuous-integration-team-scenarios-students.

Io mi riferirò a questo indirizzo semplicemente come

Я буду называть этот адрес просто Le parentesi angolari come.

Угловые скобки как indicheranno che devi sostituire tale espressione con il valore corrispondente. Assicurati che

siano abilitati per questo repository del corso. Se non sono abilitati, per favore attivali cliccando sul grande pulsante al centro della pagina, a cui puoi accedere cliccando su Actions nell'interfaccia di GitHub. GitHub actions включены для данного репозитория курса. Если они не будут включены, пожалуйста, включите их, нажав на большую кнопку в середине страницы, на которую вы можете попасть, кликнув Actions в интерфейсе GitHub.

Non puoi completare il corso seguendo le mie istruzioni se le GitHub Actions non sono abilitate.

Puoi sempre utilizzare la funzione di GitHub di visualizzare il Markdown per vedere lo stato attuale dell'elenco che stiamo creando, qui

https://github.com//continuous-integration-team-scenarios-students/blob/master/ci.md

Sugli aggiornamenti

Sebbene il modo migliore per completare questo corso sia farlo da solo, potresti incontrare delle difficoltà.

Se senti di non capire cosa fare e non riesci a proseguire, puoi dare un'occhiata al branch solution, che è nel tuo repository di partenza.
Per favore, non effettuare merge solution in master durante il corso. Puoi usare questo branch per capire cosa fare o per confrontare il tuo codice con quello dell'autore, sfruttando tutte le possibilità che Git ci offre. Se ti senti completamente perso, puoi sostituire completamente il tuo branch master con il branch solution e poi ripristinare la tua directory di lavoro allo stato del corso che ti serve.

Usa questo solo se è davvero necessario

Fai commit del tuo codice

git add .
git commit -m "Backup del mio lavoro"

Questi comandi

• rinominano master in master-backup;
• rinominano solution in master;
• e passano (checkout) a un nuovo branch master e riscrivono il contenuto della directory di lavoro;
• creano un ramo "solution" da "master" (che in precedenza era "solution") nel caso vi serva in futuro il ramo "solution".

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

Dopo queste operazioni, puoi utilizzare git log master per determinare quale commit ti serve.
Puoi ripristinare la tua directory di lavoro a questo commit in questo modo:

git reset --hard

Se sei soddisfatto del risultato, a un certo punto ti servirà pubblicare la tua versione del repository in un repository remoto. Non dimenticare di specificare esplicitamente il ramo remoto quando farai ciò.

git push --force origin master

Si prega di notare che stiamo usando git push --force. Probabilmente non vorrai farlo spesso, ma qui abbiamo uno scenario molto specifico con un solo utente del repository, che tra l'altro, sa cosa sta facendo.

Inizio a lavorare

Iniziamo a redigere la nostra lista di passaggi per il CI. Di solito inizi questo passaggio estraendo l'ultima versione del codice dal repository remoto, ma non abbiamo ancora un repository locale, quindi invece lo cloniamo dal remoto.

️ Compito: aggiorna il repository locale, crea un branch da master, inizia a lavorare

1. Clona il repository del corso da Le parentesi angolari come.
2. Esegui npm install nella cartella del repository del corso; ci serve per installare Jest, che utilizziamo per eseguire i test.
3. Crea un branch e chiamalo feature. Passa a questo branch.

4. Aggiungi il codice di test in ci.test.js tra i commenti che chiedono di farlo.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. Aggiungi il testo con i primi 4 passaggi nel file ci.md.

   1. Porta il codice più recente. Crea un branch da `master`. Inizia a lavorare.    
   2. Crea commit nel tuo nuovo branch. Esegui build e test localmente.  
   Passato? Vai al passaggio successivo. Fallito? Correggi gli errori o i test e riprova.  
   3. Push nel tuo repository remoto o nel branch remoto.  
   4. Crea una pull request. Discuti le modifiche, aggiungi ulteriori commit  
   el corso della discussione. Fai passare i test sul branch feature.  

   Comandi

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

Crea commit nel nuovo branch, esegui build e test localmente

Stiamo per configurare i test in modo che vengano eseguiti prima del commit, e poi committare il codice.

Scenari standard in cui i test vengono eseguiti automaticamente

• Localmente:
  • Costantemente o in risposta a modifiche specifiche nel codice;
  • Durante il salvataggio (per linguaggi interpretati o JIT-compiled);
  • Durante la compilazione (quando è necessaria la compilazione);
  • Durante il commit;
  • Durante la pubblicazione in un repository condiviso.

• Sul server di build o nell'ambiente di build:
  • Quando il codice viene pubblicato in un ramo/repository personale.
  • Il codice viene testato in questo ramo.
  • Si testa il potenziale risultato della fusione (di solito con master).
  • Come fase dell'integrazione continua/pipeline di distribuzione continua

In generale, più velocemente vengono eseguiti i test, più spesso è possibile permettersi di eseguirli. Una distribuzione tipica delle fasi potrebbe apparire così.

• Test unitari rapidi — durante la compilazione, nella pipeline CI
• Test unitari lenti, test rapidi di componenti e integrazione — durante il commit, nella pipeline CI
• Test lenti di componenti e integrazione — nella pipeline CI
• Test di sicurezza, test di carico e altri test lunghi o costosi — nelle pipeline CI/CD, ma solo in determinate modalità/fasi/pipeline di build, ad esempio, durante la preparazione del candidato per il rilascio o quando avviati manualmente.

️ Assegnazione

Ti consiglio di eseguire prima i test manualmente utilizzando il comando npm test. Dopodiché, aggiungiamo un git hook per eseguire i nostri test al momento del commit. C'è un problema: i git hook non fanno parte del repository e quindi non possono essere clonati da GitHub insieme agli altri materiali del corso. Per impostare il hook, è necessario eseguire install_hook.sh o copiare il file repo/hooks/pre-commit nella cartella locale .git/hooks/.
Quando esegui un commit, vedrai che vengono eseguiti i test e che verificano la presenza di alcune parole chiave nella lista.

1. Esegui i test manualmente utilizzando il comando npm test nella cartella del tuo repository del corso. Assicurati che i test siano stati eseguiti.
2. Imposta il hook per il commit (pre-commit hook) eseguendo install_hook.sh.
3. Esegui il commit delle modifiche nel repository locale.
4. Assicurati che i test vengano eseguiti prima del commit.

Il tuo repository dovrebbe apparire così dopo aver eseguito queste operazioni.

Comandi

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

Pubblica il codice nel repository remoto o in un ramo remoto.

Dopo aver lavorato localmente, gli sviluppatori di solito rendono il loro codice accessibile al pubblico, in modo che possa eventualmente essere integrato con il progetto comune. Con GitHub, ciò viene generalmente raggiunto pubblicando il lavoro in una copia personale del repository (personal fork) o in un ramo privato.

• Utilizzando i fork, lo sviluppatore clona il repository remoto condiviso, creando una sua copia remota personale, nota anche come fork. Successivamente, clona questo repository personale per lavorarci localmente. Quando il lavoro è completato e i commit sono stati creati, li inserisce nel suo fork, dove sono accessibili agli altri e possono essere integrati nel repository comune. Questo approccio è comunemente utilizzato in progetti open source su GitHub. Viene anche trattato nel mio corso avanzato [Team Work and CI with Git].http://devops.redpill.solutions/).
• Un altro approccio consiste nell'utilizzare un solo repository remoto e considerare solo un ramo. master di un repository "protetto". In questo scenario, i singoli sviluppatori pubblicano il proprio codice in rami di un repository remoto, affinché altri possano visionare questo codice e, se tutto va bene, unirlo con master il repository comune.

In questo corso specifico, utilizzeremo un flusso di lavoro basato su rami.

Pubblichiamo il nostro codice.

️ Assegnazione

• Pubblica le modifiche in un ramo remoto con lo stesso nome del tuo ramo di lavoro

Comandi

git push --set-upstream origin feature

Crea una pull request

Crea una pull request con il titolo Revisione dei passaggi. Imposta feature come "head branch" e master come "base branch".

Assicurati di aver impostato master nel tuo fork del repository come "base branch", non risponderò a richieste di modifica nel repository con materiali del corso.

Nel gergo di GitHub, "base branch" è il ramo su cui basi il tuo lavoro, mentre "head branch" è il ramo che contiene le modifiche proposte.

Discuti le modifiche, aggiungi nuovi commit man mano che la discussione continua

Pull request (PR)

Pull request (PR) è un modo per discutere e documentare il codice, oltre a condurre una revisione del codice (code review). Le pull request prendono il nome dal comune metodo di integrazione delle singole modifiche nel codice condiviso. Di solito, una persona clona il repository ufficiale remoto del progetto e lavora sul codice localmente. Dopo di che, carica il codice nel proprio repository remoto personale e chiede ai responsabili del repository ufficiale di prelevarepull) il suo codice nei loro repository locali, dove lo esaminano e, possibilmente, lo integranomerge) nel loro lavoro. Questo concetto è noto anche con altri nomi, ad esempio, richiesta di merge.

In realtà non è necessario utilizzare la funzione pull request di GitHub o piattaforme simili. I team di sviluppo possono utilizzare altri modi di comunicazione, tra cui interazioni faccia a faccia, chiamate vocali o email, ma ci sono comunque diverse ragioni per adottare pull request in stile discussione forum. Ecco alcune di esse:

• discussioni organizzate relative a specifiche modifiche nel codice;
• come luogo per la revisione dei feedback sul lavoro incompleto sia da test automatici che da colleghi;
• formalizzazione delle revisione del codice;
• per poter chiarire in seguito le motivazioni e le considerazioni dietro un dato frammento di codice.

Di solito, crei una pull request quando hai bisogno di discutere qualcosa o ricevere feedback. Ad esempio, se stai lavorando a una funzionalità che può essere implementata in diversi modi, puoi creare una richiesta di modifica ancora prima di scrivere la prima riga di codice, per condividere le tue idee e discutere i tuoi piani con i co-autori. Se il lavoro è più semplice, la pull request viene aperta quando qualcosa è già stato fatto, registrato e può essere discusso. In alcuni scenari, puoi aprire un PR solo per motivi di controllo qualità: per eseguire test automatici o avviare una revisione del codice. Qualunque cosa tu decida, non dimenticare di @menzionare le persone il cui consenso è necessario nella tua pull request.

Di solito, quando crei un PR, fai quanto segue.

• Indichi cosa proponi di modificare e dove.
• Scrivi una descrizione che spieghi lo scopo delle modifiche. Potresti voler:
  • aggiungi qualcosa di importante che non sia ovvio dal codice, o qualcosa di utile per comprendere il contesto, come i bug pertinenti e i numeri dei commit;
  • menziona tutti con cui desideri iniziare a collaborare, oppure puoi menzionarli nei commenti in seguito;
  • chiedi ai colleghi di aiutarti con qualcosa o di controllare qualcosa di specifico.

Dopo aver aperto la PR, vengono eseguiti i test configurati per essere eseguiti in questi casi. Nel nostro caso, sarà lo stesso insieme di test che abbiamo eseguito localmente, ma in un progetto reale potrebbero esserci test e verifiche aggiuntive.

Per favore, attendi fino al completamento dei test. Puoi vedere lo stato dei test nella parte inferiore della discussione della PR nell'interfaccia di GitHub. Procedi quando i test sono stati completati.

️ Aggiungi una nota sulla discrezionalità dell'elenco dei passaggi CI

L'elenco utilizzato in questo corso è arbitrario e soggettivo, dobbiamo aggiungere una nota su questo.

️ Compito: creare una pull request per questa applicazione

1. Passa al ramo master.
2. Crea un ramo chiamato bugfix.
3. Aggiungi il testo della nota alla fine del file ci.md.

   > **GitHub flow** viene talvolta utilizzato come soprannome per riferirsi a una variante dello sviluppo basato su trunk quando il codice viene distribuito direttamente dalle branch di funzionalità. Questo elenco è solo un'interpretazione che utilizzo nei miei [corsi di DevOps](http://redpill.solutions). Il tutorial ufficiale è [qui](https://guides.github.com/introduction/flow/).

4. Effettua il commit delle modifiche.
5. Pubblica la branch bugfix sul repository remoto.
6. Crea una pull request con il nome Aggiungere un remark con la branch principale bugfix e la branch di basemaster.

Assicurati di aver impostato master nel tuo fork del repository come "base branch", non risponderò a richieste di modifica nel repository con materiali del corso.

Ecco come dovrebbe apparire il tuo repository.

Comandi

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

Approva la pull request "Aggiungere un remark"

️ Assegnazione

1. Crea una pull request.
2. Clicca su "Unisci pull request".
3. Clicca su "Conferma fusione".
4. Clicca su "Elimina branch", non ne abbiamo più bisogno.

Questa è la diagramma dei commit dopo la fusione.

️ Continua a lavorare e aggiungere test

Collaborare su una pull request porta spesso alla necessità di ulteriore lavoro. Questo è solitamente il risultato di una revisione del codice o di una discussione, ma nel nostro corso simuleremo ciò aggiungendo nuovi elementi nella nostra lista di passaggi CI.

Nella continuous integration viene solitamente applicato un certo grado di copertura per i test. Le esigenze relative alla copertura dei test variano e si trovano generalmente in un documento intitolato "linee guida per i contributori". Procederemo in modo semplice aggiungendo un test per ogni riga nella nostra checklist.

Quando si eseguono compiti, inizia provando a effettuare il commit dei test. Se hai configurato correttamente il pre-commit hook in precedenza, il test appena aggiunto verrà eseguito, non verrà superato e nulla verrà impegnato. Tieni presente che questo ci permette di capire se i nostri test controllano veramente qualcosa. È interessante notare che se fossimo partiti dal codice prima dei test, il passaggio dei test potrebbe significare sia che il codice funziona come previsto, sia che i test non controllano realmente nulla. Inoltre, se non avessimo scritto i test in primo luogo, potremmo dimenticarli completamente, poiché nulla ci ricorderebbe di farlo.

Sviluppo guidato dai test (TDD)

Il TDD raccomanda di scrivere i test prima del codice. Il processo tipico utilizzando TDD è il seguente.

1. Aggiungi un test.
2. Esegui tutti i test e assicurati che il nuovo test non venga superato con successo.
3. Scrivi il codice.
4. Esegui i test e assicurati che tutti i test siano superati con successo.
5. Effettua il refactoring del codice.
6. Ripeti.

Poiché i risultati dei test non superati vengono solitamente mostrati in rosso e quelli superati in verde, il ciclo è anche noto come "rosso-verde-refactoring" (red-green-refactor).

️ Assegnazione

Inizia provando a fare commit dei test e lascia che falliscano, poi aggiungi e fai commit del testo stesso della lista dei passi CI. Vedrai che i test passeranno ("verdi").
Poi pubblica il nuovo codice nel repository remoto e osserva come vengono eseguiti i test nell'interfaccia di GitHub in fondo alla discussione sulla richiesta di modifica, con l'aggiornamento dello stato PR.

1. Passa al ramo feature.

2. Aggiungi questi test in ci.test.js dopo l'ultima chiamata it (...);.

   it('5. Unire/ribaltare i commit da master. Far passare i test sul risultato della fusione.', () => {
     expect(/.*merge.*commits.*tests+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Distribuire dal branch della funzionalità in produzione.', () => {
     expect(/.*Deploy.*to+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. Se tutto va bene in produzione per un certo periodo, unire le modifiche a master.', () => {
     expect(/.*merge.*to+master.*/ig.test(fileContents)).toBe(true);
   });

3. Prova a fare commit dei test. Se pre-commit l'hook è impostato, il tentativo di commit fallirà.
4. Dopo, aggiungi questo testo in ci.md.

   5. Unire/ribaltare i commit da master. Assicurati che i test superino il risultato della fusione. 
   6. Distribuisci dalla branch di funzionalità con un bug nascosto in produzione.
   7. Se tutto va bene in produzione per un certo periodo, unisci le modifiche a master. 

5. Apporta e fai commit delle modifiche localmente.
6. Pubblica le modifiche nella branch feature.

Ora dovresti avere qualcosa del genere

Comandi

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

Conflitto di fusione

Vai alla richiesta di modifica Revisione dei passaggi.

Nonostante non abbiamo fatto nulla di male e i test per il nostro codice siano passati, non possiamo ancora effettuare la fusione della branch feature e master. Questo perché un altro branch bugfix è stato unito a master mentre lavoravamo su questo PR.
Questo crea una situazione in cui il branch remoto master ha una versione più recente rispetto a quella su cui abbiamo basato il branch feature. A causa di ciò non possiamo semplicemente riavvolgere HEAD master fino alla fine del branch feature. In questa situazione dobbiamo o effettuare una fusione (merge), o applicare i commit feature sopra (rebase) master. GitHub può effettivamente eseguire una fusione automatica se non ci sono conflitti. Purtroppo, nella nostra situazione, entrambi i branch hanno modifiche concorrenti nel file ci.md. Questa situazione è nota come conflitto di fusione (merge conflict), e dobbiamo risolverla manualmente.

Merge o rebase

Merge

• Crea un commit di unione aggiuntivo e mantiene la storia del lavoro.
  • Salva i commit originali dei rami con i relativi timestamp e autori.
  • Mantiene gli SHA dei commit e i riferimenti ad essi nelle discussioni delle richieste di cambiamento.
• Richiede una sola risoluzione dei conflitti.
• Rende la storia non lineare.
  • La storia può essere difficile da leggere a causa del gran numero di rami (sembra un cavo IDE).
  • Complica il debug automatico, rendendo ad esempio git bisect meno utile — troverà solo il commit di unione.

Rebase

• Riproduce i commit dall'attuale ramo sopra la base uno dopo l'altro.
  • Si formano nuovi commit con nuovi SHA, il che rende i commit su GitHub correlati alle richieste di pull originali, ma non ai relativi commenti.
  • I commit possono essere ricombinati e modificati nel processo o anche uniti in uno solo.
• Potrebbe essere necessario risolvere più conflitti.
• Consente di mantenere una storia lineare.
  • La storia può essere più facile da leggere, a meno che non sia troppo lunga senza motivi ragionevoli.
  • Il debug automatico e la risoluzione dei problemi sono un po' più semplici: rende possibile git bisect, può rendere i rollback automatici più chiari e prevedibili.
• È necessaria la pubblicazione del ramo con i commit trasferiti con il flag —force quando si utilizzano le richieste di modifica.

Di solito i team concordano sempre di utilizzare la stessa strategia quando devono unire le modifiche. Questo può essere un'unione "pulita" o l'applicazione "pulita" dei commit sopra, oppure qualcosa di intermedio, come eseguire l'applicazione dei commit in modalità interattiva (git rebase -i) localmente per i rami non pubblicati nel repository comune, ma unire (merge) per i rami "pubblici".

Qui useremo l'unione.

️ Assegnazione

1. Assicurati che il codice nel ramo locale master sia aggiornato dal repository remoto.
2. Passa al ramo feature.
3. Avvia l'unione con il ramo master. Verrà segnalato un conflitto di unione relativo a modifiche concorrenti in ci.md.
4. Risolvi il conflitto in modo che nel testo rimangano sia la nostra lista di passaggi CI che la nota su di essa.
5. Pubblica il commit di unione nel ramo remoto feature.
6. Controlla lo stato della pull request nell'interfaccia utente di GitHub, attendi che l'unione venga risolta.

Comandi

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Ottimo lavoro!

Hai completato il lavoro con l'elenco e ora devi approvare la pull request in master.

️ Compito: Approva la pull request "Steps review"

1. Apri la pull request.
2. Clicca su "Unisci pull request".
3. Clicca su "Conferma fusione".
4. Clicca su "Delete branch", poiché non ci serve più.

Questo è il tuo repository attualmente

Errore in produzione

Si dice che "i test possano essere utilizzati per dimostrare la presenza di errori, ma mai per dimostrare la loro assenza". Nonostante avessimo test e non ci fosse alcun errore, un insidioso bug è sfuggito in produzione.

In uno scenario simile, dobbiamo occuparci di:

• ciò che è distribuito in produzione;
• codice nel ramo master con l'errore, da cui gli sviluppatori possono iniziare un nuovo lavoro.

Rollback o correzione nella prossima versione?

"Rollback" (rollback) è la distribuzione di una versione precedente nota come corretta nell'ambiente di produzione e l'annullamento (revert) dei commit contenenti l'errore. "Correzione nella prossima versione" (fixing forward) è l'aggiunta di una correzione in master e distribuire una nuova versione il prima possibile. Poiché le API e gli schemi del database cambiano con la distribuzione del codice in produzione, con la consegna continua e un buon livello di test, il rollback è generalmente molto più complicato e rischioso rispetto alla correzione nella versione successiva.

Poiché il rollback non comporta alcun rischio nel nostro caso, procederemo in questo modo, poiché ci consente di

• correggere l'errore in produzione il prima possibile;
• rendere il codice master pronto immediatamente per iniziare un nuovo lavoro.

️ Assegnazione

1. Passa al ramo master localmente.
2. Aggiorna il repository locale dal repository remoto.
3. Annulla il commit di unione PR Revisione dei passaggi in master.
4. Pubblica le modifiche nel repository remoto.

Questa è la cronologia del repository con il commit di unione annullato.

Comandi

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ Autovalutazione

Assicurati che ci.md non contiene più il testo "sneaky bug" dopo l'annullamento del commit di unione.

Correggi l'elenco dei passaggi CI e riportalo in master

Abbiamo completamente annullato il commit di unione del ramo feature. La buona notizia è che ora non abbiamo più l'errore in master. La cattiva notizia è che è scomparso anche il nostro prezioso elenco dei passaggi di integrazione continua. Quindi, idealmente, dobbiamo applicare la correzione ai commit di feature e riportarli in master insieme alla correzione.

Possiamo affrontare il compito in modi diversi:

• annullare(revert) il commit che annulla la fusione feature con master;
• trasferire i commit dall'ex feature.

Diverse squadre di sviluppatori utilizzano approcci diversi in questo caso, noi trasferiremo i commit utili su un ramo separato e creeremo una pull request per questo nuovo ramo.

️ Assegnazione

1. Crea un ramo chiamato feature-fix e passa a esso.

2. Trasferisci tutti i commit dall'ex ramo feature nel nuovo ramo. Risolvi i conflitti di fusione che si sono verificati durante il trasferimento.

   

3. Aggiungi un test di regressione in ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. Esegui i test localmente per assicurarti che non terminino con successo.
5. Rimuovi il testo " with a sneaky bug" in ci.md.
6. Aggiungi all'indice le modifiche ai test e le modifiche nella lista dei passaggi e fa un commit.
7. Pubblica il ramo nel repository remoto.

Dovresti ottenere qualcosa di simile

Comandi

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

Crea una pull request.

Crea una pull request con il titolo Fixing the feature. Imposta feature-fix come "head branch", e master come "base branch".
Attendere fino al completamento dei test. Puoi vedere lo stato dei test nella parte inferiore della discussione del PR.

Assicurati di aver impostato master nel tuo fork del repository come "base branch", non risponderò a richieste di modifica nel repository con materiali del corso.

Approva la pull request "Fixing the feature"

Grazie per la correzione! Ti preghiamo di approvare le modifiche in master dalla pull request.

️ Assegnazione

1. Clicca su "Unisci pull request".
2. Clicca su "Conferma fusione".
3. Clicca su "Delete branch", poiché non ci serve più.

Questo è ciò che dovresti avere in questo momento

Congratulazioni!

Hai completato tutte le azioni che le persone in genere eseguono nel processo di integrazione continua.

Se hai notato problemi con il corso o sai come migliorarlo, apri un'issue in repository dei materiali del corso. Questo corso ha anche una versione interattiva che utilizza GitHub Learning Lab come piattaforma.

Fonte: habr.com