¿Cómo hacer que Git Merge maneje cambios no confirmados en mi árbol de trabajo?

Un compañero de trabajo y yo estamos trabajando en la rama principal en este momento. Tengo un código en mi árbol de trabajo que no quiero confirmar (instrucciones de depuración y similares). Ahora si comete cambios en algunos de esos mismos archivos, no puedo fusionarlas:¿Cómo hacer que Git Merge maneje cambios no confirmados en mi árbol de trabajo?

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

Viniendo de un fondo de la subversión, yo estoy acostumbrado a tener mi árbol de trabajo se fusionó de forma automática cuando me tire cambios del repositorio y si hay conflictos, los resuelvo manualmente.

La forma más rápida que he encontrado para hacer esto en Git es:

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

Esencialmente, la eliminación de mis cambios no confirmados, haciendo la fusión y luego volver a aplicar los cambios. ¿Cómo puedo decir merge para fusionar automáticamente mi árbol de trabajo con los cambios que estoy tratando de incorporar?

Fuente

2009-05-02 Jeremy Huiskamp

¿Qué sucede si tiene conflictos de combinación? ¿Qué pasaría si tuvieras conflicto de fusión en archivos sucios (archivos que has modificado)? Vea también "Diversión para mantener los cambios locales" en el blog de Junio C Hamano (git maintainer): http://gitster.livejournal.com/29060.html –

Gracias por el enlace. Sin embargo, una vez más, la gran mayoría de las veces, espero que no haya conflictos o conflictos menores que no me moleste arreglar manualmente. Corro el mismo riesgo de conflicto si confío mis archivos sucios de todos modos, excepto que luego me tengo que tomar la molestia de no comprometerlos después. –

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

Por lo que puedo decir, lo mejor que puedes hacer es lo que ya tienes con git stash. También me parece extraño que Merge quiera tratar solo con árboles limpios.

Fuente

2009-05-02 00:35:41

Voy a poner esto en mi .bashrc: gm() { git stash; git merge $ @; git stash pop } Y luego espere a ver cuánto tiempo me toma morderme el culo de alguna manera. –

@jeremy: terminarás aplicando un alijo muy viejo un día :). me sucedió :). – reto

@reto: ¿Cómo sería eso? – Casebash

Olvídate de todo lo que has aprendido de la subversión.

Comprométase siempre antes de introducir cambios externos.

Imagine que tiene un árbol que funciona en su mayoría, tal vez no perfecto, pero está haciendo un progreso. Luego vas a hacer una fusión y el código que estás trayendo simplemente causó estragos (fue un error en sí mismo, demasiados conflictos para tratar, etc.). ¿No sería bueno si pudieras deshacer eso?

Si se compromete, puede hacerlo. Si no lo haces, vas a sufrir.

Recuerde: Lo que usted confirma no es tiene que es lo que empuja, pero lo que no compromete puede perder fácilmente.

Simplemente haga lo seguro y fácil y comprométase temprano y comprométase a menudo.

Fuente

2009-05-02 01:45:08 Dustin

Así que confirmo mis declaraciones de depuración y luego me fusiono. Luego realizo algunos cambios reales que deseo impulsar. ¿Cómo obtengo mis declaraciones de depuración, ahora que las cosas que quiero comprometer dependen de esa confirmación? –

Siempre puede revertir una confirmación previa usando el comando "revertir" –

Consideraré esta estrategia para cuando nuestro código realmente se vuelve lo suficientemente loco como para preocuparme por deshacerlo. Sin embargo, por ahora, creo que la versión 'escondite' sigue siendo reversible. Puedo volver a esconder, matar el commit de fusión y abrir el alijo de nuevo en cualquier otro commit que quiera. No me importa olvidar lo que he aprendido sobre la subversión, pero suena cuando hace algo mucho mejor que git, particularmente cuando se supone que git es tan bueno para fusionarse. –

No puede indicar git merge para fusionar los cambios en los archivos que tienen cambios con respecto a su repositorio local. Esto lo protege de perder sus cambios en aquellos momentos en los que una fusión sale mal.

Con el enfoque de CVS y SVN para la fusión, si no copió manualmente sus archivos antes de la actualización y los compiló al fusionarlos, tiene que volver a editarlos manualmente para volver a un buen estado.

Si confirma sus cambios o los esconde antes de realizar una fusión, todo es reversible. Si la fusión no funciona bien, puede probar varias formas de hacerlo funcionar e ir con la que mejor funciona.

Si realiza cambios experimentales o de depuración, puede usar git rebase para moverlos después de las confirmaciones que recibe a través del git merge para que sea más fácil deshacerse de ellos o evitar empujarlos a un repositorio accidentalmente.

Tenga en cuenta que usar git rebase en una rama que ha enviado a un repositorio compartido causará dolor a todos los que están sacando de ese repositorio.

Prefiero usar git stash en estos casos, pero solo lo uso si la fusión cambia los archivos que he editado y no confirmado.

Fuente

2010-01-22 14:05:03

¿De qué estás hablando? SVN realiza una copia de respaldo de tus archivos antes de fusionarse. Git es el C++ del control de versiones. Se siente orgulloso de ser demasiado complejo y complicado. – JohnPristine

Supongo que mi conocimiento de SVN está desactualizado. Git también evoluciona para ser más útil con el tiempo. Acabo de ver una charla sobre Gitless ayer, que actúa en repositorios de git, pero es mucho más fácil de usar cuando tienes cambios no confirmados y quieres fusionar o cambiar de ramas. –

¿Cómo hacer que Git Merge maneje cambios no confirmados en mi árbol de trabajo?

Respuesta

Cuestiones relacionadas