[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT - di nuovo] consiglio su uso di git.



Il giorno sab 14 lug 2018 alle ore 08:39 Paolo Miotto
<paolo.miotto@uniud.it> ha scritto:
>
> Il 13/07/2018 22:53, Gollum1 ha scritto:
> > Ho scelto bitbucket perché mi permette di fare il repository privato
>
> Anche gitlab ha  repo privati (ma anche qui ti devi iscrivere).

allora tanto vale continuare con gbitbucket, visto che gli account li ho già.

> Se hai in vps puoi usare gitolite per consentire l'accesso al singolo
> branch senza dover usare 2 repo.
No, niente vps (almeno per ora).

però ho un server linux (RH purtroppo) in azienda, dici che potrei
metterci su qualcosa per usarlo come repository, e fare in modo che i
miei studenti possano prelevare da li? tanto sono tutti dipendenti
dell'azienda, quindi virtualmente potrei anche gestire i loro accessi.

Ma non saprei proprio cosa potrebbe servirmi per fare una cosa del genere.

nel frattempo comunque uso bitbucket, in quanto mi permette di
lavorarci anche quando non sono in azienda, poi potrei clonare il
repository pubblico sul server aziendale...

passo successivo, quando torno al lavoro.

> > leggendo un po' di documentazione su git, mi pare di aver capito però
> > che io posso avere sì due repository, ma alimentati da una sola
> > directory di sviluppo locale,
>
> Esattamente.

esattamente, ma mi trovo in difficoltà... non riesco a chiarirmi l'uso
di git, ho qualche difficoltà con questo modo di gestire il
software/documentazione.

solitamente comincio da bitbucket, dove creo il repository e poi lo
clono in locale, e comincio a riempirlo, facendo poi i commit.

in questo caso devo crearne due di repository su bitbucket, quello di
sviluppo e quello di distribuzione.

credo di aver capito che quello di sviluppo è quello che poi clono
così come è, con tutto il contenuto che vado a mettere in locale.

> Setti il remote origin al repo completo, dove hai master e i feature branch.
quello di sviluppo quindi...

> Crei un nuovo remote (public) che conterrà i branch che vuoi diffondere.
>
> git remote add public ssh://...
con questo quindi aggancio sul mio progetto anche il secondo repository, giusto?

> Crei un nuovo branch (diciamo gruppo1) che userai per pubblicare
> la tua documentazione.
>
> git checkout -b corso1
in questo modo mi sposto sul branch che poi voglio distribuire...

>
> Quindi fai il push di corso1 su public, impostandolo come upstream
>
> git push --set-upstream public corso1
a cosa serve settarlo come upstream?

>
> a questo punto puoi andare avanti con i commit in master e feature branch,
quindi mi devo rispostare con il checkout, giusto?

> quando sei a una situazione stabile fai un merge --squash su corso1 (per
> collassare i commit di sviluppo in un unico commit) e poi fai il push su
> public

quindi questo comando farebbe un commit unico, perdendo tutti i commit
intermedi che ho fatto? è questo il senso?
naturalmente solo per il branch corso sul repository di distribuzione.
>
> git push public
forse ho capito... upstream è una label per identificare
immediatamente il repository pubblico con il branch corso.
>

> Sono andato un po' a memoria negli esempi, spero che siano tutti esatti,

vado a rivedermi i singoli comandi, per sicurezza... intanto penso di
aver capito cosa cercare e come pensare il lavoro.

> in ogni
> caso la procedura generale che uso io è questa.
>
> Poi puoi decidere se vare il push di corso1 anche su origin o se ti
> basta averlo in public.

potrebbe servire? in realtà su origin dovrei mantenere solo la parte
di sviluppo... o no?

Spero di aver capito i vari passaggi... appena posso faccio qualche
prova e poi faccio i due repository e comincio a rimetterci su il
materiale.

Grazie.
-- 
Gollum1 - http://www.gollumone.it
Tesssssoro, dov'é il mio tessssoro...


Reply to: