Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
git, invece di litigare fate i buoni
9 views
Skip to first unread message
l...@email.it
May 24, 2012, 10:39:17 AM5/24/12
to
e suggeritemi un tutorial per deficienti, anche in inglese, perché
quelli che ho trovato in giro mi sono sembrati le solite cose scritte
per far vedere che le si sa ad altri che già le sanno.
quelli che ho trovato in giro mi sono sembrati le solite cose scritte
per far vedere che le si sa ad altri che già le sanno.
BS82
May 24, 2012, 10:46:12 AM5/24/12
to
fatti spiegare da rootkit ;-) tanto sono 4 comandi da impare.
rootkit
May 24, 2012, 12:15:44 PM5/24/12
to
l...@email.it ha scritto:
> e suggeritemi un tutorial per deficienti, anche in inglese, perché
> quelli che ho trovato in giro mi sono sembrati le solite cose scritte
> per far vedere che le si sa ad altri che già le sanno.
premesso che si presuppone i deficienti facciano lavori meno di concetto
:) la maggior parte dei tutorial parte dalla creazione dei repository fino
a spiegare come si lavora con i repo gerarchici. ora dipende un po' da
cosa ti aspetti, perché potresti volerlo usare gestendo tu i repository (e
allora ti devi smazzare un po' di teorie e workflow) oppure semplicemente
per appoggiarti a project hosting esterni come github (e in questo caso ti
basta navigare qui http://help.github.com/).
altrimenti c'è sempre la "madre di tutte le soluzioni" che bs82 certamente
ti vorrà illustrare, quando ha finito di fare lo spiritoso :P
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
> e suggeritemi un tutorial per deficienti, anche in inglese, perché
> quelli che ho trovato in giro mi sono sembrati le solite cose scritte
> per far vedere che le si sa ad altri che già le sanno.
:) la maggior parte dei tutorial parte dalla creazione dei repository fino
a spiegare come si lavora con i repo gerarchici. ora dipende un po' da
cosa ti aspetti, perché potresti volerlo usare gestendo tu i repository (e
allora ti devi smazzare un po' di teorie e workflow) oppure semplicemente
per appoggiarti a project hosting esterni come github (e in questo caso ti
basta navigare qui http://help.github.com/).
altrimenti c'è sempre la "madre di tutte le soluzioni" che bs82 certamente
ti vorrà illustrare, quando ha finito di fare lo spiritoso :P
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it
Andrea D'Amore
May 24, 2012, 2:05:51 PM5/24/12
to
In article
<39a5f882-1f65-4d42...@v24g2000vbx.googlegroups.com>,
Hai usato altri VCS? Questo cambia in bene o in male l'approccio che
puoi avere verso git.
[1] http://progit.org
<39a5f882-1f65-4d42...@v24g2000vbx.googlegroups.com>,
"l...@email.it" <l...@email.it> wrote:
> e suggeritemi un tutorial per deficienti, anche in inglese,
Vado col gitbook [1].
> e suggeritemi un tutorial per deficienti, anche in inglese,
Hai usato altri VCS? Questo cambia in bene o in male l'approccio che
puoi avere verso git.
[1] http://progit.org
Falco Stellare
May 24, 2012, 2:44:47 PM5/24/12
to
Il 24/05/2012 20:05, Andrea D'Amore ha scritto:
> [1] http://progit.org
Bello, epub sull'iPad, e via :-)
--
Falco Stellare
> [1] http://progit.org
Bello, epub sull'iPad, e via :-)
--
Falco Stellare
pigmalion
May 30, 2012, 1:53:52 PM5/30/12
to
On Thu, 24 May 2012 20:05:51 +0200, Andrea D'Amore
<anddam+groupsNOA...@brapi.net> wrote:
>Hai usato altri VCS? Questo cambia in bene o in male l'approccio che
>puoi avere verso git.
a questo punto mi accodo :)
<anddam+groupsNOA...@brapi.net> wrote:
>Hai usato altri VCS? Questo cambia in bene o in male l'approccio che
>puoi avere verso git.
ho usato per anni, ma anni, cvs per uso 'solitario'
server/repository alternativamente su linux o cygwin,
client da cli o da win usando tortoise cvs...
vedo che git è diventato molto popolare, ma non ci ho ancora capito
molto
da occhiate sparse, pare che ci sia un server centrale a pagamento o
free per alcuni casi...
ma è popolare perchè effettivamente lo usano a pagamento o sembra
popolare perchè sempre più spesso i progetti open source sono tenuti
li...
c'è qualcosa di interessante che occorre sapere?
di tanto in tanto bisogna aggiornarsi, ma in questo caso git è un
reale passo avanti o faccio bene a teneremi stretto il collaudato
sistema con cvs?
che, ripeto, uso in maniera solitaria (al massimo un potenziale altro
utente) per tenere traccia delle versioni e assicurarmi un archivio
dal quale recuperare backup et simili...
--
pigmalion at home
http://www.pigmalion.it/
Andrea D'Amore
May 30, 2012, 2:05:09 PM5/30/12
to
In article <95ncs7pgvkmc4rdvj...@4ax.com>,
società che offre un servizio basato su git, non è git.
Git è foss, ed è usato da alcuni grossi progetti, linux ad esempio e ora
Android.
> ma è popolare
È popolare perché alcuni nomi grossi hanno aiutato a diffonderlo facendo
da traino, perché alcuni servizi come github sono veramente comodi da
usare, perché è molto veloce con i file binari (a differenza di altri
VCS), e perché dicono che il merge sia abbastanza intelligente, più che
con svn per intenderci.
> c'è qualcosa di interessante che occorre sapere?
Fanno branching a manetta.
Io trovo più "naturale" usare mercurial perché condivide molto con
subversion.
Uso git raramente e ogni volta devo andarmi a cercare come funziona,
però ogni volta risolvo abbastanza semplicemente (cioè buona
documentazione) e mi dico "però è abbastanza logico". Solo che non lo
uso così di frequente da fissarmelo in testa.
pigmalion <pigm...@bigfoot.com> wrote:
> vedo che git è diventato molto popolare, ma non ci ho ancora capito
> molto
>
> da occhiate sparse, pare che ci sia un server centrale a pagamento o
> free per alcuni casi...
C'è github che ha acquistato una grande quantità di moto, ma è una
> vedo che git è diventato molto popolare, ma non ci ho ancora capito
> molto
>
> da occhiate sparse, pare che ci sia un server centrale a pagamento o
> free per alcuni casi...
società che offre un servizio basato su git, non è git.
Git è foss, ed è usato da alcuni grossi progetti, linux ad esempio e ora
Android.
> ma è popolare
È popolare perché alcuni nomi grossi hanno aiutato a diffonderlo facendo
da traino, perché alcuni servizi come github sono veramente comodi da
usare, perché è molto veloce con i file binari (a differenza di altri
VCS), e perché dicono che il merge sia abbastanza intelligente, più che
con svn per intenderci.
> c'è qualcosa di interessante che occorre sapere?
Io trovo più "naturale" usare mercurial perché condivide molto con
subversion.
Uso git raramente e ogni volta devo andarmi a cercare come funziona,
però ogni volta risolvo abbastanza semplicemente (cioè buona
documentazione) e mi dico "però è abbastanza logico". Solo che non lo
uso così di frequente da fissarmelo in testa.
pigmalion
May 30, 2012, 2:51:03 PM5/30/12
to
On Wed, 30 May 2012 20:05:09 +0200, Andrea D'Amore
<anddam+groupsNOA...@brapi.net> wrote:
grazie pe le info innanzitutto :)
>C'è github che ha acquistato una grande quantità di moto, ma è una
>società che offre un servizio basato su git, non è git.
eh, avevo intuito na mezza cosa...
confesso di non aver ancora fatto i compiti su git, al massimo l'ho
usato perchè mi serviva questo o quel pacchetto da scaricare...
ma quindi funziona in locale solamente?
cioè riesco a farmi i miei repository etc? e sono accessibili anche al
di fuori?
in questo thread decine di alternative ad un server per git, ma nessun
git server come naturale conseguenza del prodotto originale...
http://stackoverflow.com/questions/5507489/git-server-like-github
ma perchè tanto rumore per un server? cosa mi sfugge?
>> c'è qualcosa di interessante che occorre sapere?
>
>Fanno branching a manetta.
>
>Io trovo più "naturale" usare mercurial perché condivide molto con
>subversion.
>Uso git raramente e ogni volta devo andarmi a cercare come funziona,
>però ogni volta risolvo abbastanza semplicemente (cioè buona
>documentazione) e mi dico "però è abbastanza logico". Solo che non lo
>uso così di frequente da fissarmelo in testa.
a parte qualche branching, non ho mai osato oltre con cvs...
forse non ho vermaente bisogno di git... ma magari valeva la pena
portare quei miei semplici modi d'uso in questo nuovo prodotto.. anche
per rimanere al passo..
ma perchè poi, cvs e subversion sono gia morti?
<anddam+groupsNOA...@brapi.net> wrote:
grazie pe le info innanzitutto :)
>C'è github che ha acquistato una grande quantità di moto, ma è una
>società che offre un servizio basato su git, non è git.
confesso di non aver ancora fatto i compiti su git, al massimo l'ho
usato perchè mi serviva questo o quel pacchetto da scaricare...
ma quindi funziona in locale solamente?
cioè riesco a farmi i miei repository etc? e sono accessibili anche al
di fuori?
in questo thread decine di alternative ad un server per git, ma nessun
git server come naturale conseguenza del prodotto originale...
http://stackoverflow.com/questions/5507489/git-server-like-github
ma perchè tanto rumore per un server? cosa mi sfugge?
>> c'è qualcosa di interessante che occorre sapere?
>
>Fanno branching a manetta.
>
>Io trovo più "naturale" usare mercurial perché condivide molto con
>subversion.
>Uso git raramente e ogni volta devo andarmi a cercare come funziona,
>però ogni volta risolvo abbastanza semplicemente (cioè buona
>documentazione) e mi dico "però è abbastanza logico". Solo che non lo
>uso così di frequente da fissarmelo in testa.
forse non ho vermaente bisogno di git... ma magari valeva la pena
portare quei miei semplici modi d'uso in questo nuovo prodotto.. anche
per rimanere al passo..
ma perchè poi, cvs e subversion sono gia morti?
Andrea D'Amore
May 30, 2012, 3:12:51 PM5/30/12
to
In article <h5qcs7de2gvfncoqs...@4ax.com>,
> forse non ho vermaente bisogno di git...
Lo puoi sapere soltanto tu.
> ma magari valeva la pena portare quei miei semplici modi d'uso in
> questo nuovo prodotto.. anche per rimanere al passo..
Io lo suggerisco, trovo comodo il livello ulteriore della
decentralizzazione e quando devo salvare lo stato di una cartella in
genere uso un repository mercurial, due colpi di riga di comando e sei a
posto (tra l'altro uso DTerm).
pigmalion <pigm...@bigfoot.com> wrote:
> http://stackoverflow.com/questions/5507489/git-server-like-github
> ma perchè tanto rumore per un server?
Perché non vuole pagare per il servizio di github.
> http://stackoverflow.com/questions/5507489/git-server-like-github
> ma perchè tanto rumore per un server?
> forse non ho vermaente bisogno di git...
> ma magari valeva la pena portare quei miei semplici modi d'uso in
> questo nuovo prodotto.. anche per rimanere al passo..
decentralizzazione e quando devo salvare lo stato di una cartella in
genere uso un repository mercurial, due colpi di riga di comando e sei a
posto (tra l'altro uso DTerm).
Message has been deleted
rootkit
May 31, 2012, 3:17:03 AM5/31/12
to
On 30 Mag, 20:51, pigmalion <pigmal...@bigfoot.com> wrote:
> confesso di non aver ancora fatto i compiti su git, al massimo l'ho
> usato perchè mi serviva questo o quel pacchetto da scaricare...
>
> ma quindi funziona in locale solamente?
>
> cioè riesco a farmi i miei repository etc? e sono accessibili anche al
> di fuori?
funziona con una filosofia diversa dal cvs. in sostanza non è basato
> confesso di non aver ancora fatto i compiti su git, al massimo l'ho
> usato perchè mi serviva questo o quel pacchetto da scaricare...
>
> ma quindi funziona in locale solamente?
>
> cioè riesco a farmi i miei repository etc? e sono accessibili anche al
> di fuori?
su un concetto di repository centrale e working copy locale, bensì con
git lavori direttamente su un repository. quindi nella configurazione
più semplice tu hai un solo repo su cui lavori, fai commit, branches,
tags, etc...
ovviamente però in questa configurazione semplice puoi lavorare
esclusivamente da solo. se vuoi condividere il lavoro con almeno
un'altra persona occorre che tu abbia un repo comune, in quel caso
funziona che i vari componenti del team lavorano su dei cloni di
questo repo comune su cui periodicamente fanno il push delle loro
modifiche committate sul proprio repo.
ai repository remoti si può accedere nei modi più disparati ma
solitamente via ssh o http(s).
questo è in soldoni quello che si intende per repository gerarchico e
distribuito. in realtà si può fare assai di più dal punto di vista
organizzativo, come avere più repository remoti collegati o avere più
livelli di gerarchia (es. se devi convogliare il lavoro di più team e/
o vuoi separare il loro ruolo da quello dei committers).
> ma perchè poi, cvs e subversion sono gia morti?
delle limitazioni al modo di operare. limitazioni che nel tuo caso
potresti tranquillamente non riscontrare ma su cui vale la pena di
riflettere, se non altro per capire se si potrebbe lavorare in modo
diverso / più produttivo.
Daniele Orlandi
May 31, 2012, 9:09:13 AM5/31/12
to
rootkit wrote:
> considerato che lavorare con un vcs
> distribuito nel bene e nel male impone un certo cambiamento nel workflow,
Beh, una volta che hai impostato un git remote non c'è una gran differenza
nel workflow; c'è giusto da ricordarsi di fare un git push dopo il commit.
Ciao,
--
Daniele "Vihai" Orlandi
Bieco Illuminista #184213
> considerato che lavorare con un vcs
> distribuito nel bene e nel male impone un certo cambiamento nel workflow,
Beh, una volta che hai impostato un git remote non c'è una gran differenza
nel workflow; c'è giusto da ricordarsi di fare un git push dopo il commit.
Ciao,
--
Daniele "Vihai" Orlandi
Bieco Illuminista #184213
rootkit
May 31, 2012, 10:33:40 AM5/31/12
to
On 31 Mag, 15:09, Daniele Orlandi <dani...@orlandi.com> wrote:
> > considerato che lavorare con un vcs
> > distribuito nel bene e nel male impone un certo cambiamento nel workflow,
>
> Beh, una volta che hai impostato un git remote non c'è una gran differenza
> nel workflow; c'è giusto da ricordarsi di fare un git push dopo il commit.
chiaro volendo puoi anche non cambiare nulla e lavorare come se fossi
> > considerato che lavorare con un vcs
> > distribuito nel bene e nel male impone un certo cambiamento nel workflow,
>
> Beh, una volta che hai impostato un git remote non c'è una gran differenza
> nel workflow; c'è giusto da ricordarsi di fare un git push dopo il commit.
in modalità connessa, ma non è granché conveniente.
Daniele Orlandi
May 31, 2012, 11:29:10 AM5/31/12
to
rootkit wrote:
>
> chiaro volendo puoi anche non cambiare nulla e lavorare come se fossi
> in modalità connessa, ma non è granché conveniente.
Beh, finché si è in gruppi piccoli (4-5 persone) lo trovo il modo più
>
> chiaro volendo puoi anche non cambiare nulla e lavorare come se fossi
> in modalità connessa, ma non è granché conveniente.
efficiente.
Il bello è il *poter* cambiare workflow con lo stesso strumento quando/se
diviene necessario.
rootkit
May 31, 2012, 4:21:10 PM5/31/12
to
Il Thu, 31 May 2012 17:29:10 +0200, Daniele Orlandi ha scritto:
> rootkit wrote:
>>
>> chiaro volendo puoi anche non cambiare nulla e lavorare come se fossi
>> in modalità connessa, ma non è granché conveniente.
>
> Beh, finché si è in gruppi piccoli (4-5 persone) lo trovo il modo più
> efficiente.
non sono d'accordo. per esempio, la tecnica di lavorare su branch locali
> rootkit wrote:
>>
>> chiaro volendo puoi anche non cambiare nulla e lavorare come se fossi
>> in modalità connessa, ma non è granché conveniente.
>
> Beh, finché si è in gruppi piccoli (4-5 persone) lo trovo il modo più
> efficiente.
è molto efficiente anche lavorando in due e persino da solo una volta che
si è preso la mano. efficiente perché si possono gestire agevolmente più
modifiche e hotfix senza rischio di perdere la testa ne un byte di lavoro.
con svn ogni volta che devi fare un branch ci pensi non una ma dieci
volte solo per l'incubo dei merge, e comunque lo devi fare nel repository
centrale anche se magari è un branch che vive giusto il tempo della
modifica e non hai nessuna necessità di condivisione.
0 new messages