Fusionar el archivo en GIT

Question

Descargué el paquete Zip CakePHP 2.0 de su página de inicio hace algunas semanas y comencé a codificar un sitio web con él. Ahora quiero actualizarlo a CakePHP 2.0.4. Sé que puedo descargar el paquete similar y reemplazar los archivos manualmente, pero pensé que debería fusionar la versión de GitHub para salvarme los problemas en el futuro. Lo intenté

git remote add github git://github.com/cakephp/cakephp.git

y entonces

git merge tags/2.0.4

Pero no funcionó. Todos los archivos están en conflicto. Por ejemplo:

Auto-merging lib/Cake/View/Scaffolds/form.ctp
CONFLICT (add/add): Merge conflict in lib/Cake/View/Scaffolds/form.ctp

¿Puedes decirme cómo hacer esto correctamente? ¡Soy un novato en Git, CakePhp y MacOSX! Gracias.

Answer 1

Voy a suponer que descargaste CakePHP 2.0.0, lo desabroché y luego ejecutó algo como git init, git add ., git commit Para hacer un repositorio. Tal vez hiciste algunas ediciones además de eso (si no lo hiciste, simplemente tíralo, clone el repositorio de GitHub y trabaje a partir de eso).

Lo importante es que tienes un repositorio que comenzó en el Zipball.

Ahora, cuando agregó el control remoto de GitHub y se obtuvo, GitHub le advirtió brevemente "Advertencia: no se confirma común". Lo que eso significa es que no hay una raíz de confirmación entre el repositorio en GitHub y su repositorio local.

a1 -- b1 -- c1 -- d1 -- e1 -- f1        master

r1 -- s1 -- t1 -- u1 -- v1 -- w1        github/tags/2.0.4

Cuando va a fusionarse, no hay relación entre los dos repositorios. Los conflictos son porque ellos ambas cosas Parece agregar los mismos archivos con contenido diferente.

La forma más sencilla de esto es rebase Su trabajo sobre la etiqueta 2.0.4. Haces esto rebotando todo excepto La primera confirmación donde agregó el archivo zip. Digamos que su primer compromiso es A1 y su rama es maestra.

Primero, haz una etiqueta a tu maestro. Si algo sale terriblemente mal, puedes restaurar esa etiqueta.

git tag tmp/master master

Entonces haz el Rebase.

git rebase --onto tags/2.0.4 a1 master

Cada confirmación se reescribirá como un compromiso de la versión 2.0.4.

a1 -- b1 -- c1 -- d1 -- e1 -- f1     tmp/master

r1 -- s1 -- t1 -- u1 -- v1 -- w1     github/tags/2.0.4
                               \
                                - b2 - c2 - d2 - e2 - f2 - g2 - h2   master

Piense en un rebase como guardar cada compromiso como un parche y volver a aplicarlos a otra rama. Usted toma la diferencia entre A1 y B1 y lo compromete además de W1 haciendo un nuevo commit B2. Luego diff B1 vs C1 y confirme eso además de B1 haciendo C2. Y así.

Si su primera confirmación no fue el archivo zip inalterado, no todo se pierde. Puede usar el mismo procedimiento, pero debe recuperar ese primer trabajo. Primero, debe extraer una diferencia entre su primer confirmación y una limpia 2.0.0.

git diff tags/2.0.0 a1 > first_commit.patch

Luego haga una nueva rama en la etiqueta 2.0.4 para mantener su nuevo trabajo.

git checkout tags/2.0.4
git checkout -b newmaster

Aplicar y confirmar el parche.

git apply first_commit.patch
git commit -a

Ahora Newmaster contiene 2.0.4 más su primer trabajo.

Ahora rebase Maestro como antes, pero en la parte superior de Newmaster en lugar de directamente en 2.0.4.

git tag tmp/master master
git rebase --onto newmaster a1 master

Puedes eliminar el Newmaster.

git branch -d newmaster

PD: Todo esto se vuelve más claro si puede visualizar el repositorio. En OS X, Gitx (l) es una excelente manera de ver el repositorio.