usar - git-- tags
Git: solo sube la confirmación más reciente a Github (3)
En mi repositorio de git local tengo muchos commits, que incluyen cadenas de conexión ''secretas'' :-)
No quiero esta historia en github cuando la coloco allí.
Esencialmente quiero impulsar todo lo que tengo, pero quiero deshacerme de una gran cantidad de historia.
Tal vez sería mejor correr en una rama para todos mis desarrolladores, y luego volver a fusionarme con el maestro antes de comprometerme ... entonces la historia de maestro será la confirmación que deseo.
He intentado ejecutar rebase:
git rebase –i HEAD~3
Eso fue 3 commits, y luego pude eliminar un commit.
Sin embargo, funcionó con el auto cherry-pick fallido, y se volvió bastante complejo.
Cualquier pensamiento muy apreciado ... no es gran cosa para la historia y comenzar de nuevo si esto se pone demasiado difícil :-)
Guión
Clonó un proyecto e hizo una cantidad ridícula de confirmaciones para una nueva característica, y ha llegado el momento de abrirla o compartirla para su revisión. ¡Y no quieres que nadie vea tu confusión!
La rama original era cloned_branch , tus commits desordenados estaban en la rama dev , y quieres publicar tu trabajo limpio en la rama public_branch .
Suponga que los siguientes commits:
En la rama cloned_branch :
SHA0: Implementado X e Y. (autor: authorA)
SHA1: Implementado Z. (autor: authorA)
SHA2: Implementado W. (autor: authorA)
dev rama dev y pulsaste algunos commits:
SHA3: tratando de implementar la función Q para trabajar ...
SHA4: mierda, no funciona
SHA5: ensuciado aún más! :(
SHA6: ¡¡FUNCIONA !!
SHA7: limpieza!
Pon todos estos cambios en una única confirmación en public_branch :
git checkout SHA2 -b public_branch # new branch at `authorA`''s last commit
git merge --squash SHA7 # squash commits up to your last one
git commit -m "Implemented Q (author:me)"
Resultado:
Las ramas cloned_branch y dev permanecen como antes, mientras que la rama public_branch contiene:
SHA0: Implementado X e Y. (autor: authorA)
SHA1: Implementado Z. (autor: authorA)
SHA2: Implementado W. (autor: authorA)
SHA8: Implementado Q. (autor: yo)
No tengo suficiente reputación para comentar, así que publicaré una respuesta.
Si tiene submódulos, un enfoque similar a la respuesta de Paschalis proporciona una alternativa más estable ( cherry-pick no tiene en cuenta los submódulos) y minimiza los conflictos (ninguno en mi caso).
Este es mi enfoque preferido:
git checkout OLDSHA -b temp
git merge --squash master
git commit -m "All my work"
Donde OLDSHA es el compromiso más antiguo, se siente seguro para ingresar al repositorio público y el master es la rama que contiene todo su trabajo.
Esto crea una nueva rama ( temp ), que "oculta" (aplastando) todo el historial entre OLDSHA y la confirmación más reciente en el master . El mensaje para el nuevo compromiso será "Todo mi trabajo".
Luego puede eliminar el maestro y hacer que la temperatura sea el nuevo maestro (antes de hacer esto, asegúrese de que el maestro haya sido enviado a otro repositorio o respaldado)
git branch -d master
git branch -m temp master
Y presiona un nuevo control remoto, manteniendo intacto tu viejo control remoto
git remote rm origin
git remote add origin NEW_URL
git push --set-upstream origin master
Puede ramificar su trabajo actual, rebobinar el maestro, luego seleccionar cuidadosamente el último compromiso de regreso al maestro:
git branch secret
git reset --hard HEAD~3
git cherry-pick secret
En fotos,
A--B--C--D--E (master)
después git branch secret :
A--B--C--D--E (master, secret)
después de git reset --hard HEAD~3 :
A--B (master) / C--D--E (secret)
después de git cherry-pick secret :
A--B--E'' (master) / C--D--E (secret)
Finalmente, si git checkout secret; git rebase master git checkout secret; git rebase master , puedes obtener:
A--B--E'' (master) / C--D (secret)