Mantenere una cronologia git pulita durante l'utilizzo di gitflow - commit non interrotti durante lo sviluppo

10

Usando gitflow, quando crei un ramo release-1.0.0 e lo unisci a master e develop , entrambi i rami avranno un commit mancante:

  • master non ha il commit dove release-1.0.0 è stato unito a develop
  • develop non ha il commit dove release-1.0.0 è stato unito a master

Invece, dopo che hotfix-1.0.1 è stato creato e unito a master , quando viene unito a develop , il commit per unire includerà il commit precedente dove release-1.0.0 è stato unito a master ; quindi assomiglierà a questo:

User 'john doe' is trying to merge the following commits into 'develop' from 'hotfix-1.1.1'.

* merge release-1.0.0 to master
* merge release-1.1.0 to master
* Fix shopping cart critical bug

Se suona confuso, puoi facilmente notare che questo è tutto ciò che vedi develop di solito è un paio di commit dietro master (anche se sviluppare, in teoria, dovrebbe solo essere avanti poiché è il ramo principale. Questi commit si fondono da release-x.x.x a master ).

Come dovrebbe essere gestito per mantenere una cronologia pulita?

    
posta Christopher Francisco 03.11.2016 - 20:21
fonte

1 risposta

3

Penso che un buon approccio sia evitare di avere due rami "principali": padroneggiare e sviluppare sono ridondanti. È spiegato dettagliatamente qui , branded cactus-flow dal autore.

Alcuni punti si distinguono invece che git-flow:

  • Solo un ramo principale
  • Solo una fusione veloce

Per me l'ultimo è importante, poiché dopo aver usato git-flow per molto tempo devo ancora vedere cosa è utile su --no-ff merges.

I'm trying to follow gitflow as close as possible to it's documentation. I'd rather not doing any kind of "hackz" because since gitflow is already adopted by many many developers, they should already have a solution for this simple thing

IMHO è il tuo grande errore. Non c'è motivo per te di attenersi a git-flow il più possibile. Può essere usato in migliaia di progetti, ma ciò non influisce sul tuo, non lo rende buono.

Git-flow è un buon punto di partenza, ma dovresti pensare ad adattarlo agli strumenti e al flusso di lavoro piuttosto che viceversa.

    
risposta data 21.02.2017 - 09:08
fonte

Leggi altre domande sui tag