[Doc] Best practice de Github

Desde que comence a trabajar o, por lo menos en la mayoria de estos, siempre usabamos el versionador de codigo o, como antes se llamaba usabamos TFS. Vamos no solo se usaba para el versionamiento del codigo, tambien se usaba para la administracion de proyecto, requerimientos, casos de prueba etc.

Ahora, ya ni se llama TFS, hay muchas herramientas y entre las más populares podemos encontrar DevOps, Github, etc. Antes era muy facil, te conectabas desde el Vs.Net a tu TFS y listo, pero ahora – por lo menos yo- trabajo con tecnologia git y, eso ha cambiado un poco. Exiten plugin que puedes descargar en tu Vs.Net y trabjar dandole clic derecho tales como https://www.visualsvn.com/visualsvn/

No prentendo explicar sobre estos repositorios ya que seguro hay mucha gente que tiene mucho más conocimiento que yo, pero si me gustaría compartir mi experiencia sobre algunas buenas practicas que he podido aprender.

Buenas practicas,

Entre ellas podemos encontrar:

1. Crear un branch

Cuando trabajas en un proyecto, vas a tener un montón de diferentes características o ideas en progreso en un momento dado – algunas de las cuales están listas para funcionar, y otras no. Branching existe para ayudarte a manejar este flujo de trabajo.

Cuando creas una rama en tu proyecto, estás creando un entorno donde puedes probar nuevas ideas. Los cambios que hagas en una rama no afectan a la rama maestra, por lo que eres libre de experimentar y confirmar los cambios, con la seguridad de que tu rama no se fusionará hasta que esté lista para ser revisada por alguien con quien estés colaborando.

1.1 Pro/Tip

Branching es un concepto central en Git, y todo el flujo de GitHub se basa en él. Sólo hay una regla: cualquier cosa en la rama maestra siempre es desplegable.

Por eso es muy importante que la nueva rama se cree a partir de la maestra cuando se trabaja en una característica o una corrección. El nombre de la rama debe ser descriptivo por ejemplo, create-plugin-contact, script-account, script-html-account-form, etc para que los demás puedan ver en qué se está trabajando.

2. Agregar Commits

Una vez que tu branch ha sido creada, es hora de empezar a hacer cambios. Cada vez que añades, editas o eliminas un archivo, estás haciendo un commit y añadiéndolo a tu rama. Este proceso de agregar commits  lleva un registro de tu progreso mientras trabajas en una rama de características.

Los commit también crean un historial transparente de tu trabajo que otros pueden seguir para entender lo que has hecho y por qué. Cada commit tiene un mensaje asociado, que es una descripción que explica por qué se hizo un cambio en particular. Además, cada commit se considera una unidad de cambio independiente. Esto te permite retroceder los cambios si se encuentra un error, o si decides ir en una dirección diferente.

2.1 Pro/Tip

Los mensajes del commit son importantes –o muy importantes-, sobre todo porque Git hace un seguimiento de tus cambios y los muestra como commits  una vez que se envían al servidor. Escribiendo mensajes de confirmación claros, puedes hacer que sea más fácil para otras personas seguirlos y dar su opinión.

3. Abrir un Pull Request

los pull request inician la discusión sobre los commits. Debido a que están estrechamente integradas con el repositorio subyacente de Git, cualquiera puede ver exactamente qué cambios se fusionarían si aceptan tu petición.

Puedes abrir una Pull Request en cualquier momento del proceso de desarrollo: cuando tienes poco o ningún código pero quieres compartir algunas capturas de pantalla o ideas generales, cuando estás atascado y necesitas ayuda o consejo, o cuando estás listo para que alguien revise tu trabajo. Usando el sistema @mention de GitHub en tu mensaje “Pull Request”, puedes pedir comentarios de personas o equipos específicos, ya sea que estén al final del pasillo o al otro lado del mundo.

3.1 Pro/Tip
Las solicitudes de extracción son útiles para contribuir a los proyectos de código abierto y para gestionar los cambios en los depósitos compartidos Si está usando un Modelo de Repositorio Compartido, las Solicitudes Pull ayudan a iniciar la revisión del código y la conversación sobre los cambios propuestos antes de que se fusionen en la rama maestra.

4. Discuta y revise su código

Una vez que se ha abierto una solicitud de extracción, la persona o el equipo que revisa sus cambios puede tener preguntas o comentarios. Tal vez el estilo de codificación no coincide con las directrices del proyecto, al cambio le faltan las pruebas de unidad, o tal vez todo se ve muy bien y los accesorios están en orden. Los Pull Requests están diseñados para animar y capturar este tipo de conversación.

También puede continuar empujando a su rama a la luz de la discusión y la retroalimentación acerca de sus compromisos. Si alguien comenta que has olvidado hacer algo o si hay un error en el código, puedes arreglarlo en tu rama y empujar el cambio. GitHub mostrará tus nuevas confirmaciones y cualquier comentario adicional que puedas recibir en la vista de solicitud de extracción unificada.

4.1 Pro/Tip

Los comentarios de la solicitud de extracción están escritos en Markdown, así que puedes incrustar imágenes y emoji, usar bloques de texto preformateados y otros formatos ligeros.

5. Deploy

Con GitHub, puedes desplegarte desde una sucursal para las pruebas finales en producción antes de fusionarte con el maestro.

Una vez que su solicitud de extracción ha sido revisada y la rama pasa sus pruebas, puede desplegar sus cambios para verificarlos en producción. Si tu rama causa problemas, puedes hacerla retroceder desplegando el master existente en producción.

6. Merge

Ahora que sus cambios han sido verificados en la producción, es hora de fusionar su código en la rama master.

Una vez fusionados, las Solicitudes de extracción conservan un registro de los cambios históricos de su código. Debido a que se pueden buscar, permiten a cualquiera retroceder en el tiempo para entender por qué y cómo se tomó una decisión.

6.1 Pro/Tip

Al incorporar ciertas palabras clave en el texto de su Solicitud de extracción, puede asociar los problemas con el código. Cuando tu Solicitud de extracción se fusiona, los temas relacionados también se cierran. Por ejemplo, al introducir la frase Cierra #32 se cerraría el problema número 32 en el repositorio. Para obtener más información, consulte nuestro artículo de ayuda.

Update

Algo que me va bien al momento de subir, es crear un gitignore. Puedes crear un archivo .gitignore en el directorio raíz de tu repositorio para indicarle a Git qué archivos y directorios debe ignorar cuando hagas un commit. Para compartir las reglas de ignorar con otros usuarios que clonen el repositorio, confirma el archivo .gitignore en tu repositorio.

GitHub mantiene una lista oficial de archivos .gitignore recomendados para muchos sistemas operativos, entornos e idiomas populares en el repositorio público de github/gitignore. También puedes usar gitignore.io para crear un archivo .gitignore para tu sistema operativo, lenguaje de programación o IDE. Para obtener más información, consulte “github/gitignore” y el sitio “gitignore.io”.

Espero que estas practicas que yo implemento les ayude en algo.

Salu2

Leave a Reply

Your email address will not be published. Required fields are marked *