2010-08-05 12 views
9

Viniendo de un fondo de svn: casi nunca se ramificó, debido a la (falta de) velocidad de conmutación y la hora o más que tardó en fusionar las ramas en el tronco. A veces, si necesitaba solucionar un problema en un sitio web, hacía el cambio en el enlace (que viviría junto con los cambios previos o las nuevas características) y luego iba a ese archivo y simplemente hacía "svn up path/to/filename "y solo actualizaría ese archivo, solucionando el problema pero ahorrando el resto de los archivos.comprensión git cherry-pick

Conceptualmente, esto no parece posible en git (o necesario); ¿Es la organización estructurada y las confirmaciones agrupadas que permiten la selección de cerezas? Entonces, ¿podría cambiar un área específica del sitio y comprometerlo como un grupo en lugar de hacer cómo trabajo con svn, y dedicarme a un día de trabajo y tocar los archivos de todo el lote al mismo tiempo?

Respuesta

10

Lo que probablemente quiera hacer en este caso es crear una nueva rama para su revisión, que se bifurque del ancestro común de todas las ramas que necesitarán la solución. Por ejemplo, suponga que tiene un par de lanzamientos mantenido junto con su desarrollo actual:

- X - o - o - o - o - o - o - o - o - o (master) 
    \      \ 
    o - o - o (release A) o - o (release B) 

Si necesita hacer una revisión que se aplicará a ambos comunicados, crear una rama a partir de la etiqueta X. cometer Commit su revisión , luego fusiona esa rama en las tres ramas.

Puede elegir, pero aquí hay una buena regla acerca de cuándo elegir: no. El único caso en el que querrá seleccionar cuidadosamente es cuando ha manejado mal sus sucursales. En este caso, eso podría significar que ha realizado el arreglo en el maestro en lugar de ramificarlo adecuadamente desde un punto anterior, y la gente ya ha retirado las actualizaciones al maestro, por lo que no puede cambiarlo. Tendría que elegir cuidadosamente para obtenerlo en las dos ramas de lanzamiento. Pero, por supuesto, en primer lugar, debes administrar tus ramas y nunca tendrás que elegirlas. (Sí, todavía sucederá a veces, así es la vida.)

+0

eso es increíble. Acabo de jugar con algunas cosas de "git branch foo old-merge-sha1" y eso es simplemente increíble. – Hans

+0

¿Es una mejor práctica crear un branch off master para "FeatureA" y luego ramificar "FeatureA" nuevamente para topic (s), fusionándolos en FeatureA cuando estén listos, pero sin tocar el master hasta que toda la FeatureA esté lista, cuando ¿combinaría FeatureA en master? Ahora mismo (en svn) si estoy trabajando en algo que va a tomar algunas semanas y necesito una revisión, hago lo que describí en mi pregunta (svn up path/to/filename) y luego continúo. La ramificación de Git parece ser una recomendación de "fusionar a menudo", pero ¿qué pasa si no quiero * que el master/trunk se toque hasta que esté listo, entonces puedo actualizar libremente el sitio web? – Hans

+2

@Hans: No se fusiona hasta que, bueno, es hora de fusionarse. Por lo general, el maestro es una rama estable actual, por lo que podría mover una característica parcial pero estable si así lo desea, pero en general solo debería fusionar cosas completas. Y es muy posible tener varias ramas estables de diferentes sabores, una para una descarga determinada (para su sitio web), una para pruebas estables actuales, una para pruebas inestables ... solo asegúrese de combinarse en la dirección correcta (tema -> característica -> maestra o inestable -> estable). – Cascabel