version-control - control - mercurial svn
¿Cómo envío un parche a otro desarrollador y evito conflictos de combinación? (4)
En SVN puedes simplemente hacer tus cambios antes de comprometer, canalizar la salida de svn diff a un archivo como tal
svn diff > mypatch.diff
a continuación, puede revertir los cambios y aplicar el parche en una fecha posterior usando
patch -p0 -i mypatch.diff
Como siempre, no aplique ciegamente parches a su código y siempre inspecciónelos primero.
También puede encontrar que el parche romperá su código fuente si los archivos fuente han cambiado significativamente desde que se tomó el parche.
Tampoco puede garantizar que no habrá conflictos de fusión cuando intente verificar el código.
¿Cómo obtengo un parche de una confirmación para enviarlo a otro desarrollador? ¿Y cómo puedo evitar un conflicto de fusión con este parche al fusionar nuestros árboles en una fecha posterior?
Si sabe cómo, explique cómo hacerlo en su VCS de elección, como subversión, git, Mercurial, bzr, etc.
Bzr maneja el envío de una "directiva de fusión", lo que significa que envía el parche para que la otra parte simplemente haga clic en "Aceptar" para fusionar y haya menos papeleo con el parche / aplicación, etc.
solo: $ bzr enviar -o mycode.patch
En Subversion no hay una buena manera de hacer esto. Sí, puedes usar svn diff + patch, pero esto solo pospondrá tus problemas hasta que te fusionarás y para entonces es probable que te hayas olvidado de él.
La forma en que lo harías en Subversion sería crear una rama, hacer la confirmación en la rama y pedir al destinatario del parche que cambie a la rama. Luego puede fusionar la rama de nuevo al tronco de la manera habitual.
En git puedes canalizar la salida de git-diff entre dos commits como este:
git diff fa1afe1 deadbeef > patch.diff
Envíe el patch.diff al desarrollador y déjelo que lo git-apply a su espacio de trabajo de la siguiente manera:
git apply patch.diff
Si el otro desarrollador ya tiene los commits disponibles en su repositorio, siempre podría canalizarlo sin fusionarse así:
git apply < git diff fa1afe1 deadbeef
A continuación, puede agregar y confirmar los cambios en el diff de la manera habitual .
Ahora aquí viene la parte interesante cuando tienes que unir el parche a la rama maestra (que es pública). Considere el siguiente árbol de revisión donde C* es el parche aplicado desde C en la rama principal:
A---B---C---D master, public/master
/
E---C*---F feature_foo
Puede usar git-rebase para actualizar la rama del tema (en este ejemplo, llamado feature_foo ) con su encabezado ascendente. Lo que eso significa es cuando escribes lo siguiente:
git rebase master feature_foo
Git reorganizará el árbol de revisión de esta manera y también aplicará el parche en sí mismo:
A---B---C---D master, public/master
/
E*---F* feature_foo
La fusión con la rama ascendente ahora será una fusión fácil y rápida. También verifique que los nuevos commits E* y F* funcionan como E y F previos respectivamente.
Puedes hacer lo mismo contra la sucursal de otro desarrollador usando los mismos pasos, pero en lugar de hacerlo en un repositorio público, obtendrás revisiones del repositorio del desarrollador. De esta forma, no tendrá que pedirle al otro desarrollador un parche si ya está disponible de acuerdo con lo que publicó en su repositorio.
Tenga en cuenta que nunca vuelva a establecer una base de datos en una sucursal pública porque el comando volverá a escribir el historial de git, que es algo que no desea hacer en las sucursales de las que depende la gente y creará un caos al fusionarse con repositorios remotos. Además, nunca olvides integrarte a menudo para que otros en tu equipo puedan participar de tus cambios.