GitHub OS project come avere una buona versione e una versione work in progress

Question

GitHub OS project come avere una buona versione e una versione work in progress

#1 da (2 voti)
#2 da (0 voti)
#3 da (0 voti)

2

Ho avviato la mia applicazione del sistema operativo, la sto ospitando su GitHub. Il mio problema è che sposto le modifiche al repository da più di una posizione, quindi a volte voglio lavorarci sopra e a volte non riesco sempre a finire qualcosa in tempo, ma mi piacerebbe comunque spingerlo comunque così posso recuperarlo più tardi la mia altra posizione. Mi piacerebbe essere in grado di avere una versione stabile e avere il master branch come "work in progress".

Come faccio a fare questo?

C'è un pulsante che posso spingere che prenderà il codice dal mio ramo principale e lo inserirò in un file zip nella mia scheda download e lo chiamerò una versione o dovrei farlo a mano?

Sarebbe meglio avere il master branch bello e pulito e avere un ramo separato con cui giocare e poi unire i due quando è il momento giusto? Questo non causerebbe più problemi nella fase di fusione?

branching versioning github

posta Para 30.10.2012 - 12:21

fonte

3 risposte

Leggi altre domande sui tag branching versioning github

Un codebase: molti servizi in hosting (simili a un servizio in stile basecamp) - struttura di pianificazione DDD Model Design and Repository Persistenza Considerazioni sulle prestazioni

score 2 · Answer 1

Alcuni progetti dedicano il ramo principale per "stable" e usano un ramo separato, come "dev" per cose all'avanguardia. Il ramo di sviluppo viene quindi unito al master ogni tanto, quando è in uno stato stabile. Per feature più grandi e innovative è una buona idea utilizzare i branch di feature completamente separati.

Un'altra opzione è di fare il contrario e avere il master come ramo di sviluppo e creare branch di rilascio. Assicurati solo di documentare che il master è instabile. Nota che puoi anche cambiare il ramo predefinito mostrato da GitHub dal pannello di amministrazione.

Forse un modo più elegante, e si prende anche cura dei file zip automaticamente è quello di taggare le versioni stabili. GitHub crea collegamenti zip automatici per ogni tag nella scheda Tags , che si trova accanto a Downloads . Per la guida alla codifica, consulta questo link .

Se esegui commit nel ramo stabile, assicurati di unirli al ramo di sviluppo molto spesso. Ciò minimizzerà i conflitti di fusione.

Se non conosci la ramificazione, ecco una guida .

score 0 · Answer 2

Avere il tuo atto principale come il tuo baule in corso, questo è ciò che costituirà il tuo prossimo rilascio.

Utilizza un ramo separato per ogni funzione e quindi uniscili di nuovo nel trunk principale quando sono stati completamente sviluppati e testati e poi testati nuovamente sul trunk principale.

Rendi periodicamente i rami di rilascio dal principale e utilizza il registro dei rami aperti correnti e uniti in rami per creare note di rilascio che descrivono guasti noti e funzionalità aggiunte. Ciò significa che questi rami rimangono statici in modo che tu possa fornire il supporto per l'utente per più versioni, non solo per l'ultima versione.

score 0 · Answer 3

Dovresti (quasi) avere sempre un ramo master funzionante nei repository git.

Questo non significa che puoi spingere a padroneggiare solo quando fai una nuova versione, ma vuol dire che dovresti usare un altro ramo quando stai implementando una nuova funzione.

Unisci new_feature a master dopo che la funzione è stata completata e testata.

Le patch e le nuove diramazioni (feature) sono normalmente basate su master .

Potresti usare un ramo chiamato stable , dato che puoi cambiare quale ramo è il ramo predefinito mostrato in github. Tuttavia, anche stable viene spesso utilizzato come ramo che riceve solo modifiche per le correzioni di sicurezza o simili del rilascio attualmente stabile.

In ogni caso, non dovresti rebase o push -f a rami "ben noti" come master e stable , poiché spesso è inaspettato. Puoi rebase nei branch delle feature quanto vuoi e rompere le cose nei feature branch non è un grosso problema.

L'utilizzo dei rami di funzionalità è particolarmente importante quando si desidera aprire pull_requests su github. Dopo aver aperto una richiesta di pull per unire un ramo in qualche altro ramo, non puoi usare quel ramo senza che le tue modifiche appaiano in quella richiesta di pull. Ciò significa che dovresti utilizzare solo il ramo master se il tuo repository è il repository principale. Quando hai solo una forchetta e non hai intenzione di renderlo un progetto autonomo, non dovresti usare il ramo master nella tua forcella, solo i rami delle funzionalità.