Hai imparato i comandi Git ma vuoi immaginare come funziona nella realtà l'integrazione continua (CI)? O forse vuoi ottimizzare le tue attività quotidiane? Questo corso ti fornirà competenze pratiche sull'integrazione continua utilizzando un repository GitHub. Questo corso non vuole essere una procedura guidata a cui puoi accedere semplicemente cliccando, al contrario, eseguirai le stesse azioni che le persone effettivamente fanno al lavoro, nello stesso modo in cui lo fanno. Spiegherò la teoria mentre segui i passaggi coinvolti.

Cosa facciamo?

Man mano che procediamo, creeremo gradualmente un elenco di passaggi CI tipici, che è un ottimo modo per ricordare questo elenco. In altre parole, creeremo un elenco di azioni che gli sviluppatori intraprendono durante l'integrazione continua, l'integrazione continua. Utilizzeremo anche una semplice serie di test per avvicinare il nostro processo CI a quello reale.

Questa GIF mostra schematicamente i commit nel tuo repository mentre avanzi nel corso. Come puoi vedere, qui non c'è nulla di complicato e solo il più necessario.

Verranno esaminati i seguenti scenari CI standard:

• Lavorare su una funzionalità;
• Applicazione di test automatizzati per garantire la qualità;
• Attuazione del compito prioritario;
• Risoluzione dei conflitti durante l'unione di rami (conflitto di unione);
• Si verifica un errore in un ambiente di produzione.

Cosa imparerai?

Sarai in grado di rispondere alle seguenti domande:

• Che cos'è l'integrazione continua (CI)?
• Quali tipi di test automatizzati vengono utilizzati nell'IC e in risposta a quali azioni vengono attivati?
• Cosa sono le pull request e quando sono necessarie?
• Cos'è il Test Driven Development (TDD) e come si collega alla CI?
• Dovrei unire o ribasare le modifiche?
• Eseguire il rollback o la correzione nella versione successiva?

All’inizio ho tradotto cose come “pull request” ovunque, ma di conseguenza ho deciso di restituire frasi in inglese in alcuni punti per ridurre il grado di follia nel testo. A volte userò "programmatore surzhik" come il meraviglioso verbo "impegnarsi" laddove le persone lo usano effettivamente al lavoro.

Cos'è l'integrazione continua?

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

Ci sono disaccordi su questo termine

Il punto controverso è la frequenza di integrazione. Alcuni sostengono che l'unione del codice solo una volta al giorno non sia sufficiente per un'integrazione continua. Viene fornito l'esempio di un team in cui tutti prendono un nuovo codice al mattino e lo integrano una volta la sera. Sebbene questa sia un’obiezione ragionevole, si ritiene generalmente che la definizione di “una volta al giorno” sia ragionevolmente pratica, specifica e adatta a team di diverse dimensioni.

Un'altra obiezione è che il C++ non è più l'unico linguaggio utilizzato nello sviluppo e che richiedere semplicemente un assemblaggio privo di errori come metodo di convalida è debole. Anche alcuni set di test (ad esempio, unit test eseguiti localmente) devono essere completati correttamente. Al momento, la comunità si sta muovendo per renderlo un requisito, e in futuro "build + unit test" diventerà probabilmente una pratica comune, se non lo è già.

Integrazione continua diverso da consegna continua (Continuous Delivery, CD) in quanto non richiede una release candidate dopo ogni ciclo di integrazione.

Elenco dei passaggi che utilizzeremo durante il corso

1. Inserisci il codice più recente. Crea un ramo da master. Iniziare a lavorare.
2. Crea commit sul tuo nuovo ramo. Costruisci e testa localmente. Passaggio? Vai al passaggio successivo. Fallire? Correggi errori o test e riprova.
3. Invia al tuo repository remoto o filiale remota.
4. Crea una richiesta pull. Discuti le modifiche, aggiungi altri commit man mano che la discussione continua. Fai in modo che i test passino sul ramo delle funzionalità.
5. Unisci/ribase commit dal master. Fai in modo che i test trasmettano il risultato dell'unione.
6. Distribuire dal ramo delle funzionalità alla produzione.
7. Se tutto va bene in produzione per un certo periodo di tempo, unisci le modifiche al master.

‼ Preparazione

Assicurati di avere il software giusto

Per seguire questo corso avrai bisogno Node.js и Cliente Git.

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

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

Se non disponi ancora di un client Git che supporti la riga di comando, puoi trovare le istruzioni di installazione qui.

