ho il mio bel progetto rails in locale con due rami:
master
sperimentale
faccio “git checkout sperimentale”
poi mi diverto a creare/modificare file all’interno del ramo…
finito lo smanettamento selvaggio decido che quanto ho appena fatto e’
un disastro e che potevo farlo diversamente…
(non ho ancora fatto “git add .” o “git commit -m ‘ho
aggiunto/modificato qualcosa’”)
c’e’ un modo per annullare tutte le modifiche effettuate senza
committare?
oppure sono costretto a fare il commit delle “modifiche selvaggie” e poi
fare un reverse?
nel caso debba fare un reverse (se si chiama cosi’…) come sarebbe il
comando per tornare al commit precedente?
Bho, su winzoz non funzia l’ultimo comando che mi hai passato, nel
senso, mi dice “HEAD is now at <messaggio dell’ultimo commit>”
e quindi sembra essere apposto…
ma facendo “git status” vedo ancora il file nuovo…
In generale, conviene sempre fare il commit e semmai tornare indietro?
Nel senso cosi’ tengo meglio traccia delle modifiche apportate al
progetto?
Oppure fare come abbiamo appena detto non e’ cosi’ grave, specialmente
se
e’ per sperimentare?
Bho, su winzoz non funzia l’ultimo comando che mi hai passato, nel
senso, mi dice “HEAD is now at <messaggio dell’ultimo commit>”
e quindi sembra essere apposto…
ma facendo “git status” vedo ancora il file nuovo…
perch ho scritto una minchiata
serve anche un git clean -df (i file untracked che non sono presenti
nell’index non vengono toccati nemeno con git reset).
In generale, conviene sempre fare il commit e semmai tornare indietro?
Nel senso cosi’ tengo meglio traccia delle modifiche apportate al progetto?
Oppure fare come abbiamo appena detto non e’ cosi’ grave, specialmente se
e’ per sperimentare?
[cut]
Come hai intuito te, dipende
E’ sempre meglio tenere le modifiche atomiche, in modo che ogni in
ogni commit sia ben chiaro lo scopo della modifica.
Se poi stai sviluppando una feature ti basta creare un altro branch in
cui inserire le tue modifiche.
Io eviterei i commit solo nel caso in cui la sperimentazione non si
protragga per tanto tempo/codice.
In ogni caso, imho, su git se lavori su un tuo branch separato meglio un
commit in pi che un commit in meno. Puoi infatti fondere commits molto
facilmente con git rebase -i (la condizione per che quel branch deve
essere un branch locale su cui lavori solo te), prima di fare il merge
del
tuo lavoro dentro a master.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.