{"id":991,"date":"2021-07-31T13:33:00","date_gmt":"2021-07-31T11:33:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/git-workflow-team-guida-2021\/"},"modified":"2021-07-31T13:33:00","modified_gmt":"2021-07-31T11:33:00","slug":"git-workflow-team-guida-2021","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/git-workflow-team-guida-2021\/","title":{"rendered":"Git workflow per team: la guida 2021"},"content":{"rendered":"<p>Definire un <strong>git workflow team<\/strong> chiaro e condiviso non e&#8217; un dettaglio tecnico per puristi: e&#8217; la differenza fra un team di sviluppo che rilascia in modo prevedibile e uno che vive in costante stato di emergenza. Branch in conflitto, merge che cancellano lavoro altrui, deploy bloccati da feature non testate, code review fatte all&#8217;ultimo: nel 2021 questi sono ancora i sintomi piu&#8217; frequenti di team senza convenzioni Git solide.<\/p>\n<p>In questa guida analizziamo i quattro modelli di branching piu&#8217; diffusi (GitFlow, GitHub Flow, GitLab Flow, Trunk-based development), le best practice di pull\/merge request review, le convenzioni per branch naming, commit message e tag, e gli errori frequenti da evitare. L&#8217;obiettivo e&#8217; fornire a developer senior, tech lead e CTO di PMI italiane un framework operativo per scegliere il workflow piu&#8217; adatto al proprio contesto e implementarlo senza attriti.<\/p>\n<h2>Git workflow: perche&#8217; averne uno strutturato<\/h2>\n<p>Git, dalla sua creazione nel 2005 ad opera di Linus Torvalds, e&#8217; diventato lo standard de-facto per il version control. Wikipedia stima che oltre il 90% dei progetti software open source moderni lo utilizzi (<a href=\"https:\/\/it.wikipedia.org\/wiki\/Git\" target=\"_blank\" rel=\"noopener\">fonte<\/a>). Ma Git e&#8217; uno strumento, non una metodologia: senza convenzioni condivise, ogni developer crea branch a piacere, fa merge in modo arbitrario e i risultati sono caotici.<\/p>\n<p>Un git workflow strutturato risponde a domande operative concrete:<\/p>\n<ul>\n<li><strong>Dove sviluppo una nuova feature?<\/strong> Su quale branch parto?<\/li>\n<li><strong>Come integro il mio lavoro?<\/strong> Merge, rebase, squash?<\/li>\n<li><strong>Chi approva il codice?<\/strong> Quante review servono?<\/li>\n<li><strong>Come gestisco hotfix in produzione<\/strong> mentre altri sviluppano feature future?<\/li>\n<li><strong>Come marco le release?<\/strong> Tag semantici o data-based?<\/li>\n<\/ul>\n<p>Un team senza risposte standardizzate a queste domande paga un costo nascosto enorme: tempo perso a riconciliare conflitti, bug che sfuggono perche&#8217; la review e&#8217; debole, deploy che falliscono perche&#8217; una feature meta&#8217;-pronta finisce in main per errore. Per le PMI che sviluppano <a href=\"https:\/\/brentasoft.com\/soluzioni\/gestionali-personalizzati.php\">gestionali personalizzati<\/a> o <a href=\"https:\/\/brentasoft.com\/soluzioni\/web-app-pwa.php\">web app e PWA<\/a>, scegliere il workflow giusto e&#8217; propedeutico a qualunque iniziativa di <a href=\"\/blog\/devops-ci-cd-pmi-guida-2021\/\">DevOps e CI\/CD<\/a>.<\/p>\n<h2>GitFlow: il classico Vincent Driessen 2010<\/h2>\n<p>GitFlow e&#8217; stato proposto da Vincent Driessen nel 2010 in un post che e&#8217; diventato leggendario (<a href=\"https:\/\/nvie.com\/posts\/a-successful-git-branching-model\/\" target=\"_blank\" rel=\"noopener\">A successful Git branching model<\/a>). Per oltre cinque anni e&#8217; stato il default per qualsiasi team strutturato. Si basa su due branch principali a vita lunga e tre tipi di branch di supporto:<\/p>\n<ul>\n<li><code>main<\/code> (o <code>master<\/code>): contiene SOLO codice in produzione, ogni commit e&#8217; una release<\/li>\n<li><code>develop<\/code>: integration branch, contiene il codice della prossima release<\/li>\n<li><code>feature\/*<\/code>: branch temporanei per nuove feature, partono da develop e ci tornano<\/li>\n<li><code>release\/*<\/code>: branch di stabilizzazione pre-rilascio (bugfix, version bump)<\/li>\n<li><code>hotfix\/*<\/code>: fix urgenti partono da main, vanno sia in main che in develop<\/li>\n<\/ul>\n<p>Esempio di flusso completo per una feature:<\/p>\n<pre><code>git checkout develop\ngit pull\ngit checkout -b feature\/login-2fa\n# ... lavoro, commit ...\ngit push -u origin feature\/login-2fa\n# apri Pull Request verso develop\n# review, merge\ngit checkout develop\ngit pull\ngit branch -d feature\/login-2fa<\/code><\/pre>\n<p>Quando arriva il momento del rilascio, da develop si crea un branch <code>release\/v2.4.0<\/code> dove si fanno solo bugfix e bump di versione. Quando il release branch e&#8217; stabile, si fa merge in main (con tag) e in develop (per riportare i fix). Hotfix urgenti partono da main, si mergeano in main (con nuovo tag patch) e in develop.<\/p>\n<p><strong>Pro<\/strong>: separazione netta fra sviluppo e produzione, gestione robusta delle release, possibilita&#8217; di mantenere piu&#8217; versioni in parallelo (utile per software con clienti su versioni diverse). Ideale per prodotti con cicli di rilascio definiti (mensili, trimestrali) e per software desktop\/mobile dove il deploy non e&#8217; istantaneo come una web app.<\/p>\n<p><strong>Contro<\/strong>: complessita&#8217; alta, molti merge da gestire, lento per team che vogliono fare deploy continui. Lo stesso Driessen, nel 2020, ha aggiunto una nota al suo post originale precisando che GitFlow e&#8217; adatto a software con release versionate ma non al modello &#8220;deploy continuous&#8221; delle web app moderne. Il tool <code>git-flow<\/code> (estensione che automatizza i comandi) ha smesso di essere mantenuto attivamente, segno che il modello sta perdendo quota.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/07\/team-developers-collaboration.jpg\" alt=\"Team di developer in meeting di branching strategy\" \/><\/p>\n<h2>GitHub Flow: la versione semplificata<\/h2>\n<p>GitHub Flow e&#8217; nato dall&#8217;esperienza interna di GitHub (Scott Chacon, 2011) come reazione alla complessita&#8217; di GitFlow. La logica e&#8217; radicalmente semplice:<\/p>\n<ol>\n<li>Esiste un solo branch principale: <code>main<\/code><\/li>\n<li>Per qualsiasi modifica si crea un branch da main<\/li>\n<li>Si committa e si pusha frequentemente<\/li>\n<li>Quando il lavoro e&#8217; pronto, si apre una Pull Request verso main<\/li>\n<li>Dopo review e CI verde, si fa merge in main<\/li>\n<li>Subito dopo il merge, si fa deploy<\/li>\n<\/ol>\n<p>Niente develop, niente release branch, niente hotfix branch. Main deve essere SEMPRE deployable. Se un bug arriva in produzione, si crea un branch fix da main, si testa, si fa merge e si deploya: e&#8217; lo stesso identico flusso di una feature normale.<\/p>\n<p>Questo modello funziona benissimo per:<\/p>\n<ul>\n<li>Web app con deploy continuo (SaaS, e-commerce, web service)<\/li>\n<li>Team piccoli e medi (3-15 developer)<\/li>\n<li>Prodotti con un solo &#8220;cliente&#8221; (non software venduto on-premise in versioni diverse)<\/li>\n<li>Pipeline CI\/CD mature, dove ogni PR scatena test automatici<\/li>\n<\/ul>\n<p>Non funziona quando bisogna mantenere versioni multiple in parallelo (es. v2.x in produzione presso clienti enterprise mentre si sviluppa v3) o quando i deploy sono manuali e poco frequenti. La regola implicita e&#8217; che ogni merge in main scatena un deploy: se questo non e&#8217; vero nel tuo contesto, GitHub Flow rischia di lasciarti con feature &#8220;mergeate ma non rilasciate&#8221; che si accumulano e perdono leggibilita&#8217;.<\/p>\n<p>Dal punto di vista pratico, GitHub Flow richiede tre prerequisiti tecnici: branch protection su main (almeno 1 approvazione + CI verde), pipeline di CI veloce (sotto i 10 minuti idealmente, mai sopra i 30), e un sistema di rollback rapido in caso di problemi post-deploy. Senza questi tre elementi, &#8220;deploy ad ogni merge&#8221; diventa russian roulette.<\/p>\n<h2>GitLab Flow: il middle ground<\/h2>\n<p>GitLab Flow, formalizzato nel 2014, cerca di mediare fra la semplicita&#8217; di GitHub Flow e le esigenze reali di team che hanno ambienti multipli (staging, pre-prod, prod) o release versionate. Esistono due varianti principali:<\/p>\n<p><strong>Variante &#8220;environment branches&#8221;<\/strong>: oltre a main, ci sono branch che rappresentano ambienti \u2014 tipicamente <code>pre-production<\/code> e <code>production<\/code>. Il codice fluisce in una sola direzione: feature branch -&gt; main -&gt; pre-production -&gt; production. Ogni promozione fra ambienti e&#8217; un merge.<\/p>\n<p><strong>Variante &#8220;release branches&#8221;<\/strong>: simile a GitFlow ma senza develop. Esiste main + branch <code>release\/v2.5<\/code>, <code>release\/v2.6<\/code> ecc. I bugfix vengono cherry-pickati dai release branch verso main e viceversa, ma main resta il branch di sviluppo principale.<\/p>\n<p>GitLab Flow e&#8217; interessante per team che fanno <a href=\"https:\/\/brentasoft.com\/soluzioni\/integrazione-api.php\">integrazione API<\/a> con ambienti separati di test e produzione, e che hanno bisogno di &#8220;trattenere&#8221; il codice in un branch staging prima del go-live.<\/p>\n<h2>Trunk-based development: il moderno<\/h2>\n<p>Trunk-based development (TBD) e&#8217; il modello che sta crescendo piu&#8217; velocemente nel 2021. Lo usano Google, Facebook, Microsoft, Netflix e la maggior parte delle big tech. La filosofia e&#8217; estrema: <strong>tutti i developer committano direttamente sul trunk (main) almeno una volta al giorno<\/strong>.<\/p>\n<p>I branch di feature, se esistono, vivono al massimo 1-2 giorni. Niente branch lunghi, niente integrazioni dolorose, niente &#8220;merge hell&#8221; il venerdi&#8217; sera. Per gestire feature non ancora pronte si usano <strong>feature flag<\/strong>: il codice e&#8217; in main ma e&#8217; disabilitato a runtime tramite una flag che si attiva solo per gli utenti giusti (es. internal testing, beta).<\/p>\n<p>I requisiti per fare TBD seriamente sono pesanti:<\/p>\n<ul>\n<li>Test suite molto solida, con esecuzione su ogni commit (CI mandatorio)<\/li>\n<li>Code review veloce (idealmente sotto le 4 ore)<\/li>\n<li>Cultura aziendale che premia l&#8217;integrazione frequente<\/li>\n<li>Sistema di feature flag (LaunchDarkly, Unleash, o homemade)<\/li>\n<li>Capacita&#8217; di rollback rapido<\/li>\n<\/ul>\n<p>Per PMI italiane che fanno <a href=\"\/blog\/sviluppo-software-custom-pmi-quando-conviene\/\">sviluppo software custom<\/a>, TBD puo&#8217; sembrare estremo, ma una versione &#8220;soft&#8221; (branch da 1-2 giorni max + main protected + CI obbligatoria) e&#8217; un ottimo compromesso fra disciplina e leggerezza. Il libro &#8220;Accelerate&#8221; di Forsgren, Humble e Kim (2018) cita TBD fra le pratiche correlate ai team con metriche DORA migliori (deployment frequency, lead time, MTTR, change failure rate).<\/p>\n<p>Un esempio concreto: invece di tenere aperto per due settimane un branch <code>feature\/nuovo-modulo-fatture<\/code>, lo splitti in 5-6 PR sequenziali piccole. La prima introduce lo schema DB (dietro feature flag), la seconda il modello, la terza il controller, la quarta la UI, la quinta i test end-to-end, la sesta abilita la flag in staging. Ogni PR e&#8217; mergeata in main entro 1-2 giorni, ma la feature non e&#8217; visibile agli utenti fino all&#8217;ultima PR. Il rischio di merge conflict crolla, la review e&#8217; piu&#8217; efficace, l&#8217;integrazione fra colleghi e&#8217; continua.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/07\/git-branching-codice.jpg\" alt=\"Schermata di codice con sintassi git branching\" \/><\/p>\n<h2>Pull\/Merge request review: best practice<\/h2>\n<p>Indipendentemente dal workflow scelto, la <strong>review delle Pull Request (GitHub) o Merge Request (GitLab)<\/strong> e&#8217; il punto in cui il workflow vive o muore. Una review fatta bene migliora la qualita&#8217; del codice, diffonde conoscenza, scopre bug. Una review fatta male e&#8217; un rubber-stamping che da&#8217; falsa sicurezza.<\/p>\n<p><strong>Regole minime per una review che funziona<\/strong>:<\/p>\n<ul>\n<li><strong>Branch protetto<\/strong>: main (e develop, se esiste) richiedono almeno 1 approvazione e CI verde prima del merge<\/li>\n<li><strong>PR piccole<\/strong>: idealmente sotto le 400 righe modificate. Sopra le 800 la review diventa superficiale<\/li>\n<li><strong>Descrizione obbligatoria<\/strong>: ogni PR deve spiegare cosa fa, perche&#8217;, e come testarla<\/li>\n<li><strong>Self-review prima<\/strong>: il developer rilegge il proprio diff prima di richiedere review esterna<\/li>\n<li><strong>Review entro 24h<\/strong>: per non bloccare i colleghi. Se non si riesce, va comunicato<\/li>\n<li><strong>Tono costruttivo<\/strong>: si fanno domande (&#8220;perche&#8217; qui usi map invece di forEach?&#8221;) non accuse<\/li>\n<li><strong>Almeno un reviewer senior<\/strong> sui PR critici (auth, pagamenti, dati sensibili)<\/li>\n<\/ul>\n<p>Strumenti come GitHub Code Review, GitLab MR, Bitbucket Pipelines, Azure Repos PR sono tutti ottimi nel 2021. La differenza la fa la cultura del team, non lo strumento.<\/p>\n<p>Un anti-pattern frequente e&#8217; la &#8220;review-blocco&#8221;: un solo senior approva tutte le PR e diventa il collo di bottiglia. Soluzione: distribuire la review fra peer (anche junior con junior, sotto supervisione), usare CODEOWNERS per delegare automaticamente le aree di competenza, e introdurre rotazione settimanale del &#8220;PR shepherd&#8221; che monitora le PR ferme da troppo tempo. Le metriche da tenere sotto controllo sono: <em>time to first review<\/em> (mediana sotto le 4 ore lavorative), <em>time to merge<\/em> (mediana sotto la giornata), e <em>review depth<\/em> (numero di commenti sostanziali per PR \u2014 troppo basso indica rubber-stamping, troppo alto indica PR troppo grandi).<\/p>\n<h2>Branch naming convention<\/h2>\n<p>Convenzioni di naming chiare evitano la proliferazione di branch inintelligibili tipo <code>fix-bug<\/code> o <code>marco-test<\/code>. Una convention diffusa e&#8217; la seguente:<\/p>\n<pre><code>feature\/JIRA-123-login-2fa\nbugfix\/JIRA-456-fix-cart-totals\nhotfix\/JIRA-789-prod-payment-error\nrelease\/v2.3.0\nchore\/upgrade-node-16<\/code><\/pre>\n<p>Pattern: <code>{tipo}\/{ticket-id}-{slug-descrittivo}<\/code>. Tipi tipici: <code>feature<\/code>, <code>bugfix<\/code>, <code>hotfix<\/code>, <code>release<\/code>, <code>chore<\/code> (manutenzione), <code>docs<\/code>, <code>refactor<\/code>, <code>test<\/code>.<\/p>\n<p>Vantaggi:<\/p>\n<ul>\n<li>Linkabilita&#8217; al ticket Jira\/Linear\/Trello<\/li>\n<li>Ordinabilita&#8217; nei tool (i branch <code>feature\/*<\/code> stanno tutti insieme)<\/li>\n<li>Self-documenting: leggendo il nome capisci cosa fa il branch<\/li>\n<li>Facilita&#8217; di automazioni (pre-commit hook, CI conditional steps)<\/li>\n<\/ul>\n<h2>Commit message convention (Conventional Commits)<\/h2>\n<p>Conventional Commits (specifica 1.0.0 del 2018) e&#8217; uno standard per i messaggi di commit. Pattern base:<\/p>\n<pre><code>&lt;tipo&gt;(&lt;scope&gt;): &lt;descrizione breve&gt;\n\n&lt;corpo opzionale, multilinea&gt;\n\n&lt;footer opzionale, breaking changes, ticket&gt;<\/code><\/pre>\n<p>Esempi reali:<\/p>\n<pre><code>feat(auth): aggiunto supporto 2FA via TOTP\n\nImplementa Time-based OTP secondo RFC 6238.\nCompatibile con Google Authenticator e Authy.\n\nCloses JIRA-123\n\n---\n\nfix(cart): corretto calcolo IVA su sconti percentuali\n\nL'IVA veniva applicata al prezzo intero invece che\nal prezzo scontato. Risolve discrepanze in fattura.\n\n---\n\nchore(deps): bump axios da 0.21.1 a 0.21.4\n\nCVE-2021-3749 \u2014 vulnerabilita' ReDoS<\/code><\/pre>\n<p>Tipi standard: <code>feat<\/code>, <code>fix<\/code>, <code>docs<\/code>, <code>style<\/code>, <code>refactor<\/code>, <code>test<\/code>, <code>chore<\/code>, <code>perf<\/code>, <code>ci<\/code>, <code>build<\/code>.<\/p>\n<p>I vantaggi non sono solo estetici. Conventional Commits abilita la <strong>generazione automatica del CHANGELOG<\/strong> (con tool come standard-version o semantic-release) e il <strong>versionamento semantico automatico<\/strong>: ogni <code>feat<\/code> incrementa la minor, ogni <code>fix<\/code> la patch, ogni <code>BREAKING CHANGE<\/code> la major.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/07\/code-review-developer.jpg\" alt=\"Code review da laptop in ufficio\" \/><\/p>\n<h2>Tagging e release management<\/h2>\n<p>I tag Git marcano in modo permanente uno specifico commit come &#8220;release&#8221;. Si usano principalmente tag annotati (<code>git tag -a v1.2.3 -m \"Release 1.2.3\"<\/code>) perche&#8217; contengono autore, data e messaggio (i lightweight tag sono solo puntatori).<\/p>\n<p>La convenzione dominante e&#8217; <strong>SemVer (Semantic Versioning 2.0.0)<\/strong>: <code>MAJOR.MINOR.PATCH<\/code>.<\/p>\n<ul>\n<li><strong>MAJOR<\/strong>: breaking change, l&#8217;API cambia in modo non retrocompatibile<\/li>\n<li><strong>MINOR<\/strong>: nuove feature retrocompatibili<\/li>\n<li><strong>PATCH<\/strong>: bugfix retrocompatibili<\/li>\n<\/ul>\n<p>Per software interno aziendale, alcuni team preferiscono CalVer (Calendar Versioning, es. <code>2021.07.31<\/code>) o un semplice numero progressivo. L&#8217;importante e&#8217; avere una convenzione e applicarla con coerenza.<\/p>\n<p>Workflow tipico di rilascio:<\/p>\n<pre><code>git checkout main\ngit pull\ngit tag -a v2.4.0 -m \"Release 2.4.0 \u2014 nuova dashboard analytics\"\ngit push origin v2.4.0\n# il push del tag triggera la pipeline CI\/CD che builda\n# l'artefatto e fa deploy in produzione<\/code><\/pre>\n<p>Buona pratica: associare ad ogni tag una <strong>release note<\/strong> (su GitHub Releases o GitLab Releases) che descrive in modo human-readable le novita&#8217; della versione. Le release note possono essere generate automaticamente dai messaggi Conventional Commits della release, oppure curate a mano dal release manager. Per software B2B, le release note diventano comunicazione commerciale verso il cliente: &#8220;cosa abbiamo aggiunto, cosa abbiamo corretto, cosa cambia per te&#8221;. Per software interno, sono il diario tecnico utile durante post-mortem e investigazioni di bug regressivi.<\/p>\n<h2>Git workflow per team distribuiti<\/h2>\n<p>Il 2020-2021 ha accelerato il passaggio al lavoro da remoto. Un team distribuito fra Milano, Bari e Lisbona ha sfide specifiche che richiedono adattamenti al workflow:<\/p>\n<ul>\n<li><strong>Async-first<\/strong>: le PR review devono poter avvenire senza meeting sincroni. Descrizioni dettagliate, screenshot, video Loom sono cruciali<\/li>\n<li><strong>Time zone friendly<\/strong>: si evitano blocchi tipo &#8220;merge solo dopo standup&#8221;. Si protegge il branch e si lascia mergere a chi finisce la review<\/li>\n<li><strong>Documentazione del workflow<\/strong>: il file <code>CONTRIBUTING.md<\/code> nel repo descrive convenzioni, branch naming, commit format. Niente &#8220;tradizione orale&#8221;<\/li>\n<li><strong>Feature flag per rollout graduali<\/strong>: utile quando il QA e&#8217; in un fuso diverso dal dev<\/li>\n<li><strong>Pair programming via VS Code Live Share o JetBrains Code With Me<\/strong> per onboarding e debug complessi<\/li>\n<\/ul>\n<p>L&#8217;<a href=\"https:\/\/brentasoft.com\/soluzioni\/automazione.php\">automazione<\/a> (CI\/CD, linting pre-commit, dependabot) diventa ancora piu&#8217; importante: in un team distribuito non puoi affidarti al fatto che &#8220;Marco ti ricorda di lanciare i test prima di pushare&#8221;.<\/p>\n<h2>Errori frequenti<\/h2>\n<p>Dopo aver visto decine di team adottare (e fallire) workflow Git, gli errori ricorrenti sono pochi e identificabili:<\/p>\n<ol>\n<li><strong>Adottare GitFlow per una piccola web app<\/strong>. Overhead enorme, beneficio nullo. Per progetti <30 developer e deploy continuo, GitHub Flow o TBD soft sono molto piu' efficaci<\/li>\n<li><strong>Branch lunghissimi<\/strong>. Un branch <code>feature\/redesign-completo<\/code> aperto da 3 mesi e&#8217; garantito che diventera&#8217; un incubo di merge conflict. Spezzare in branch piccoli, mergere spesso<\/li>\n<li><strong>Force push su branch condivisi<\/strong>. <code>git push --force<\/code> su main o su un branch dove altri stanno lavorando = lavoro distrutto. Usare sempre <code>--force-with-lease<\/code> e mai su branch condivisi<\/li>\n<li><strong>Commit &#8220;wip&#8221; e &#8220;fix&#8221; sparsi<\/strong>. Pulire la storia con <code>git rebase -i<\/code> prima del merge. La storia di main deve essere leggibile<\/li>\n<li><strong>Niente review<\/strong> (&#8220;siamo solo in due, fidiamoci&#8221;). Anche con due developer, la review e&#8217; utile: trova bug, diffonde conoscenza, crea responsabilita&#8217; condivisa<\/li>\n<li><strong>Branch protection disabilitata<\/strong>. Dimenticare di proteggere main e&#8217; un disastro che aspetta di succedere<\/li>\n<li><strong>Mischiare feature e bugfix nello stesso branch<\/strong>. Una PR = una cosa. Cambia il colore del bottone E aggiunge l&#8217;auth a due fattori? Due PR separate<\/li>\n<li><strong>Niente convenzioni di naming<\/strong>. Branch chiamati <code>test<\/code>, <code>asd<\/code>, <code>fix<\/code> sono il sintomo di un team senza disciplina<\/li>\n<\/ol>\n<h2>Domande frequenti<\/h2>\n<p><strong>GitFlow o GitHub Flow per una PMI italiana?<\/strong><br \/>\nDipende dal prodotto. Se sviluppi una web app con un solo ambiente di produzione e fai deploy frequenti: GitHub Flow. Se vendi software on-premise a clienti che girano su versioni diverse: GitFlow. Per la maggior parte delle PMI che sviluppano gestionali web SaaS, GitHub Flow o GitLab Flow sono la scelta migliore.<\/p>\n<p><strong>Posso usare GitHub Flow con un team di 30+ developer?<\/strong><br \/>\nSi, ma con accorgimenti: branch protection rigorosa, code owners, CI obbligatoria, monorepo o multirepo ben organizzati. A scala enterprise, molti team migrano verso TBD per ridurre i tempi di integrazione.<\/p>\n<p><strong>Rebase o merge?<\/strong><br \/>\nDipende dalla cultura del team. Rebase produce una storia lineare e pulita, ma richiede disciplina e puo&#8217; essere pericoloso se fatto su branch condivisi. Merge preserva la storia reale ma produce un grafo piu&#8217; &#8220;ramificato&#8221;. Una via di mezzo popolare: <strong>squash merge<\/strong> della PR (un solo commit pulito su main) + rebase locale del developer prima della PR.<\/p>\n<p><strong>Quanto deve vivere una feature branch?<\/strong><br \/>\nIdealmente 1-3 giorni. Sopra la settimana entri in zona pericolo. Sopra il mese, devi spezzare il lavoro in feature flag e mergere parti incomplete (ma disabilitate) frequentemente.<\/p>\n<p><strong>GitHub, GitLab o Bitbucket?<\/strong><br \/>\nTutti e tre sono ottimi nel 2021. GitHub ha la community piu&#8217; ampia e l&#8217;integrazione migliore con il marketplace di tool. GitLab offre una piattaforma piu&#8217; integrata (CI\/CD, container registry, security scanning inclusi nel piano base). Bitbucket si integra naturalmente con Jira e Confluence se sei in un ecosistema Atlassian.<\/p>\n<p><strong>Conventional Commits e&#8217; obbligatorio?<\/strong><br \/>\nNo, ma altamente consigliato. Anche solo applicare i prefissi <code>feat:<\/code>, <code>fix:<\/code>, <code>chore:<\/code> rende la storia leggibile. E se vuoi automatizzare CHANGELOG e versionamento, e&#8217; un prerequisito.<\/p>\n<div style=\"background:#f5f7fa;border-left:4px solid #0066cc;padding:20px;margin:30px 0;border-radius:4px;\">\n<h3 style=\"margin-top:0;\">Stai impostando il workflow Git del tuo team di sviluppo?<\/h3>\n<p>Brentasoft sviluppa applicazioni custom con team di developer interni e su GitHub\/GitLab, applicando workflow Git, code review e CI\/CD per PMI italiane.<\/p>\n<p style=\"margin-bottom:0;\"><a href=\"https:\/\/brentasoft.com\/erp-brenta.php\" style=\"display:inline-block;background:#0066cc;color:#fff;padding:12px 24px;border-radius:4px;text-decoration:none;font-weight:600;\">Scopri ERP Brenta &rarr;<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Git workflow team: guida 2021 a GitFlow, GitHub Flow, GitLab Flow, trunk-based, code review, branch naming, Conventional Commits per PMI italiane.<\/p>\n","protected":false},"author":2,"featured_media":992,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Git workflow per team: la guida 2021","_seopress_titles_desc":"Git workflow team 2021: guida a GitFlow, GitHub Flow, GitLab Flow, trunk-based, code review, branch naming e Conventional Commits per PMI italiane.","_seopress_robots_index":"","footnotes":""},"categories":[9],"tags":[647,648,649,643,644,645,646],"class_list":["post-991","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-guide-e-tutorial","tag-branching-strategy","tag-code-review","tag-commit-convention","tag-git","tag-gitflow","tag-github-flow","tag-trunk-based"],"_links":{"self":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/991","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/comments?post=991"}],"version-history":[{"count":0,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/991\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media\/992"}],"wp:attachment":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media?parent=991"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/categories?post=991"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/tags?post=991"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}