Preview ng leksyon

Conflitti di unione: niente panico — analizziamo e risolviamo

I conflitti spaventano i principianti, ma dopo questa sezione li affronterete con calma. Analizzeremo perché si verificano i conflitti (Git non legge nel pensiero — non sa quale modifica è più importante), come interpretare i marcatori di conflitto e come scegliere la soluzione giusta. Mostreremo due approcci: la risoluzione manuale e l'uso di strumenti di merge.

conflitto di unione marcatori di conflitto risoluzione del conflitto
Ano ang matututunan mo sa leksyong ito
  • Comprenderete la natura dei conflitti di unione e smetterete di temerli — diventeranno prevedibili.
  • Sarete in grado di risolvere autonomamente un conflitto manualmente, leggendo correttamente i marcatori di Git.
  • Imparerete a configurare uno strumento di merge nel vostro editor per la risoluzione visiva dei conflitti.

Simula ng leksyon

Tre tipi di conflitti di unione

  • Di contenuto: modifiche sulle stesse righe
  • Di rinomina: file modificato e rinominato
  • Di cancellazione: file eliminato in un ramo, modificato in un altro
  • Le rinomine sono le più insidiose per Git
  • Controllate la cronologia del file in caso di conflitti sospetti

Immaginate di lavorare a un progetto importante e all'improvviso Git segnala un conflitto. Il primo passo per risolverlo è capirne il tipo. I conflitti di contenuto si verificano quando le modifiche interessano le stesse righe in rami diversi. Con le rinomine è più complesso: uno sviluppatore cambia il nome del file, mentre un altro ne modifica il contenuto contemporaneamente. Il terzo tipo sono le cancellazioni, quando un file scompare in un ramo ma continua a esistere in un altro. Sono proprio le rinomine a causare più spesso difficoltà, perché Git non sempre traccia correttamente la cronologia del file dopo un cambio di nome. Per questo motivo, in caso di conflitti sospetti, controllate sempre la cronologia delle modifiche dei file.

Anatomia di un conflitto complesso

  • I marcatori <<<<<<< mostrano le vostre modifiche
  • ======= separa la vostra versione da quella altrui
  • >>>>>>> segna la fine del blocco in conflitto
  • git status mostrerà tutti i file problematici
  • git diff — confronto dettagliato delle modifiche

Supponiamo che stiate unendo il ramo feature in main e vediate un messaggio di conflitto. Aprite i file problematici: noterete dei marcatori speciali. Tutto ciò che si trova tra <<<<<<< HEAD e ======= sono le vostre modifiche. Tra ======= e >>>>>>> feature ci sono le modifiche del ramo che state unendo. Usate git status per vedere tutti i file in conflitto e git diff per un confronto dettagliato. Ricordate: i marcatori non sono un errore, ma un suggerimento su dove dovete prendere una decisione.

#!/bin/bash
# conflict_analysis.sh

echo "Creiamo un repository di test"
mkdir conflict-demo && cd conflict-demo
git init

echo "Creiamo un file e il primo commit in main"
echo 'Linea 1' > file.txt
echo 'Linea 2' >> file.txt
git add . && git commit -m 'Commit iniziale'

echo "Creiamo il ramo feature e modifichiamo la prima riga"
git checkout -b feature
sed -i 's/Linea 1/Linea 1 modificata in feature/' file.txt
git commit -am 'Modifica linea 1 in feature'

echo "Torniamo in main e modifichiamo la stessa riga"
git checkout main
sed -i 's/Linea 1/Linea 1 modificata in main/' file.txt
git commit -am 'Modifica linea 1 in main'

echo "Proviamo a unire i rami"
git merge feature || echo 'Conflitto!'

echo "\nVisualizziamo lo stato:"
git status --short

echo "\nMostriamo il file in conflitto:"
cat file.txt

Strategie di risoluzione dei conflitti

  • Modifica manuale: rimuovere i marcatori, mantenere il necessario
  • Strumenti GUI: meld, kdiff3 per il confronto visivo
  • --ours/--theirs: accettare la propria o la versione altrui
  • Con rebase i conflitti si risolvono per ogni commit
  • Dopo la risoluzione — non dimenticare git add e git commit

