[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
