Re: [OT - di nuovo] consiglio su uso di git.
Il 15/07/2018 22:48, Gollum1 ha scritto:
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?
per l'accesso ad un repo git non locale si usa di solito http per dare gli
accessi in sola lettura e ssh per lettura/scrittura.
Con gitolite puoi concedere gli accessi ssh senza appoggiarti agli utenti
di sistema (usi un unico utente). Ogni utente ha la sua chiave ssh e puoi
configurare in maniera fine le permission sui repository e anche sul
singolo
branch.
Perché sia comodo per te fare il push verso tale server dovrebbe essere
raggiungibile da remoto via ssh, altrimenti ogni volta che vai in
azienda devi
fare il push prima di cominciare la lezione.
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.
Git è un sistema distribuito, per cui si possono avere molti repository
remoti collegati al proprio repository locale. Ognuno dei repository
remoti può avere tutti o solo alcuni branch presenti nel repo locale,
così come il repo locale può avere tutti o solo alcuni dei branc del
repo remoto.
solitamente comincio da bitbucket, dove creo il repository e poi lo
clono in locale, e comincio a riempirlo, facendo poi i commit.
Di solito si clona un repository che ha già dei commit, o uno vuoto
per non dover stare a configurare i remote.
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.
Esattamente: crei il repo di sviluppo (con master e feature branch),
e lo cloni sul tuoi pc, questo diventa automaticamente il tuo repo
*origin*.
Puoi crei un secondo repo vuoto per gli studenti, non lo cloni, ma
lo aggancerai dopo con *git remote add*
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?
Giusto,il secondo repo viene agganciato come *public* (o qualsiasi altra
label significativa che tu voglia dargli).
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...
con *checkout -b* crei un nuovo branch *corso1* a partire dal
branch su cui sei posizionato.
Quindi fai il push di corso1 su public, impostandolo come upstream
git push --set-upstream public corso1
a cosa serve settarlo come upstream?
Se lo setti come upstream non devi specificare il branch remoto ogni
volta che fai un push.
a questo punto puoi andare avanti con i commit in master e feature branch,
quindi mi devo rispostare con il checkout, giusto?
si, procedi a lavorare normalmente, facendo i tuoi commit direttamente su
master o usando i feature branch, a seconda del tuo workflow.
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.
Tu hai parlato di un branch dedicato agli studenti senza parti
intermedie di sviluppo:
Il 13/07/2018 22:53, Gollum1 ha scritto:
Ora, il discorso è che non vorrei far scaricare tutto il repository,
contenente anche tutte le parti intermedie di sviluppo, ma solo gli
step "stabili" della documentazione (che potrebbe modificarsi
attraverso il feedback avuto durante i corsi, di sessione in
sessione).
quindi ho immaginato che tu non voglia fare vedere tutti i commit che ti
hanno portato ad un certo step della documentazione, ma solo le varie
versioni dela documentazione che produci. Con *merge --squash* tu
mantieni in *master* tutta la tua history, ma non la esponi agli studenti.
Se vuoi invece esportare tutti i commit basta fare un *merge* senza squash.
git push public
forse ho capito... upstream è una label per identificare
immediatamente il repository pubblico con il branch corso.
esatto, in questo modo fai il push del branch corrente su repository
*public*
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?
Tu hai tutto sul tuo pc, ma in remoto è suddiviso su 2 o più repository
(se fai più corsi e ne dedichi uno a ciascuno).
Se devi ricostruire il repository locale (o condividerlo con qualcuno che
ti aiuta a fare la documentazione) è scomodo e soggetto ad errori e
dimenticanze dovere ricordarsi di agganciare i vari remote per avere
la situazione completa.
Avere tutto in un unico repo ti semplifica la vita e niente di più.
--
Mandi.
Paolo
Reply to: