Git: usa il ripristino o il checkout per annullare le modifiche effettuate?

Question

Git è uno strumento fenomenale, ma devo ancora avvolgere la mia mente sul modo migliore per annullare i cambiamenti imposti. Ecco la situazione.

Sono su un ramo e ho inviato diversi commit a GitHub. Da allora è stato deciso che sono andato troppo oltre nella tana del coniglio, e abbiamo bisogno di scartare molti dei commit che ho fatto e ricominciare da capo. Essenzialmente, ho bisogno di invertire tutti i commit spinti, indietro a uno precedente. Qui ci sono i due comandi che io penso sono appropriati

git revert # - creates a new commit that "undoes" the changes of one specific commit 
git checkout 'commit SHA' # - sets the head to that specific commit, wherein I will re-push to the repo, undoing my changes... I think 

Così, ho ragione? Devo eseguire un checkout git sul commit specifico su cui voglio tornare? O c'è qualcosa in questo processo contorto che non capisco?

Grazie.

Answer 1

Prova git reset: http://git-scm.com/docs/git-reset

Answer 2

Come Horia ha sottolineato correttamente avrete bisogno di reset git.

Checkout Git significa che si passa a un altro ramo o utilizzando il checkout -b è possibile creare un nuovo ramo e passare ad esso subito.

Answer 3

ci sono due scenari a seconda dello stato di quello che ti ha spinto:

• Nessuno ha usato il ramo spinto per nulla ancora. In tal caso, è possibile utilizzare git reset per forzare il ramo locale a un commit specifico e quindi è possibile git push il ramo con un parametro --force.

• Se, tuttavia, c'è qualcuno che ha basato il suo lavoro sul ramo che ha spinto accidentalmente, non è possibile resettarlo, poiché baserà le sue modifiche su un ramo nel limbo. È qui che entra in gioco git revert. Registra una patch inversa annullando in modo efficace le modifiche precedenti. Il vantaggio qui è che altri possono basare il loro lavoro sul ramo con facilità.

La scelta del metodo dipende da come il repository è e per quanto tempo le patch accidentali sono state lassù. Se ci sono pochi sviluppatori, la comunicazione e una reset sono probabilmente la risposta. Ma se la cosa è vissuta per molto tempo, probabilmente è meglio tornare indietro, a meno che tu non voglia riscrivere l'intera storia!

Un altro modo per vederlo è questo: git revert è persistente mentre git reset/git push --force è una riscrittura distruttiva della cronologia. C'è un momento appropriato per entrambi.

Infine, quando mi addentro per seguire Alice nel buco del coniglio e indagare su ciò che sta oltre, di solito lo faccio su rami creati localmente. Quindi, se mi piacciono i cambiamenti, di solito li unisco in un ramo di test e li lascio girare un po 'sul ramo di test, prima di unirli a master. In questo modo eviti il ​​problema molto spesso. In breve, ho spesso 20-30 filiali locali, una per ogni funzione su cui sto lavorando. Tendono ad essere prima testati individualmente. Occasionalmente, creo un nuovo ramo test e unisco tutto in quel ramo e faccio tutti i test insieme. Per tenere traccia dei conflitti tra i rami, utilizzo git rerere. Il vantaggio è che posso decidere quando una funzionalità è abbastanza stabile da spingere agli altri.