🎯 ¿Cansado de los anuncios?
Elimínalos ahora 🚀

En un proyecto para el cual no eres el mantenedor, generalmente es más fácil tener una rama como master siempre rastreando` origin / master` y hacer tu trabajo en ramas de tema que puedes descartar fácilmente si son rechazadas. Tener temas de trabajo aislados en las ramas temáticas también facilita la tarea de volver a establecer una base de trabajo si la punta del repositorio principal se ha movido mientras tanto y sus confirmaciones ya no se aplican limpiamente. Por ejemplo, si desea enviar un segundo tema de trabajo al proyecto, no continúe trabajando en la rama de tema que acaba de crear: vuelva a comenzar desde la rama master del repositorio principal:

$ git checkout -b featureB origin/master # (work) $ git commit $ git push myfork featureB # (email maintainer) $ git fetch origin

Ahora, cada uno de sus temas está contenido dentro de un silo, similar a una fila de parches, que puede volver a escribir, volver a establecer y modificar sin que los temas interfieran o se interrelacionen entre sí, de la siguiente manera:

Figure 17. Initial commit history with featureB work.

Digamos que el mantenedor del proyecto ha sacado otros parches y ha probado su primera rama, pero ya no se fusiona de manera limpia. En este caso, puede tratar de volver a establecer la base de esa rama sobre origin / master, resolver los conflictos del mantenedor y luego volver a enviar los cambios:

👉 Descargar el audiolibro GRATIS en Amazon
Reportar problema / Sugerencias