Preparare il deposito

Dovrai creare una copia personale (fork) repository di modelli con il codice per il corso su GitHub. Accettiamo di chiamare questa copia personale archivio del corso.

Fatto? Se non hai modificato le impostazioni predefinite, molto probabilmente verrà chiamato il repository del corso continuous-integration-team-scenarios-students, si trova nel tuo account GitHub e l'URL è simile a questo

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

Chiamerò semplicemente questo indirizzo <URL репозитория>.

Parentesi angolari come <тут> significherà che devi sostituire tale espressione con il valore appropriato.

Assicurati che Azioni GitHub incluso per questo repository del corso. Se non sono abilitati, abilitali facendo clic sul pulsante grande al centro della pagina, a cui puoi accedere facendo clic su Azioni nell'interfaccia GitHub.

Non sarai in grado di completare il corso seguendo le mie istruzioni se le azioni GitHub non sono abilitate.

Puoi sempre utilizzare la capacità di GitHub di eseguire il rendering di Markdown per vedere lo stato attuale dell'elenco che stiamo componendo qui

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

A proposito delle risposte

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

Se ritieni di non capire cosa fare e di non poter continuare, puoi esaminare il thread solution, che si trova nel repository iniziale.
Per favore non unire solution в master durante il corso. Puoi utilizzare questo ramo per capire cosa fare, oppure per confrontare il tuo codice con quello dell'autore, sfruttando tutte le funzionalità che Git ci mette a disposizione. Se sei completamente perso, puoi sostituire completamente il tuo ramo master su un ramo solution e quindi reimposta la directory di lavoro sul passaggio del corso che ti serve.

Usalo solo se ne hai davvero bisogno

Impegna il tuo codice

git add .
git commit -m "Backing up my work"

Questi comandi

• rinominare master в master-backup;
• rinominare solution в master;
• checkout in una nuova filiale master e riscrivere il contenuto della directory di lavoro;
• Crea un ramo "soluzione" da "master" (che era "soluzione") nel caso in cui avessi bisogno di un ramo "soluzione" in futuro.

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

Dopo questi passaggi è possibile utilizzare git log master per capire di quale commit hai bisogno.
Puoi reimpostare la tua directory di lavoro su questo commit in questo modo:

git reset --hard <the SHA you need>

Se sei soddisfatto del risultato, ad un certo punto dovrai pubblicare la tua versione del repository su un repository remoto. Non dimenticare di specificare esplicitamente il ramo remoto quando lo fai.

git push --force origin master

Si prega di notare che usiamo git push --force. È improbabile che tu voglia farlo molto spesso, ma qui abbiamo uno scenario molto specifico con un utente del repository che, inoltre, capisce cosa sta facendo.

Iniziare a lavorare

Iniziamo a compilare il nostro elenco di passaggi CI. Normalmente inizieresti questo passaggio estraendo l'ultima versione del codice dal repository remoto, ma non disponiamo ancora di un repository locale, quindi lo cloniamo invece da quello remoto.

️ Compito: aggiornare il repository locale, creare un ramo da master, iniziare a lavorare

1. Clona il repository del corso da <URL репозитория>.
2. inizio npm install nella directory del repository del corso; Ne abbiamo bisogno per installare Jest, che utilizziamo per eseguire i test.
3. Crea un ramo e dagli un nome feature. Passa a questo thread.

4. Aggiungi il codice di prova a ci.test.js tra i commenti chiedendomi 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 testo con i primi 4 passaggi al file ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   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 su un nuovo ramo, crea e testa localmente

Imposteremo i test da eseguire prima del commit, quindi committeremo il codice.

Scenari tipici in cui i test vengono eseguiti automaticamente

• Localmente:
  • Continuamente o in risposta a modifiche appropriate del codice;
  • Al salvataggio (per linguaggi interpretati o compilati JIT);
  • Durante l'assemblaggio (quando è richiesta la compilazione);
  • Al momento del commit;
  • Quando si pubblica su un repository condiviso.

• Sul server di compilazione o sull'ambiente di compilazione:
  • Quando il codice viene pubblicato in un ramo/repository personale.
  • Il codice in questo thread è in fase di test.
  • Viene testato il potenziale risultato della fusione (di solito con master).
  • Come fase di integrazione continua/pipeline di distribuzione continua

In genere, più velocemente viene eseguita una suite di test, più spesso puoi permetterti di eseguirla. Una tipica distribuzione per stadi potrebbe assomigliare a questa.

