Re: [OT - di nuovo] consiglio su uso di git.
Scusa, sono in ferie e non riesco a seguire la lista. Devi studiarti le funzionalità dei remote: in pratica tu hai il tuoi repo locale che ha bitbucket come remote origin, in quanto l'hai clonato da lì. Poi aggiungi altri remote, ovvero altri repository su cui puoi fare push e pull di tutti i branch o solo di alcuni. Nel tuoi caso forse è preferibile avere un branch per ciascu remote, per non incasinarsi. quindi tu avresti: master -> origin/master Branch_A -> remote-a/master Branch_b -> remote_b/master ecc. Dopo di che puoi fare il diff tra master e Branch_A, se le cose che sono su Branch_A ti servono le mergi in master e le pushi su origin. Lo stesso discorso per gli altri branch.
Re: [OT - di nuovo] consiglio su uso di git.
Il 16 agosto 2018 22:16:14 CEST, Paolo Miotto ha scritto: >Scusa, sono in ferie e non riesco a seguire la lista. > >Devi studiarti le funzionalità dei remote: in pratica tu hai il tuoi >repo locale che ha bitbucket come remote origin, in quanto l'hai >clonato >da lì. > >Poi aggiungi altri remote, ovvero altri repository su cui puoi fare >push >e pull di tutti i branch o solo di alcuni. Nel tuoi caso forse è >preferibile avere un branch per ciascu remote, per non incasinarsi. > >quindi tu avresti: > >master -> origin/master > >Branch_A -> remote-a/master > >Branch_b -> remote_b/master > >ecc. > > >Dopo di che puoi fare il diff tra master e Branch_A, se le cose che >sono >su Branch_A ti servono le mergi in master e le pushi su origin. > >Lo stesso discorso per gli altri branch. quindi, ribaltare la soluzione che ho adottato io, invece di entrare in ogni backup e fare il push verso la copia locale... entro nella copia locale, creo un branch e faccio il pull da un backup, poi un'altro, e un'altro ancora... in effetti così diventa più gestibile controllare le differenze e fare il merge delle cose interessanti... grazie delle info (mi sto studiando la documentazione di git, e comincio a capire quello che mi dite in modo più chiaro e sensato... git è una gran figata). byez -- gollum1 Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli errori, maledetto correttore automatico.
Re: [OT - di nuovo] consiglio su uso di git.
Il 15 agosto 2018 18:31:49 CEST, Alessandro Pellizzari ha scritto: > >Qui onestamente non saprei. Dipende troppo da quante differenze hai. >Rischi di trovarti tre branch impossibili da mergiare. > >Probabilmente il modo più semplice è prendere un progetto come "base", >da lì creare un branch e poi copiare fisicamente i file in modo che si >calcoli lui le differenze. > >Questo però ti fa perdere la storia dei commit, e nel branch avrai un >singolo commit con tutto dentro (a meno che non committi gruppi di file >un po' alla volta). > alla fine credo di aver risolto: sono entrato nel primo backup, ho fatto il commit di tutto quello che era rimasto non commitato, e ho fatto il push, sono entrato nel secondo backup, ho fatto il pull, il merge e nuovamente il push. stessa cosa per il terzo. Ho dovuto mettere a posto qualcosina a mano, che il merge non univa, e disolvere un problemino di branch, ora tutto è caricato su un singolo repository locale. ora mi riservo di esaminare un po' i log e i file, per avere effettivamente una situazione coerente, prima di fare l'ultimo commit e il push verso il repository remoto. byez -- gollum1 Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli errori, maledetto correttore automatico.
Re: [OT - di nuovo] consiglio su uso di git.
On 13/08/18 10:30, Gollum1 wrote: > Mi trovo con tre versioni locali del repository originale, che vorrei > reinserire nel nuovo repository (più che altro, per inserire eventuali > modifiche rimaste disperse nei veri repository, altrimenti mi > basterebbe copiare spudoratamente i file dall'ultimo, e avrei anche > come effetto un rebase del repository). Qui onestamente non saprei. Dipende troppo da quante differenze hai. Rischi di trovarti tre branch impossibili da mergiare. Probabilmente il modo più semplice è prendere un progetto come "base", da lì creare un branch e poi copiare fisicamente i file in modo che si calcoli lui le differenze. Questo però ti fa perdere la storia dei commit, e nel branch avrai un singolo commit con tutto dentro (a meno che non committi gruppi di file un po' alla volta). Bye.
Re: [OT - di nuovo] consiglio su uso di git.
Il giorno lun 13 ago 2018 alle ore 11:21 Gollum1 ha scritto: > > lo so... sto facendo un bel po' di confusione, spero di dipanare al > più presto questa nebbia che mi ritrovo davanti agli occhi > > Mi sto studiando la documentazione sul sito di git, spero di riuscire a dipanare la nebbia... GRAZIE. Byez -- Gollum1 - http://www.gollumone.it Tesoro, dov'é il mio teoro...
Re: [OT - di nuovo] consiglio su uso di git.
Il giorno lun 13 ago 2018 alle ore 10:36 Alessandro Pellizzari ha scritto: > > On 12/08/18 17:10, Gollum1 wrote: > > > vado su uno dei tre repository locali, e lo aggancio come remote al > > repository locale, e ci paccio un push... a quel punto ho il > > repository locale con tutti i commit del primo dei repository locali > > vecchi... faccio così anche per gli altri due, committando di volta in > > volta, e così facendo dovrebbe fare anche i merge, quando faccio i > > push da ogni repository vecchio... oppure sto sbagliando ancora la > > prospettiva? > > Provo a buttare giù una soluzione. > Grazie Alessandro, mi tengo la tua mail da parte, che appena comincio a fare questo lavoro, la riprendo e me la studio... Inizialmente avevo optato per tenere tutto su bitbucket (tutte e due i repository), per il fatto che bitbucket mi permette di tenere privato il repository. Purtroppo insorgono due problemi non indifferenti: Per fare in modo gli utenti possano prelevare i file, sono obbligato a farli iscrivere e bitbucket, il che potrebbe anche essere fastidioso. Il secondo problema, ancora più invalidante, è che la versione "gratuita" di gestione del repository privato, mi permette di far accedere solo 5 persone. Constatando che il voler tenere privato il repository, non si dimostra poi una gran soluzione (semplicemente perché, una volta che hanno in mano la loro copia, nulla impedisce ai miei studenti di mandare in giro tutta la mia documentazione), me ne faccio una ragione ed uso un repositry pubblico (github o bitbucket a questo punto è indifferente). Con questa considerazione, diventa ideale la procedura che mi hai descritto. Negli ultimi post, mi sono trovato invece con un ulteriore problema (non è lo stesso progetto, ma parliamo sempre di git). Ho eliminato e rifatto il repository su bitbucket del mio progetto (repository privato, visto che ci lavoro solo io, e non devo distribuirlo). Mi trovo con tre versioni locali del repository originale, che vorrei reinserire nel nuovo repository (più che altro, per inserire eventuali modifiche rimaste disperse nei veri repository, altrimenti mi basterebbe copiare spudoratamente i file dall'ultimo, e avrei anche come effetto un rebase del repository). quindi la situazione è l'attuale: 1) un repository nuovo di pacca e completamente vuoto su bitbucket (privato). 2) un clone locale del repository di bitbucket (anche questo vuoto) 3) tre repository locali, copie in tempi diversi del repository originale, vecchio (potrebbero anche aumentare, se spazzolando i vari computer su cui lavoravo al progetto, dovessi trovare ulteriori repository dispersi). l'idea che mi è venuto, è quello di spostare tutti questi repository su questo computer, entrare in ogni repository vecchio, e mettere come suo remote il nuovo repository locale, fare un add dei file ed un commit, per poi procedere ad un push verso il repository locale. Il fatto è che non so come si comporta il repository locale con tutti questi commit, ad un certo punto è come se fossero diversi sviluppatori che lavorano contemporaneamente allo stesso progetto, quindi ad un certo punto, quiando sul repository principale faccio il commit per mandarlo su bitbucket, dovrebbe fare il merge dei vari commit arrivati (e questa cosa mi spaventa un po', non avendola mai gestita). non dovrebbe essere nulla di trascendentale, ma sono un po' in ansia (spero di non perdere nulla del mio progetto). mi ricordo anche che uno dei veri repository aveva anche dei file in stages (o come cavolo si chiama), come mi devo comportare con questi? spostarli in un branch a parte e poi committare l'intero branch? (presumo che se non faccio nulla, questi rimangono sempre nella versione locale, senza mai essere esportata sul repository remoto... lo so... sto facendo un bel po' di confusione, spero di dipanare al più presto questa nebbia che mi ritrovo davanti agli occhi Grazie di tutto... Byez -- Byez -- Gollum1 - http://www.gollumone.it Tesoro, dov'é il mio teoro...
Re: [OT - di nuovo] consiglio su uso di git.
On 12/08/18 17:10, Gollum1 wrote:
> vado su uno dei tre repository locali, e lo aggancio come remote al
> repository locale, e ci paccio un push... a quel punto ho il
> repository locale con tutti i commit del primo dei repository locali
> vecchi... faccio così anche per gli altri due, committando di volta in
> volta, e così facendo dovrebbe fare anche i merge, quando faccio i
> push da ogni repository vecchio... oppure sto sbagliando ancora la
> prospettiva?
Provo a buttare giù una soluzione.
Crei una cartella in locale, la trasformi in un git repo (git init).
Registri lo stesso progetto su github e su bitbucket. Aggiungi i due
remote al progetto locale:
git remote add origin ssh://bitbucket.org/...
git remote add public ssh://github.com/...
Decidi di usare bitbubket come "repo di sviluppo" e github per le
release pubbliche.
git checkout master # non dovrebbe fare niente perché ci sei già
git push -u origin master # collega master locale a master su bitbucket
git checkout -b public # crea un nuovo branch "public"
git push -u public master
# collega il branch public locale al branch master su gtihub
git checkout master # torna a master
Con questo si conclude il setup iniziale. Da qui in avanti parliamo di
sviluppo corrente.
git checkout nuova-feature # crea un nuovo branch per lo sviluppo
loop {
edit file
git commit file
}
git checkout master # torna in master
git merge nuova-feature #merge delle modifiche in master
git push # pusha master su bitbucket
git checkout nuova-feature # torna al branch
git rebase -i public
Ti apre un editor con la lista dei commit, ognuno con "pick" di fronte.
Cambia tutti i "pick" TRANNE IL PRIMO con "squash" (o solo "s", mi pare.
Te lo dice lui in un commento mentre fai l'edit).
Puoi anche cambiare il commit message del primo, se vuoi.
Salva e chiudi.
git checkout public # torna al branch public
git merge nuova-feature # merge del branch squashato
git push # pusha le modifiche su github
C'è un po' di lavoro manuale da fare ogni volta, e devi stare attento a
non fare casini coi branch, ma se ci sviluppi solo tu è fattibile.
Ricordati che git è un sistema distribuito. Ogni branch può avere
collegati zero o più remote totalmente distinti dagli altri.
O può anche non avere remote collegati, e decidi di volta in volta dove
pushare le modifiche (il che può portare a casini enormi :)
Bye.
Re: [OT - di nuovo] consiglio su uso di git.
Il 09/08/2018 20:16, Gollum1 ha scritto: se io ricreo il repository su bitbucket (questa è la mia intenzione a prescindere), posso entrare in ogni repository, aggiungere bitbucket come remote, e caricarli tutti su di esso? le parti in comune dei vari commit verrebbero messe insieme, e quindi avrei una sola versione delle varie commit? le parti non commitate inizialmente, posso farle andare su vari branch in modo che poi facendo una analisi dei soli file modificati, riesca a ricostruire il mio branch di sviluppo principale? eventualmente con i merge del caso? è possibile e affidabile un approccio del genere? Devi fare il contrario: aggiungere gli altri repo al tuo clone di bitbucket; da lì puoi vedere le differenze, fare i merge e pusharli verso il repo definitivo. Mandi. Paolo
Re: [OT - di nuovo] consiglio su uso di git.
Il giorno dom 12 ago 2018 alle ore 17:28 Gollum1 ha scritto: > > Il 12 agosto 2018 11:23:47 CEST, Paolo Miotto ha > scritto: > >Devi fare il contrario: aggiungere gli altri repo al tuo clone di > >bitbucket; da lì puoi vedere le differenze, fare i merge e pusharli > >verso il repo definitivo. > > > > vediamo se ho capito. > io ho rifatto il repository vuoto su bitbucket e l'ho clonato in locale, ci > copio dentro quello che credo che sia il più vecchio dei tre che ho a > disposizione, e ne faccio il commit su bitbucket. ci copio dentro il > successivo e faccio il nuovo commit... c'è qualcosa che non mi torna... come si comporterebbe invece il tutto, se io faccio il repository su bitbucket, e me lo porto in locale. vado su uno dei tre repository locali, e lo aggancio come remote al repository locale, e ci paccio un push... a quel punto ho il repository locale con tutti i commit del primo dei repository locali vecchi... faccio così anche per gli altri due, committando di volta in volta, e così facendo dovrebbe fare anche i merge, quando faccio i push da ogni repository vecchio... oppure sto sbagliando ancora la prospettiva? Byez -- Gollum1 - http://www.gollumone.it Tesoro, dov'é il mio teoro...
Re: [OT - di nuovo] consiglio su uso di git.
Il 12 agosto 2018 11:23:47 CEST, Paolo Miotto ha scritto: >Il 09/08/2018 20:16, Gollum1 ha scritto: >>> se io ricreo il repository su bitbucket (questa è la mia intenzione >a >>> prescindere), posso entrare in ogni repository, aggiungere bitbucket >>> come remote, e caricarli tutti su di esso? le parti in comune dei >vari >>> commit verrebbero messe insieme, e quindi avrei una sola versione >>> delle varie commit? le parti non commitate inizialmente, posso farle >>> andare su vari branch in modo che poi facendo una analisi dei soli >>> file modificati, riesca a ricostruire il mio branch di sviluppo >>> principale? eventualmente con i merge del caso? >>> >>> è possibile e affidabile un approccio del genere? > >Devi fare il contrario: aggiungere gli altri repo al tuo clone di >bitbucket; da lì puoi vedere le differenze, fare i merge e pusharli >verso il repo definitivo. > >Mandi. > >Paolo vediamo se ho capito. io ho rifatto il repository vuoto su bitbucket e l'ho clonato in locale, ci copio dentro quello che credo che sia il più vecchio dei tre che ho a disposizione, e ne faccio il commit su bitbucket. ci copio dentro il successivo e faccio il nuovo commit... c'è qualcosa che non mi torna... byez -- gollum1 Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità e gli errori, maledetto correttore automatico.
Re: [OT - di nuovo] consiglio su uso di git.
Il giorno gio 9 ago 2018 alle ore 18:18 Gollum1 ha scritto: > > > spostando invece il discorso più propriamente su git, mi trovo in una > situazione un po' diversa... > > avevo un repository su cui stavo facendo lo sviluppo di un mio > programmino, nel tempo ho copiato il repository in diverse posizioni, > e probabilmente qualcuno di questi ha avuto pure delle modifiche... > > per fare un po' di pulizia, ho deciso di cancellare il reposity > remoto, e di ricomniciare a ricaricare il materiale, ma dei repository > che mi ero salvato, non ho un riferimento di quello che era il > repository più aggiornato e non so neppure quale sia quello che ha > avuto modifiche rispetto all'originale. > > se io ricreo il repository su bitbucket (questa è la mia intenzione a > prescindere), posso entrare in ogni repository, aggiungere bitbucket > come remote, e caricarli tutti su di esso? le parti in comune dei vari > commit verrebbero messe insieme, e quindi avrei una sola versione > delle varie commit? le parti non commitate inizialmente, posso farle > andare su vari branch in modo che poi facendo una analisi dei soli > file modificati, riesca a ricostruire il mio branch di sviluppo > principale? eventualmente con i merge del caso? > > è possibile e affidabile un approccio del genere? guardando le date di alcuni file, nelle tre direcotry, posso dare una sequenza temporale alle stesse, quindi potrei individuare l'ultima trnauillamente, ma vorrei comunque reinserirle tutte e tre nel repository, seguendo la corretta sequenza, per recuperare le diverse parti successivamente, come mi consigliate di procedere ? Grazie -- Gollum1 - http://www.gollumone.it Tesoro, dov'é il mio teoro...
Re: [OT - di nuovo] consiglio su uso di git.
Il giorno lun 16 lug 2018 alle ore 10:46 Paolo Nicorelli ha scritto: > > On Sun, 15 Jul 2018 at 22:49, Gollum1 wrote: >> >> Il giorno sab 14 lug 2018 alle ore 08:39 Paolo Miotto >> ha scritto: >> > >> > Il 13/07/2018 22:53, Gollum1 ha scritto: >> > > Ho scelto bitbucket perché mi permette di fare il repository privato >> > > Però su bitbucket (account free) puoi avere, tra i tuoi collaboratori, fino > a 5 users > > ... che tradotto vuol dire che, a prescindere da quanti repo hai, puoi avere > fino 5 persone che hanno accesso a tuoi repo privati. > non avevo valutato questo aspetto... e non mi va bene... ho quindi deciso di usare comunque git per lo sviluppo, in modo da mantenere il versioning, ma invece di usare un secondo repository per la distribuzione, quando ritengo un file abbastanza completo, lo copio spudoratamente in dropbox, ed invio il link alla cartella di dropbox ai diversi utenti, sta a loro poi andare a vedere se ogni tanto ci sono aggiornamenti oppure no. Non è la soluzione ottimale, a meno che dropbox non preveda di avvertire da solo tutti gli utenti che hanno ricevuto il link che c'é stato un aggiornamento, e anche il discorso protezione, alla fin della fiera, credo che vada a decadere, perché mi sa che chiunque abbia il link riesca a scaricare i file, e non solo chi è stato esplicitamente invitato. (falso problema, visto che poi basta che uno lo abbia in mano, e lo distribuirà sicuremanete a tutti i suoi conoscenti). spostando invece il discorso più propriamente su git, mi trovo in una situazione un po' diversa... avevo un repository su cui stavo facendo lo sviluppo di un mio programmino, nel tempo ho copiato il repository in diverse posizioni, e probabilmente qualcuno di questi ha avuto pure delle modifiche... per fare un po' di pulizia, ho deciso di cancellare il reposity remoto, e di ricomniciare a ricaricare il materiale, ma dei repository che mi ero salvato, non ho un riferimento di quello che era il repository più aggiornato e non so neppure quale sia quello che ha avuto modifiche rispetto all'originale. se io ricreo il repository su bitbucket (questa è la mia intenzione a prescindere), posso entrare in ogni repository, aggiungere bitbucket come remote, e caricarli tutti su di esso? le parti in comune dei vari commit verrebbero messe insieme, e quindi avrei una sola versione delle varie commit? le parti non commitate inizialmente, posso farle andare su vari branch in modo che poi facendo una analisi dei soli file modificati, riesca a ricostruire il mio branch di sviluppo principale? eventualmente con i merge del caso? è possibile e affidabile un approccio del genere? Grazie. Byez -- Gollum1 - http://www.gollumone.it Tesoro, dov'é il mio teoro...
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
Re: [OT - di nuovo] consiglio su uso di git.
On Sun, 15 Jul 2018 at 22:49, Gollum1 wrote: > Il giorno sab 14 lug 2018 alle ore 08:39 Paolo Miotto > 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à. > > Però su bitbucket (account free) puoi avere, tra i tuoi collaboratori, fino a 5 users ... che tradotto vuol dire che, a prescindere da quanti repo hai, puoi avere fino 5 persone che hanno accesso a tuoi repo privati.
Re: [OT - di nuovo] consiglio su uso di git.
Il giorno sab 14 lug 2018 alle ore 08:39 Paolo Miotto 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 Tesoro, dov'é il mio teoro...
Re: [OT - di nuovo] consiglio su uso di git.
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). Se hai in vps puoi usare gitolite per consentire l'accesso al singolo branch senza dover usare 2 repo. 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. Setti il remote origin al repo completo, dove hai master e i feature branch. Crei un nuovo remote (public) che conterrà i branch che vuoi diffondere. git remote add public ssh://... Crei un nuovo branch (diciamo gruppo1) che userai per pubblicare la tua documentazione. git checkout -b corso1 Quindi fai il push di corso1 su public, impostandolo come upstream git push --set-upstream public corso1 a questo punto puoi andare avanti con i commit in master e feature branch, 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 git push public Sono andato un po' a memoria negli esempi, spero che siano tutti esatti, 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. -- Mandi. Paolo
[OT - di nuovo] consiglio su uso di git.
Visto che nella ML c'è chi ci vive con il lavoro di sviluppatore, forse riuscirete a darmi qualche consiglio su come procedere in questo caso. devo tenere dei corsi all'interno della mia azienda, e vorrei mettere il materiale che preparo su un reposository in bitbucket. Ho scelto bitbucket perché mi permette di fare il repository privato ed invitare di volta in volta gli studenti che partecipano, dando loro l'accesso al contenuto del repository. Purtroppo, la cosa che mi piace poco, è che, questo modo di fare, impone che, a seguito del mio invito, gli studenti debbano iscriversi a bitbucket (per fortuna non spamma nella mail del malcapitato). 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). Quello che pensavo di fare è quindi di fare due repository, uno per lo sviluppo, e uno per il rilascio. lato negativo (per modo di dire) è che sul mio pc, mi ritrovo le due cartelle che contengono materiale in due stadi diversi di sviluppo, e che devo di volta in volta copiare dal ramo di sviluppo nel ramo di distribuzione, quello che ritengo oramai stabile e pronto per essere distribuito. 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, che registra sui due repositori in un caso tutto il repository locale (nel repository di sviluppo) nell'altro caso solo un particolare branch (nel repository di distribuzione)... ok... NON HO CAPITO per nulla come questo debba essere gestito, come passo i file dal branch di sviluppo, e fissarli ad un dato momento dello sviluppo, dentro nel branch di distribuzione, e come metterci solo quel file, lasciando tutte le modifiche precedenti sul branch di sviluppo, relegando quindi nel branch di distribuizione solo le modifiche da una stabile alla stabile successiva. Come vedete, poche idee, e tutte ben confuse... se qualche anima pia è in grado di accendermi la lampadina per capire come e perché si debba usare un metodo piuttosto che un altro, ve ne sarei molto grato. Se non volete intasare la lista (che in questo periodo sta comunque languendo), anche se il discorso potrebbe essere interessante per tanti alltri, sono ben accette informazioni anche a livello privato. Grazie in anticipo a chiunque avrà pietà di me, e dei miei studenti. Byez -- Gollum1 - http://www.gollumone.it Tesoro, dov'é il mio teoro...
