Abbiamo distinti tipi di rami?

Question

Abbiamo distinti tipi di rami?

#1 da (8 voti)

2

C'è ciò che chiamiamo feature branch in git. Immagina per esempio che sto facendo un gioco e ho bisogno di aggiungere una funzione Power-up .

Come vedo i miei nomi di commit con rami di funzione:
Nome di ramo : Adding Power-up.
Primo nome di commit : Added prefab.
Secondo nome commit : Implemented graphics.
Nome terzo commit : Added collision detection.
Quarto nome commit : Added effect on player on collision.

Come vedo i miei nomi di commit senza rami delle funzioni:
Primo nome commit : Adding power-up: added prefab.
Secondo nome commit : Adding power-up: added graphics.
Terzo nome commit : Adding power-up: added collision detection.
Quarto nome commit : Adding power-up: added effect on player on collision.

Quando i commit erano file, creai una directory chiamata Power-up e inserisco prefab , graphics , collision detection , effect on player on collision all'interno di quella cartella.

Un altro uso dei rami git è quello di separare la versione di sviluppo dalla versione di produzione.

Se la mia intuizione è corretta, le feature git sono paragonabili alle cartelle su explorer e git master e dev branch paragonabili agli ambienti?
Ho dimenticato un altro "tipo" di ramo?
Se ci sono diversi tipi di rami, dovrebbe git aggiungere qualche struttura? (come un comando chiamato git featureBranch <newBranchName> o git environmentBranch <newBranchName> forse)

Riferimento (s):
- link
- link

git naming gitflow

posta Ambroise Rabier 07.12.2018 - 13:23

fonte

1 risposta

Leggi altre domande sui tag git naming gitflow

Differenza tra MVC ed ECS È 'Mantenere l'aspetto simile al codice di esempio' un motivo valido per preferire il principio WET over DRY?

score 8 · Accepted Answer

Non per diventare tutti filosofici, ma una branca in git è una realtà alternativa della tua base di codice - un universo parallelo - in cui una nuova funzionalità o correzione di errori viene sviluppata separatamente da tutte le altre modifiche al codice.

Un ramo in git non dovrebbe essere visto come una "cartella" contenente i file. Dovrebbe essere visto come una timeline che registra modifiche indipendenti e isolate alla tua base di codice.

Il ramo principale è l'unica linea temporale comune su cui si basano tutti gli altri. Tutti gli altri universi paralleli (rami) si scheggiano dal maestro e si evolvono a modo loro (si impegna sugli altri rami). Quando la nuova funzionalità o correzione di bug è pronta per essere inclusa nelle altre timeline (altri rami) queste realtà alternative si scontrano nella forma di un git merge .

Alcuni rami vivono più a lungo di altri. Una correzione di difetti potrebbe essere in giro solo per alcuni giorni. Un nuovo ramo di funzionalità potrebbe essere in giro per alcune settimane. Il ramo "dev" potrebbe essere scisso dal master all'inizio del progetto e sopravvive finché l'applicazione non viene ritirata.

I rami possono essere differenziati gli uni dagli altri in base al loro uso previsto e alla durata della vita, il che ti dà qualcosa di simile a "tipi di rami:"

master: creato il giorno 1. Vive finché il repository non viene eliminato. Solitamente è la fonte canonica su cui tutti gli altri rami sono fondamentalmente basati.
Un ramo di integrazione: il lavoro di molte persone è integrato qui in modo che possa essere testato correttamente prima di essere unito in master. Possono essere chiamati cose come "dev" o "sviluppo" o possono essere denominati in base ad ambienti applicativi (come "qa" o "uat")
Difetto correzione: un ramo di breve durata per risolvere un problema di produzione
Nuova funzionalità: un ramo, solitamente di breve durata, per aggiungere nuove funzionalità al sistema