• Test unitari rapidi: durante la creazione, nella pipeline CI
• Unit test lenti, componenti veloci e test di integrazione - su 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 della build, ad esempio durante la preparazione di una release candidate o durante l'esecuzione manuale.

️Compito

Suggerisco di eseguire prima i test manualmente utilizzando il comando npm test. Successivamente, aggiungiamo un hook git per eseguire i nostri test su commit. C'è un problema: gli hook Git non sono considerati parte del repository e quindi non possono essere clonati da GitHub insieme al resto dei materiali del corso. Per installare l'hook è necessario eseguire install_hook.sh oppure copiare il file repo/hooks/pre-commit alla directory locale .git/hooks/.
Quando ti impegni, vedrai che i test vengono eseguiti e controllano se determinate parole chiave sono presenti nell'elenco.

1. Esegui i test manualmente eseguendo il comando npm test nella cartella del repository del corso. Verificare che i test siano stati completati.
2. Imposta un hook di commit (hook pre-commit) eseguendo install_hook.sh.
3. Applica le modifiche al repository locale.
4. Assicurati che i test vengano eseguiti prima di impegnarti.

Il tuo repository dovrebbe assomigliare a questo dopo aver seguito questi passaggi.

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 in un repository remoto o in un ramo remoto

Una volta terminato il lavoro a livello locale, gli sviluppatori in genere rendono il loro codice pubblicamente disponibile in modo che possa eventualmente essere integrato con il pubblico. Con GitHub, ciò si ottiene generalmente pubblicando il lavoro su una copia personale del repository (fork personale) o su un ramo personale.

