flusso di lavoro git di piccole dimensioni

Question

flusso di lavoro git di piccole dimensioni

#1 da (3 voti)

4

Voglio chiedere se il seguente flusso di lavoro è corretto! Si riferisce a una piccola squadra privata. C'è un ramo master in cui nessuno si fonde lì (tranne il manutentore), un ramo di sviluppo e rami individuali per ogni utente. Quindi, ogni utente spingerà al ramo di sviluppo.

* clone the repo to your local machine
  git clone https://github.com/username/project.git

* cd project

* git remote add upstream https://github.com/group/project.git

* git checkout userbranch 
* git add files
  git commit -m ".."

* git push origin userbranch ( I am not sure if this step is necessary since I 

* Merge into development and push your work to development
  git checkout development
  git merge --no-ff userbranch
  git push origin development

* Update local master to apply changes from master to the local  repository.
  git checkout userbranch  ( or checkout local master? )
  git fetch upstream
  git merge upstream/development

* git push origin development

Non sono sicuro che tutta la sequenza sia corretta (non voglio fare errori!). Inoltre, non sono sicuro dei passaggi in cui dico Update local master to apply changes from master to the local repository e Merge into development and push your work to development se funzionano come previsto.

E all'ultima fase devo effettuare il checkout sul mio ramo o sul mio master locale?

E infine, (se quanto sopra è corretto) a che punto posso recuperare e unirmi dal ramo principale? In generale, come posso combinare rami master e di sviluppo?

git github

posta George 03.05.2016 - 10:31

fonte

1 risposta

Leggi altre domande sui tag git github

Una domanda sull'implementazione degli oggetti in una lingua scritta in C Trovare la sottosequenza più lunga con una somma inferiore o uguale a un numero fisso

score 3 · Answer 1

La tua domanda dovrebbe comportare la descrizione del processo di consegna e di sviluppo e quindi potresti decidere quali filiali devi mantenere.

Presumo un set-up classico. Hai un ramo di sviluppo principale, in cui tutto è sviluppato per impostazione predefinita e un ramo di rilascio, che è ciò che stai preparando a pubblicare come rilascio ai clienti.

Per un ramo di sviluppo predefinito è meglio utilizzare il ramo master , poiché è un ramo predefinito, in modo che gli sviluppatori possano lavorarci subito. Per le versioni crea un ramo release . Il flusso di lavoro per uno sviluppatore sta seguendo:

git clone link
progetto cd
git aggiungi file / git commit
git pull, git push
vai a 3.

Per un gestore di rilascio durante la versione:

rilascio di git checkout
git merge master
tag git v1.2.3.4
git push & & git push --tags

"Userbranches" saranno filiali locali nei cloni di dev (o nelle forche), quindi di solito non devi fare nulla di speciale su di esso, nessun nome speciale. È più facile quando i nomi dei rami corrispondono.

Questo è lo scenario di base, se hai bisogno di altre opzioni, ad es. facendo hotfix o feature branch, puoi crearne tutto sopra questa base.

Se hai bisogno di una revisione del codice (solo una persona designata potrebbe unire il codice da sviluppatori in master), allora hai bisogno di fork. I fork in github sono per richieste pull. Quindi, l'utente spinge il suo lavoro in un fork e invia una richiesta di pull alla persona designata.