Quando viene rilevato un conflitto, avete diverse strade. Potete aprire il file manualmente e modificarlo, rimuovendo i marcatori e lasciando il codice desiderato. Per i visivi sono adatti strumenti come meld o kdiff3 — mostrano tre versioni del file contemporaneamente. Se siete sicuri delle vostre modifiche, usate git checkout --ours per mantenere la vostra versione, o --theirs per quella altrui. Bisogna essere particolarmente attenti con rebase: qui i conflitti possono verificarsi su ogni commit che viene riorganizzato.

#!/bin/bash
# resolve_strategies.sh

echo "Metodo 1: Risoluzione manuale"
echo 'Modificate il file, rimuovendo i marcatori di conflitto'
echo 'Quindi eseguite: git add file.txt'

echo "\nMetodo 2: Accettare la nostra versione"
git checkout --ours file.txt

echo "\nMetodo 3: Accettare la loro versione"
git checkout --theirs file.txt

echo "\nMetodo 4: Usare uno strumento di unione"
echo 'git mergetool --tool=meld'

echo "\nDopo aver scelto il metodo, completate l'unione:"
echo 'git commit -m "Risolto conflitto di unione"'

Buong leksyon ay para sa subscription

34 pang slide sa buong bersyon.

Mabubuksan ang video, lahat ng slide, tala, pagsusulit, AI tutor, at interview pagkatapos mag-sign in at mag-subscribe.

Mag-sign in o magparehistro Mag-subscribe

Nilalaman ng leksyon

  1. Tre tipi di conflitti di unione
  2. Anatomia di un conflitto complesso
  3. Strategie di risoluzione dei conflitti
  4. Prevenzione e buone pratiche
  5. Come leggere i conflitti multilinea in Git
  6. Decodifica dei marcatori contestuali
  7. Conflitti annidati: strategie di risoluzione
  8. Automazione e strumenti avanzati
  9. Strategia di scelta: HEAD o ramo?
  10. Principio del 'minimo stupore'
  11. Conflitti semantici: nemici invisibili
  12. Strumenti e automazione
  13. Scelta dello strumento: quando usare cosa
  14. VS Code: configurazione e funzionalità avanzate
  15. Beyond Compare: scenari per conflitti complessi
  16. Integrazione in Git flow e automazione
  17. Automatizziamo il merge tramite .gitattributes
  18. Scriviamo il nostro merge driver
  19. Git rerere — il vostro assistente personale
  20. Strategie avanzate di automazione
  21. Progettiamo un workflow per grandi team
  22. Code Review come strumento per prevenire i conflitti
  23. Strategie per lavorare con branch feature longevi
  24. Strumenti e automazione per la risoluzione dei conflitti
  25. Pericoli dell'accettazione cieca delle modifiche
  26. Strategie per una risoluzione sicura dei conflitti
  27. Test dopo il merge: cosa verificare
  28. Integrazione con CI/CD e misure preventive
  29. In cosa differiscono i conflitti in rebase da quelli in merge
  30. Lavorare con --rebase-merges
  31. Strategie per la risoluzione di conflitti sequenziali
  32. Tecniche avanzate e debug del rebase
  33. CI/CD come sistema di controllo qualità
  34. GitHub Actions: controllo dei conflitti
  35. Danger-JS: automazione intelligente dei controlli
  36. Risoluzione automatica dei conflitti in CI/CD
  37. Conflitti: dal panico alla sicurezza

Mga artikulo tungkol sa araling ito

Lahat ng leksyon ng kurso

  1. Introduzione: Git da zero a sviluppatore fiducioso
  2. Perché serve Git — e perché senza non ti assumono
  3. Installazione e configurazione: prepariamo Git al primo avvio
  4. Primo repository: init, add, commit e la magia dell'indice
  5. Leggiamo la storia: log, diff, show e navigazione nel passato
  6. Branch: la realtà parallela del tuo codice
  7. Annullare gli errori: restore, reset, revert — correttamente e con cautela
  8. GitHub e repository remoti: il tuo codice nel cloud
  9. Lavoro di squadra: fork, feature branch e pull request
  10. Conflitti di unione: niente panico — analizziamo e risolviamo
  11. Processi Git nei team reali: quale workflow scegliere
  12. Strumenti avanzati: rebase, stash, cherry-pick e tag
  13. Progetto finale: simuliamo uno sviluppo di gruppo reale