• Con i fork, uno sviluppatore clona un repository remoto condiviso, creandone una copia remota personale, nota anche come fork. Quindi clona questo repository personale per lavorare localmente. Quando il lavoro è completo e i commit vengono effettuati, li inserisce nel suo fork, dove sono disponibili agli altri e possono essere integrati nel repository comune. Questo approccio è comunemente utilizzato nei progetti open source su GitHub. Viene utilizzato anche nel mio corso avanzato [Team Work e CI con Git] (http://devops.redpill.solutions/).
• Un altro approccio consiste nell'utilizzare un solo repository remoto e contare solo il ramo master repository condiviso "protetto". In questo scenario, i singoli sviluppatori pubblicano il proprio codice nei rami di un repository remoto in modo che altri possano guardare questo codice, se tutto è in ordine, unirlo con master archivio condiviso.

In questo corso particolare, utilizzeremo un flusso di lavoro che utilizza i rami.

Pubblichiamo il nostro codice.

️Compito

• Pubblica le modifiche su un ramo remoto con lo stesso nome del tuo ramo funzionante

comandi

git push --set-upstream origin feature

Crea una richiesta pull

Crea una richiesta pull con un titolo Revisione dei passaggi... Installare feature come "ramo capo" e master come "ramo base".

Assicurati di averlo installato master prima eseguire il fork del repository In quanto "ramo base", non risponderò alle richieste di modifiche al repository dei materiali del corso.

Nel gergo di GitHub, il "ramo base" è il ramo su cui basi il tuo lavoro, e il "ramo head" è il ramo contenente le modifiche proposte.

Discuti le modifiche, aggiungi nuovi commit mentre la discussione continua

Richiesta di estrazione (PR)

Richiesta di estrazione (PR) è un modo per discutere e documentare il codice, nonché per condurre la revisione del codice. Le richieste pull prendono il nome dal modo generale di integrare le singole modifiche nel codice complessivo. In genere, una persona clona il repository ufficiale remoto del progetto e lavora sul codice localmente. Successivamente, inserisce il codice nel suo repository remoto personale e chiede ai responsabili del repository ufficiale di ritirarlo(tirare) il suo codice nei loro repository locali, dove rivedono ed eventualmente integrano(unire) il suo. Questo concetto è conosciuto anche con altri nomi, ad esempio richiesta di unione.

In realtà non è necessario utilizzare la funzionalità di richiesta pull di GitHub o piattaforme simili. I team di sviluppo possono utilizzare altri metodi di comunicazione, tra cui la comunicazione faccia a faccia, le chiamate vocali o la posta elettronica, ma esistono ancora numerosi motivi per utilizzare richieste pull in stile forum. Ecco qui alcuni di loro:

• discussioni organizzate relative a modifiche specifiche del codice;
• come luogo in cui visualizzare il feedback sul lavoro in corso sia da parte degli autotester che dei colleghi;
• formalizzazione delle revisioni del codice;
• in modo che in seguito tu possa scoprire le ragioni e le considerazioni dietro questo o quel pezzo di codice.

In genere si crea una richiesta pull quando è necessario discutere qualcosa o ottenere feedback. Ad esempio, se stai lavorando su una funzionalità che potrebbe essere implementata in più di un modo, puoi creare una richiesta pull prima di scrivere la prima riga di codice per condividere le tue idee e discutere i tuoi piani con i tuoi collaboratori. Se il lavoro è più semplice, viene aperta una richiesta pull quando qualcosa è già stato fatto, impegnato e può essere discusso. In alcuni scenari, potresti voler aprire un PR solo per motivi di controllo qualità: per eseguire test automatizzati o avviare revisioni del codice. Qualunque cosa tu decida, non dimenticare di @menzionare le persone di cui desideri l'approvazione nella tua richiesta di pull.

In genere, quando crei un PR, procedi come segue.

• Indica cosa proponi di cambiare e dove.
• Scrivi una descrizione che spieghi lo scopo delle modifiche. Potresti volere:
  • aggiungi qualcosa di importante che non sia ovvio dal codice, o qualcosa di utile per comprendere il contesto, come #bug rilevanti e numeri di commit;
  • @menzionare chiunque con cui vuoi iniziare a lavorare, oppure puoi @menzionarlo nei commenti in seguito;
  • chiedi ai colleghi di aiutarti con qualcosa o di controllare qualcosa di specifico.

Una volta aperto il PR, vengono eseguiti i test configurati per l'esecuzione in questi casi. Nel nostro caso, si tratterà dello stesso insieme di test che abbiamo eseguito localmente, ma in un progetto reale potrebbero esserci test e controlli aggiuntivi.

Si prega di attendere il completamento dei test. Puoi vedere lo stato dei test in fondo alla discussione PR nell'interfaccia GitHub. Continuare una volta completati i test.

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

L'elenco utilizzato in questo corso è arbitrario e soggettivo, dovremmo aggiungere una nota al riguardo.

️ Compito: creare una richiesta pull per questo commento

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

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. Impegna le modifiche.
5. Pubblica il thread bugfix ad un archivio remoto.
6. Crea una richiesta pull denominata Aggiunta di un'osservazione con un ramo di testa bugfix e il ramo basemaster.

Assicurati di averlo installato master prima eseguire il fork del repository In quanto "ramo base", non risponderò alle richieste di modifiche al repository dei materiali del corso.

Questo è 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 richiesta pull "Aggiunta di un'osservazione"

️Compito

1. Crea una richiesta pull.
2. Fare clic su "Unisci richiesta pull".
3. Fare clic su "Conferma unione".
4. Fai clic su "Elimina ramo", non ne abbiamo più bisogno.

Questo è un diagramma dei commit dopo una fusione.

️ Continua a lavorare e ad aggiungere test

La collaborazione su una richiesta pull spesso comporta lavoro aggiuntivo. Questo di solito è il risultato di una revisione o discussione del codice, ma nel nostro corso lo modelleremo aggiungendo nuovi elementi al nostro elenco di passaggi CI.

L'integrazione continua in genere comporta una copertura di test. I requisiti di copertura del test variano e di solito si trovano in un documento chiamato qualcosa come "linee guida per i contributi". Lo manterremo semplice e aggiungeremo un test per ogni riga nella nostra lista di controllo.

Quando esegui i compiti, prova prima a eseguire i test. Se hai installato correttamente pre-commit hook in precedenza, il test appena aggiunto verrà eseguito, fallirà e non verrà eseguito il commit di nulla. Tieni presente che questo è il modo in cui sappiamo che i nostri test stanno effettivamente testando qualcosa. È interessante notare che, se iniziassimo con il codice prima dei test, il superamento dei test potrebbe significare che il codice ha funzionato come previsto o che i test in realtà non stavano testando nulla. Inoltre, se non avessimo scritto i test in primo luogo, forse ce li saremmo dimenticati del tutto, poiché nulla ce lo avrebbe ricordato.

Sviluppo guidato dai test (TDD)

TDD consiglia di scrivere i test prima del codice. Un tipico flusso di lavoro che utilizza TDD è simile al seguente.

1. Aggiungi una prova.
2. Esegui tutti i test e assicurati che il nuovo test fallisca.
3. Scrivi il codice.
4. Esegui i test, assicurati che tutti i test vengano superati.
5. Rifattorizza il tuo codice.
6. Ripetere.

Poiché i risultati dei test falliti sono solitamente mostrati in rosso, mentre quelli superati sono solitamente mostrati in verde, il ciclo è noto anche come refactoring rosso-verde.

️Compito

Innanzitutto, prova a eseguire il commit dei test e a lasciarli fallire, quindi aggiungi e conferma il testo dell'elenco dei passaggi CI stesso. Vedrai che i test stanno superando ("verde").
Quindi pubblica il nuovo codice nel repository remoto e guarda i test eseguiti nell'interfaccia GitHub in fondo alla discussione sulla richiesta pull e all'aggiornamento dello stato PR.

1. Passa alla filiale feature.

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

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. Prova a fare i test. Se pre-commit hook è installato, il tentativo di commit fallirà.
4. Quindi aggiungi questo testo a ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. Apporta e conferma le modifiche localmente.
6. Pubblica modifiche al ramo feature.

Ora dovresti avere qualcosa di simile

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

Unisci conflitto

Vai a Richiesta di modifica Revisione dei passaggi.

Anche se non abbiamo fatto nulla di sbagliato e i test per il nostro codice sono stati superati, non possiamo ancora unire il ramo feature и master. È perché l'altro thread bugfix è stato fuso con master mentre stavamo lavorando a questo PR.
Ciò crea una situazione in cui il ramo remoto master ha una versione più recente di quella su cui abbiamo basato il ramo feature. Per questo motivo non possiamo semplicemente riavvolgere HEAD master fino alla fine del filo feature. In questa situazione, dobbiamo unire o applicare i commit feature ribasare master. GitHub può effettivamente eseguire unioni automatiche se non ci sono conflitti. Purtroppo, nella nostra situazione, entrambi i rami hanno modifiche concorrenti nel file ci.md. Questa situazione è nota come conflitto di unione e dobbiamo risolverla manualmente.

Unisci o riorganizza

Unire

• Crea un ulteriore commit di unione e salva la cronologia lavorativa.
  • Conserva i commit originali dei rami con i loro timestamp e autori originali.
  • Salva lo SHA dei commit e si collega ad essi nelle discussioni sulle richieste di modifica.
• Richiede la risoluzione del conflitto una tantum.
• Rende la storia non lineare.
  • La storia può essere difficile da leggere a causa del gran numero di diramazioni (che ricorda un cavo IDE).
  • Rende più difficile il debug automatico, ad es. git bisect meno utile: troverà solo il commit di unione.

rebase

• Riproduce i commit dal ramo corrente sopra il ramo base uno dopo l'altro.
  • Vengono generati nuovi commit con nuovi SHA, facendo sì che i commit in GitHub corrispondano alle richieste pull originali, ma non ai commenti corrispondenti.
  • I commit possono essere ricombinati e modificati nel processo o addirittura fusi in uno solo.
• Potrebbe essere necessario risolvere più conflitti.
• Ti consente di mantenere una storia lineare.
  • La storia può essere più facile da leggere purché non sia troppo lunga senza una ragione ragionevole.
  • Il debug automatico e la risoluzione dei problemi sono un po' più semplici: lo rendono possibile git bisect, può rendere i rollback automatici più chiari e prevedibili.
• Richiede la pubblicazione di un ramo con commit migrati con un flag --force se utilizzato con richieste pull.

In genere, i team concordano di utilizzare sempre la stessa strategia quando devono unire le modifiche. Potrebbe trattarsi di un'unione "pura" o di un commit "puro" in alto, o qualcosa di intermedio, come eseguire un commit in alto in modo interattivo(git rebase -i) localmente per i rami non pubblicati nell'archivio pubblico, ma unificati per i rami "pubblici".

Qui useremo l'unione.

️Compito

1. Assicurati che il codice sia in una filiale locale master aggiornato da un repository remoto.
2. Passa alla filiale feature.
3. Avviare un'unione con il ramo master. Un conflitto di unione dovuto a modifiche concorrenti al file ci.md.
4. Risolvi il conflitto in modo che sia il nostro elenco di passaggi CI che una nota al riguardo rimangano nel testo.
5. Pubblica un commit di unione su un ramo remoto feature.
6. Controlla lo stato della richiesta pull nell'interfaccia utente di GitHub e attendi finché l'unione non viene 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 finito con l'elenco e ora devi approvare la richiesta di pull master.

️ Compito: approvare la richiesta pull "Revisione passaggi"

1. Apri una richiesta pull.
2. Fare clic su "Unisci richiesta pull".
3. Fare clic su "Conferma unione".
4. Fai clic su "Elimina ramo" poiché non ne abbiamo più bisogno.

Questo è il tuo repository al momento

Errore del prodotto

Si dice che “i test possono essere utilizzati per mostrare la presenza di errori, ma mai per mostrare la loro assenza”. Anche se abbiamo effettuato dei test e non ci hanno mostrato errori, un bug insidioso si è insinuato nella produzione.

In uno scenario come questo, dobbiamo occuparci di:

• cosa viene distribuito in produzione;
• codice nel thread master con un errore, da cui gli sviluppatori possono iniziare un nuovo lavoro.

Dovrei eseguire il rollback o risolverlo nella prossima versione?

Il rollback è il processo di distribuzione di una versione precedente nota come valida in produzione e di ripristino dei commit che contengono l'errore. "Fixing forward" è l'aggiunta di una correzione al file master e distribuire la nuova versione il prima possibile. Poiché le API e gli schemi dei database cambiano man mano che il codice viene distribuito in produzione, con distribuzione continua e buona copertura dei test, il rollback è in genere molto più difficile e rischioso che risolverlo nella versione successiva.

Poiché il rollback non comporta alcun rischio nel nostro caso, seguiremo questa strada perché ce lo consente

• correggere l'errore sul prodotto il prima possibile;
• inserire il codice master subito idoneo per iniziare un nuovo lavoro.

️Compito

1. Passa alla filiale master localmente.
2. Aggiorna il repository locale dal repository remoto.
3. Ripristina il commit dell'unione PR Revisione dei passaggi в master.
4. Pubblica le modifiche su un repository remoto.

Questa è la cronologia di un repository con un 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

️ Autotest

едитесь, то ci.md non contiene più il testo "bug subdolo" dopo aver ripristinato un commit di unione.

Correggi l'elenco dei passaggi CI e restituiscilo al master

Abbiamo completamente ripristinato il commit di fusione del ramo. feature. La buona notizia è che ora non ci sono errori master. La cattiva notizia è che anche il nostro prezioso elenco di passaggi di integrazione continua è sparito. Quindi, idealmente, dobbiamo applicare la correzione ai commit from feature e restituirli a master insieme alla correzione.

Possiamo affrontare il problema in diversi modi:

• ripristinare un commit che annulla un'unione feature с master;
• spostare i commit dal primo feature.

Diversi team di sviluppo utilizzano approcci diversi in questo caso, ma sposteremo i commit utili in un ramo separato e creeremo una richiesta pull separata per questo nuovo ramo.

️Compito

1. Crea un thread chiamato feature-fix e passare ad esso.

2. Migrare tutti i commit dal ramo precedente feature a un nuovo thread. Risolvere i conflitti di unione che si sono verificati durante la migrazione.

   

3. Aggiungi un test di regressione a 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 falliscano.
5. Rimuovere il testo "con un bug subdolo" in ci.md.
6. Aggiungi modifiche di test e modifiche all'elenco dei passaggi all'indice e confermale.
7. Pubblica il ramo in un repository remoto.

Dovresti ritrovarti con qualcosa di simile a questo:

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 richiesta pull.

Crea una richiesta pull con un titolo Correzione della funzionalità... Installare feature-fix come "ramo capo" e master come "ramo base".
Si prega di attendere il completamento dei test. Puoi vedere lo stato dei test in fondo alla discussione PR.

Assicurati di averlo installato master prima eseguire il fork del repository In quanto "ramo base", non risponderò alle richieste di modifiche al repository dei materiali del corso.

Approva richiesta pull "Correzione della funzionalità"

Grazie per la correzione! Si prega di approvare le modifiche a master dalla richiesta pull.

️Compito

1. Fare clic su "Unisci richiesta pull".
2. Fare clic su "Conferma unione".
3. Fai clic su "Elimina ramo" poiché non ne abbiamo più bisogno.

Questo è quello che dovresti avere in questo momento.

Congratulazioni!

Hai completato tutti i passaggi normalmente eseguiti dalle persone durante l'integrazione continua.

Se noti problemi con il corso o sai come migliorarlo, crea un problema in repository con i materiali del corso. Anche questo corso ha versione interattiva utilizzando GitHub Learning Lab come piattaforma.

Fonte: habr.com