Creamos una rama en el proyecto para nuestra funcionalidad, normalmente estas funcionalidades o tareas, se suelen asociar a un gestor de tareas (como por ejemplo Teambox, pivotaltracker, clockingit...), y suelen contener una id asi que la gente crea las ramas por ejemplo 34-add-users y asi cuando tienes muchas ramas, y en las cuales por ejemplo se podria repetir un nombre por el fallo de poner algo genérico como nombre de la rama, por ejemplo fixed-test, si quieres hacer referencia a una concreta eso es lo mejor para saber a que rama dirigirnos para revisar una tarea si nos hace falta.
Simplemente trabaja haciendo commits en esa rama hasta terminar, para hacer memoria recordar el flujo normal de de hacer commits y subirlos a una rama en concreto: -$ git add . -$ git commit -m git push servidor rama
Se suele primero mergear con master la tarea dado que pueden existir conflictos y no poderse desde la interface de github solventar los conflictos que pudieran existir previamente, esta practica si estamos en una funcionalidad muy gorda(no se suele recomendar que sean grandes), es mergear cada poco tiempo con master dado que puedes asumir pequeños conflictos en lugar de muchos al final, así que es una buena practica ir asumiendo los cambios de master en tu rama mientras desarrollas tu funcionalidad, los merge traían la rama indicada a la rama en la que se encuentran, recordar que siempre se trae master a la rama en la que trabajas o la rama en la que trabajas a master de eso se encarga el último paso: -$ git checkout master -$ git pull servidor master -$ git checkout rama -$ git merge master
Hay varias razones para hacer esto, una es para poder discutir con los compañeros de trabajo una funcionalidad, otra para compartir la experiencia, si alguien tiene que hacer eso mañana ha visto tu código o si alguien lo ha hecho antes te puede comentar una solución mejor así que o aprendes tu o aprende el resto, es fácil de localizar cuando algo se rompe, dado que puede se ve y también queda clara la decisión general el pull request también es una aceptación del equipo por un código, digamos que todos conocen lo que has hecho y tu conoces lo que opinan al respecto, los pull request se hacen desde github o también pueden ser desde bitbuken si lo tenemos alojado allí.
No se recomienda hacer push a master nunca o casi nunca, salvo ficheros de configuración específicos para puestas en producción o cosas muy pequeñas no relativas a funcionalidades, si se te quede un ; atrás en el pull request y lo quieres arreglar o abres o lanzas el pull request desde la misma rama o te añades otra con la solución y repites los 4 pasos. Tampoco es recomendable borrar commits igual que podemos querer ir ahora hacia un estado anterior luego podemos querer recuperar lo que antes queriamos borrar, es mejor usar reverse para evitar borrar información buena o mala una versión es una versión, y lo que antes era malo luego puede ser bueno.