Sto scrivendo un semplice framework che voglio open source solo per esperienza (e divertimento!). Tuttavia, ha alcune idee interessanti che potrebbero far crescere un progetto più ampio e voglio essere pronto se ciò dovesse accadere. Dubito strongmente che ciò accadrà, ma voglio usarlo come esperienza di apprendimento su come eseguire correttamente un progetto open source.
Voglio tuffarmi proprio nello sviluppo. Non sono troppo preoccupato per il codice reale poiché dovrebbe essere per lo più semplice. Tuttavia, non sono così esperto con Github. Voglio dire, conosco tutte le basi e cose simili, ma non so davvero come utilizzare tutti gli strumenti a mio vantaggio.
Come dovrei gestire un flusso di lavoro per accogliere al meglio gli sviluppatori? Cercherò di incoraggiare la procedura "standard":
- Fork the repository
- Clona il repository al tuo client Git
- Crea un nuovo ramo per il lavoro
- Esegui il lavoro effettivo
- Impegna il tuo lavoro (se più commit, rebase per creare un commit per la cronologia facile sul repository principale)
- Invia una richiesta di pull con quel commit
Quindi, ovviamente, sceglierò se voglio farlo o meno. Ecco dove rimango bloccato. Come dovrei gestire i miei rami?
Ho redatto questo progetto:
Proposed Workflow:
In sostanza:
- Il ramo
masterè destinato a versioni stabili. Le richieste di pull individuali vengono inviate al ramo principale solo se si tratta di un bug critico e necessita di una singola release APPENA POSSIBILE. - Il ramo
betaè per il codice per la prossima versione stabile. Le correzioni dei bug verranno eseguite su questo ramo. - Il ramo
alphaè dove vengono aggiunte le richieste di funzionalità.
Quando un commit (non una richiesta pull) viene aggiunto al ramo master o beta, le modifiche sono "cascading" (cioè una richiesta pull viene automaticamente creata in modo che un commit to master sia anche in beta e alpha; un commit su beta sarà in alpha). Lo farei con una semplice sceneggiatura. Anche se sarebbe un po 'ghetto, ma sarebbe automatico.
Per una versione standard, la beta verrebbe unificata nel master e quindi l'alfa nel ramo beta.
Il motivo di ciò è che le richieste di funzionalità non vengono inserite nella versione successiva in modo che siano abbastanza stabili da essere incluse nella versione stabile.
Questo è stupido? Un ramo "dev" consolidato sarebbe il più facile da gestire, ma temo che alcuni bug possano ancora arrivare. Immagino che dovrei smettere di accettare le aggiunte di funzionalità un po 'prima di rilasciare una nuova versione.
EDIT: questa domanda è estremamente simile alla mia domanda: Esiste una best practice consolidata o definita per il branching del controllo sorgente tra sviluppo e build di produzione? . Tuttavia, sto osservando il mio metodo proposto rispetto a non gestire le richieste di pull prima di una nuova versione. Inoltre, si tratta di software open source (quindi potrebbe essere più difficile addestrare nuove persone sul sistema per questo progetto).