¿Cómo envío un parche a otro desarrollador y evito conflictos de fusión?

Question

¿Cómo obtengo un parche de un commit 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 hacer esto en su VCS de elección, como subversion, git, Mercurial, bzr o etc.

Answer 1

En git puede canalizar la salida de git-diff entre dos confirmaciones como esta:

git diff fa1afe1 deadbeef > patch.diff

Envíe el patch.diff al desarrollador y permítale git-apply en su espacio de trabajo de esta manera:

git apply patch.diff

Si el otro desarrollador ya tiene las confirmaciones disponibles en su repositorio, siempre podría canalizarlo sin fusionarse así:

git apply < git diff fa1afe1 deadbeef

Luego puede agregar y < a href = "http://www.kernel.org/pub/software/scm/git/docs/git-commit.html" rel = "noreferrer"> commit los cambios en diff de la forma habitual .

---

Ahora aquí viene la parte interesante cuando tiene que fusionar el parche de nuevo con 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 maestra:

A---B---C---D          master, public/master
     \
      E---C*---F       feature_foo

Puede usar git-rebase para actualizar el rama de tema (en este ejemplo llamada feature_foo ) con su cabeza 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í:

A---B---C---D          master, public/master
             \
              E*---F*  feature_foo

La fusión a la rama ascendente ahora será una combinación fácil de avance rápido. Compruebe también que las nuevas confirmaciones E * y F * funcionan como las anteriores E y F respectivamente.

Puede hacer lo mismo contra la sucursal de otro desarrollador utilizando los mismos pasos, pero en lugar de hacerlo en un repositorio público, será recuperando revisiones del repositorio del desarrollador. De esta manera, no tendrá que pedirle al otro desarrollador un parche si ya está disponible según lo que publicó en su repositorio.

Tenga en cuenta que nunca debe volver a crear una rama pública porque el comando reescribirá el historial de git, que es algo que no desea hacer en las ramas de las que depende la gente y creará un desastre al fusionarse con el control remoto repositorios Además, nunca olvide integrarse a menudo para que otros miembros de su equipo puedan participar de sus cambios.

Answer 2

En SVN, simplemente puede hacer sus cambios y luego, antes de confirmar, canalizar la salida del svn diff a un archivo como tal

svn diff > mypatch.diff

puede revertir sus cambios y aplicar el parche en una fecha posterior usando

patch -p0 -i mypatch.diff

Como siempre, no aplique parches a ciegas a su código e inspeccione siempre 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 ingresar el código.

Answer 3

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 hay menos vacíos con el parche / aplicación, etc.

solo:  $ bzr send -o mycode.patch

Answer 4

En Subversion no hay una buena manera de hacer esto. Sí, puede usar el parche svn diff +, pero esto solo pospondrá sus problemas hasta que vaya a fusionarse y para entonces es probable que lo haya olvidado.

La forma en que lo haría en Subversion sería crear una rama, realizar la confirmación en la rama y pedirle al destinatario del parche que cambie a la rama. Luego, puede volver a fusionar la rama con el tronco de la forma habitual.