2009-05-02 11 views
44

Un collega e io stiamo entrambi lavorando al master in questo momento. Ho un codice nel mio albero di lavoro che non voglio commettere (dichiarazioni di debug e simili). Ora, se commette modifiche a alcuni di questi stessi file, non posso unirli:Come fare git merge per gestire modifiche non vincolanti al mio albero di lavoro?

$ git merge origin/master 
Updating 1b8c5c6..eb44c23 
error: Entry 'blah.java' not uptodate. Cannot merge. 

Provenendo da un background di eversione, io sono abituato ad avere il mio albero di lavoro fuse automaticamente quando tiro cambiamenti dal repository e se ci sono conflitti, li risolvo manualmente.

Il modo più veloce che ho trovato per fare questo in git è:

$ git stash 
$ git merge origin/master 
$ git stash pop 

In sostanza, eliminando le mie modifiche non, a fare la fusione e poi ri-applicare le modifiche. Come posso dire di unire per unire automaticamente il mio albero di lavoro con le modifiche che sto tentando di inserire?

+3

Cosa succede se si verificano conflitti di unione? Cosa succederebbe se si unisse in conflitto con file sporchi (file modificati)? Vedere anche "Divertimento nel mantenere le modifiche locali in giro" nel blog Junio ​​C Hamano (git maintainer): http://gitster.livejournal.com/29060.html –

+0

Grazie per il link. Di nuovo però, nella stragrande maggioranza del tempo, non mi aspetto né conflitti né molto minori che non mi preoccupo di fissare a mano. Corro lo stesso rischio di conflitto se commetto comunque i miei file sporchi, salvo poi devo andare a prendermi la briga di rimandarli dopo. –

+0

Domanda correlata: http://stackoverflow.com/questions/18529206/when-do-i-need-to-do-git-pull-before-or-after-git-add-git-commit – leo9r

risposta

18

Per quanto ne so, il meglio che puoi fare è quello che hai già con git stash. Trovo anche strano che unire voglia trattare solo con alberi puliti.

+3

Inserirò questo nel mio .bashrc: gm() { git stash; git si fonde $ @; git stash pop } E poi aspetta di vedere quanto tempo ci vuole per mordermi in culo in qualche modo. –

+1

@jeremy: finirai per applicare uno stash molto vecchio un giorno :). mi è successo :). – reto

+0

@reto: Come accadrebbe? – Casebash

36

Dimentica tutto ciò che hai imparato da sovversione.

Eseguire sempre il commit prima di introdurre modifiche esterne.

Immagina di avere un albero per lo più funzionante, forse non perfetto, ma stai facendo dei progressi. Poi vai a fare una fusione e il codice che stai portando è stato devastato (era un bug da solo, troppi conflitti da affrontare, ecc ...). Non sarebbe bello se potessi semplicemente annullare quello?

Se si commette, è possibile. Se non lo fai, stai solo andando a soffrire.

Ricordare: ciò che si commette non è essere ciò che si spinge, ma ciò che non si commette si può facilmente perdere.

Basta fare la cosa facile e sicura e impegnarsi presto e impegnarsi spesso.

+1

Quindi impegno le mie dichiarazioni di debug e quindi mi unisco. Poi faccio dei veri cambiamenti che voglio spingere. Come faccio a ottenere le mie dichiarazioni di debug, ora che le cose che voglio commettere dipende da quel commit? –

+0

È sempre possibile ripristinare un commit precedente utilizzando il comando "ripristina" –

+1

Considererò questa strategia per quando il nostro codice diventa effettivamente abbastanza pazzo da dovermi preoccupare di annullarlo. Comunque, per ora, credo che la versione 'stash' sia ancora reversibile. Posso ri-memorizzare, uccidere il commit di fusione e far scattare di nuovo lo stash su qualsiasi altro commit che voglio. Non mi dispiace dimenticarmi di quello che ho imparato sulla sovversione, ma soffia quando fa qualcosa di molto meglio di git, in particolare quando si presume che git sia così bravo a fondere. –

2

Non è possibile specificare git merge di unire le modifiche sui file che presentano modifiche rispetto al proprio repository locale. Questo ti protegge dal perdere le tue modifiche in quei momenti in cui una fusione va male.

Con l'approccio di unione di CVS e SVN, se non hai copiato manualmente i tuoi file prima dell'aggiornamento e li ha codificati per l'unione, devi modificarli manualmente per tornare a uno stato buono.

Se si commettono le modifiche o le si memorizzano prima di eseguire un'unione, tutto è reversibile. Se l'unione non va bene, puoi provare diversi modi per farlo funzionare e andare con quello che funziona meglio.

Se si esegue il commit delle modifiche sperimentali o di debug, è possibile utilizzare git rebase per spostarle dopo i commit ricevuti tramite git merge per rendere più facile sbarazzarsi di esse o per evitare di inviarle accidentalmente a un repository.

Si noti che l'utilizzo di git rebase su un ramo che è stato trasferito su un repository condiviso causerà dolore a tutti coloro che stanno prelevando da quel repository.

Preferisco usare git stash in questi casi, ma lo uso solo se l'unione cambia i file che ho modificato e non commesso.

+0

Di cosa stai parlando? SVN esegue il backup dei file prima della fusione. Git è il C++ del controllo di versione. È orgoglioso di essere eccessivamente complesso e complicato. – JohnPristine

+0

Suppongo che la mia conoscenza di SVN non sia aggiornata. Git si evolve anche per diventare più utile nel tempo. Ho appena visto un discorso su Gitless ieri, che agisce su repository git ma è molto più facile da usare quando si apportano modifiche senza commit e si desidera unire o cambiare rami. –

Problemi correlati