Ogni volta che inizia un nuovo progetto, di solito ha senso iniziare impegnandosi direttamente a padroneggiare fino a quando non si ottiene qualcosa di "stabile", quindi si inizia a lavorare nei rami.
Almeno, è così che lo faccio normalmente. C'è un modo per avviare immediatamente le filiali dal secondo commit? Ha senso farlo in questo modo? Ovviamente, "Initial Commit" sarà sempre il padrone, ma dopo, quando saprò che è il momento giusto per iniziare a creare filiali per nuove funzionalità?
Risposte:
Subito.
La chiave è la domanda su quale sia la politica per il Master. Con git, in genere, la politica di succursale su Master è la versione stabile costruibile . A volte, Master è la 'linea principale' da cui i rami sono fatti e uniti prima della fusione con un ramo di rilascio. Questi sono due diversi approcci ruolo / politica.
Spesso è una fonte di errori per le persone cambiare il ruolo o la politica di una filiale a metà del progetto. È più facile per uno sviluppatore solista comunicare questi cambiamenti ai collaboratori, ma cercando di convincere una dozzina di programmatori a riconoscere tutti "Il Master è ora in 1.0, per favore dirama le funzionalità piuttosto che tutti spingono ad esso"
Ho toccato l'approccio politico sopra. La politica per Master è che si tratta della versione stabile costruibile . Il controllo di piccole modifiche incrementali in questo significa che non hai sempre qualcosa di costruibile stabile. Non fare il check in piccole modifiche va contro "un sacco di check-in piccoli (ma completi)" che tende ad essere la migliore politica (e incoraggiata da una facile ramificazione).
Da un punto di vista basato sui ruoli, hai iniziato con il ruolo principale in ruoli di ruolo principale, rilascio, manutenzione e sviluppo, e poi alcuni punti indicano che il ruolo di sviluppo e manutenzione passa alle filiali. Ciò significa di nuovo un cambiamento in ciò che è consentito al master e può confondere i partecipanti su dove appartengono le cose. Può anche (leggermente) confondere la storia della filiale, incoraggiando grandi impegni che significano fusioni più grandi e più difficili da comprendere.
Chiave i ruoli e le politiche sui rami semplice e coerente fin dall'inizio.
Questo "ramo sul cambio di politica" può essere visto nei modelli di diramazione . L'idea di ogni ramo con ruoli può essere letta in Strategie di ramificazione SCM avanzate . Entrambe sono letture molto buone.
Esistono principalmente due situazioni in cui in genere si desidera iniziare a lavorare con i rami:
quando tu o il tuo team dovete avviare una nuova funzionalità che ha la minima possibilità di non essere aggiunta alla versione successiva (che potrebbe essere la prima versione in assoluto), quindi avviare lo sviluppo in un ramo di funzionalità separato
quando devi fornire correzioni per gravi bug all'ultima versione e vuoi creare una nuova versione di bugfix contenente solo quelle correzioni, ma nessuna funzionalità di recente sviluppo (e probabilmente instabile)
Per questo tipo di decisioni, penso che sia utile pensare sempre in termini di "nuove funzionalità" o "bugfixes", dal punto in cui hai una prima versione compilabile / eseguibile del tuo programma.
Michael Feathers elenca quattro motivi per cambiare nel suo famoso libro, ma metterei "ottimizza le risorse" sotto "nuovo ramo di funzionalità" (per una funzione non funzionale) e "migliora il design" la maggior parte delle volte anche sotto "nuovo ramo di funzionalità" , poiché IMHO non dovrebbe mai migliorare il design quando questo non è inteso allo scopo di rendere più semplice l'implementazione di una specifica funzionalità.
Se segui git-flow - e, francamente, penso che tu sia pazzo se usi Git e non usi quel modello di diramazione - allora non dovresti mai impegnarti masterfino a quando non sei davvero pronto per un rilascio pubblico.
Il tuo primo commit masterdovrebbe essere un repository vuoto. Il tuo prossimo commit masterdovrebbe essere un commit di merge dal developramo o un ramo di rilascio temporaneo e dovrebbe essere stabile, testato e pronto per la distribuzione (se si tratta di un'applicazione) o distribuzione pubblica (se si tratta di una libreria).
Ci sono altri modelli di ramificazione per Git, ma la maggior parte di loro hanno sono derivati dai modelli SCM centralizzata anziani e può portare a gravi problemi in un ambiente DVCS. Non è necessario utilizzare l'estensione git-flow e non sono necessariamente necessari tutti quei rami release / hotfix / feature, ma le ossa nude sono develope mastere il codice instabile entra develop.
master. Ricorda che masternon è niente di speciale da usare, non ha bisogno di essere lì. Puoi semplicemente avere un ramo di sviluppo fino a quando non vuoi rilasciare una versione.
Neal Ford of Thoughtworks sostiene l'uso delle funzionalità di attivazione / disattivazione delle ramificazioni per evitare il problema di "unire l'inferno". Considera il caso in cui due programmatori si uniscono quotidianamente alla filiale principale e uno dei cambiamenti considerevoli avviene in alcune settimane e poi si impegna. L'altro programmatore potrebbe benissimo finire in un inferno. Per evitare questo problema, Ford consiglia di "portare avanti il dolore" (un attributo agile ben noto) avendo un solo ramo e impegnandosi quotidianamente. Funzionalità aggiuntive vengono aggiunte tramite interruttori funzione che disabilitano la funzionalità fino a quando non è stata completamente testata.
Questa metodologia sembrerebbe funzionare meglio in un ambiente che implementa la consegna continua poiché i problemi con un commit verrebbero immediatamente colti.
Sono passati due anni dall'ultima risposta a questa domanda e penso che ora la storia cambi. Per me la risposta è "Ogni volta che usi il controllo del codice sorgente per tenere traccia delle versioni".
Per elaborare, al giorno d'oggi il monitoraggio delle versioni del progetto con il controllo del codice sorgente non sempre funziona. (ad esempio utilizzando npm per gestire la dipendenza e specificare le versioni semantiche con '^') In tal caso, gli artefatti del progetto cambiano ogni volta che si verifica una generazione, con non necessariamente corrispondente alle modifiche del codice sorgente ogni volta. Per gestire questo tipo di nuove sfide, alcuni team scelgono di aver già creato "artefatti" salvati nel sistema di controllo degli artefatti (ad es. JFrog Artifactory) per tracciare le versioni del progetto.
Ovviamente quando si ha già il controllo della versione degli artefatti, non si estrae il 'codice di produzione' da un ramo GIT e non si costruisce / si distribuisce alla produzione, invece si consulta il sistema di controllo degli artefatti per una versione eseguibile direttamente per la distribuzione. In tali casi il concetto di "ramo di rilascio" perde improvvisamente il suo significato. E ogni volta che il tuo team decide di non associare git branch alla versione di rilascio, impegnarsi / spingere direttamente verso il master diventa ancora una volta una scelta valida: arriva come ramo predefinito ogni volta che il repository viene clonato, quindi automaticamente data la semantica ampiamente accettata e ben comunicata i cambiamenti. Tuttavia, come suggerisce la risposta accettata, dovresti probabilmente andare a capo di un ruolo nei rami incluso il master e usare quei rami solo per quei ruoli particolari.
Infine, faccio un ulteriore passo avanti e suggerisco di utilizzare master come ramo di sviluppo in progetti con solo una manciata di core committer. Questo è il caso del mio team e probabilmente lo stesso per la maggior parte dei negozi di micro-servizi. L'impegno sul master rimuove la comunicazione del processo di modifica ed evita potenzialmente di "unire l'inferno" quando si lavora su funzionalità attraverso più sprint. Inoltre, il codice nel ramo master non deve nemmeno "funzionare", il processo di compilazione / test automatizzato ti dirà cosa è andato storto ed è comunque abbastanza facile controllare la cronologia di Git e contattare l'autore che ha rotto la build / test :-)
Prenderò una posizione radicale: rammenta ogni idea. In primo luogo nei rami git sono economici, il costo principale di un ramo è ricordare a cosa serve. Concordo anche sul fatto che il primo impegno da padroneggiare sia un candidato al rilascio. Consiglio di iniziare con un ramo di prova del concetto. Dopo aver dimostrato il tuo concetto, puoi unirlo con il tuo ramo di sviluppo vuoto o riscriverlo a seconda di quanto è buono il tuo primo tentativo. da questo punto ti dirigi dallo sviluppo per ogni bug, caratteristica, astrazione, ecc.