Git, modifiche su un ramo

Community IT
1

Buongiorno a tutti,

vi illustro la mia situazione:

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?

2

2011/12/7 Luca B. [email protected]:

Ciao

[cut]

c’e’ un modo per annullare tutte le modifiche effettuate senza
committare?

git checkout path/to/file

se sei sicuro di voler annullare tutte le modifiche fatte nel branch
locale e non ancora committate puoi eseguire direttamente:

git checkout -f

[cut]

Maurizio

3

2011/12/7 maurizio de magnis [email protected]

git checkout -f

Se hai anche creato dei file git checkout -f non basta per riportarti
allo
stato dell’ultimo commit: dovrai utilizzare git reset --hard HEAD.

Ciao
Stefano

4

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…

(ripeto, forse è colpa di win…)

5

Funziona! Grazie mille, so che era una cavolata ma per me ruby, rails,
git… e’ tutto un mondo nuovo T_T

Il giorno 07 dicembre 2011 11:02, maurizio de magnis <
[email protected]> ha scritto:

6

grazie! Ora e’ perfetto! :smiley:

Per concludere farei due considerazioni al volo:

  • 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?

Il giorno 07 dicembre 2011 11:36, Stefano P.
<[email protected]

ha scritto:

7

2011/12/7 Luca B. [email protected]

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 :slight_smile:

serve anche un git clean -df (i file untracked che non sono presenti
nell’index non vengono toccati nemeno con git reset).

8

2011/12/7 Luca B. [email protected]:
[cut]

  • 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 :slight_smile:

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.

9

2011/12/7 maurizio de magnis [email protected]

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.