Muchas veces nos pasa que por algún motivo perdemos gran parte del proyecto porque nos equivocamos con algo, porque la cagamos en algún lugar, o a veces simplemente tomamos un camino, nos damos cuenta que no es la solución y querémos volver el proyecto a un estado anterior. Github soluciona este problema y algunos otros más como el trabajo en equipo, permitiendo que cada uno trabaje su versión del proyecto y después se pueda fusionar todo.
INTRODUCCIÓN
La pregunta del millón antes de arrancar con algo que quizás no sepan para qué les va a servir: ¿Qué es GitHub?
Básicamente es un lugar donde podemos alojar proyectos, utilizando Git. Claramente la siguiente pregunta es… ¿Qué es Git? Es la herramienta que nos va a facilitar el control de versiones de nuestro proyecto. Este sistema va a llevar un control de los cambios que vamos haciendo en nuestro proyecto, sobre cada uno de los archivos, permitiéndonos trabajar en varias partes del proyecto y guardando cada uno de los cambios que hagamos, permitiéndonos volver a cualquier estado del proyecto que hayamos guardado previamente.
Esto nos permite separar el proyecto en features, y trabajarlas por separado en ramificaciones (branches), diferentes para después combinarlas en un único proyecto principal, lo que lo hace ideal y práctico para el trabajo en equipo. Es una herramienta muy usada en la gran mayoría de las empresas, al igual que muchos programas que tienen el mismo propósito.
Podemos mantener un historial de absolutamente todos los cambios hechos en el proyecto, junto con su autor, fechas en las que se hicieron y demás, y volver a cualquier estado anterior. Es, por así decirlo, como una especie de “máquina del tiempo”.
Una de las mejores cosas que tiene hoy en día es que… ES COMPLETAMENTE GRATUITO.
CREANDO UN PROYECTO EN GITHUB
Para empezar vamos tenemos que entrar a github.com y crearnos una cuenta, en caso de no tenerla. Voy a omitir la explicación de este paso, ya que si están en esta página imagino que habrán creado una cuenta miles de veces en muchísimos lugares.
Luego de estar logueados, vamos a crear nuestro primer proyecto. Para ello, hacemos click en el botón “NEW”, situado, al menos al momento de escribir esto, arriba a la izquierda:
Luego van a tener que completar un formulario, con los datos mínimos de creación de su proyecto. Estos son:
Empecemos a nombrarlos de a uno:
- Repository Name: Acá es donde ponen el nombre del repositorio. Este nombre debe ser único en cada cuenta que tengan. Estaría bien que represente el nombre en sí del proyecto de ustedes.
- Descripción: Un breve relato acerca de tu proyecto. Básicamente un resumen.
- Public o Private: Si seleccionamos público cualquier persona con o sin cuenta de git va a poder ver nuestro proyecto, acceder a él y a todo su contenido. Si es privado sólo nosotros y las personas que indiquemos que son parte de nuestro equipo (podemos invitar gente más tarde). Si el repositorio es público, esto no significa que cualquiera pueda editarlo. Pero si pueden verlo, pueden hacerse una copia, trabajar en él y después, con un permiso tuyo, pueden pasar cambios que hayan hecho en esa copia a tu repositorio.
- .gitignore: Git usa un archivo llamado “.gitignore” que sirve básicamente para indicar cuáles son los archivos que no queremos incluir en el repositorio. Esto es muy útil para esas cosas que cada programa genera automáticamente. Por ejemplo, la carpeta “Library” de Unity se genera automáticamente junto con todo su contenido. Y como dicha carpeta suele pesar incluso más que el proyecto entero, comúnmente no suele incorporarse al proyecto. Podemos indicarlo manualmente o podemos usar un template que Github tiene exclusivamente para Unity, que nos permite ignorar esa carpeta y un montón de archivos más que Unity genera de manera automática. Así, acotamos mucho el peso en el repositorio y no tenemos cambios tan seguidos, por la generación de dichos archivos. Si hacen click en el menú desplegable, pueden elegir el archivo “.gitignore” que más se adapte a sus proyectos, o ninguno si prefieren hacerlo a mano.
- Por último, la parte de “licence” es más que nada si quieren especificar un tipo de licencia para el uso de sus proyectos. Pueden no especificar ninguna o si quieren dar libre uso de él seleccionar MIT como tipo de licencia.
Y con esto ya tienen el proyecto en Github creado correctamente. Para este tutorial voy a crear el repositorio para guardar un proyecto en Unity, así voy a seleccionar el .gitignore llamado “Unity”. Como dije arriba, esto me va a ayudar a que no se suban al repositorio archivos que Unity genera automáticamente. Luego de hacer click en “Create repository“, vamos a ver la siguiente pantalla:
Van a ver una especie de "explorador de archivos" con todos los archivos que van formando parte de su repositorio. En principio, van a ver solamente un archivo, que sería el .gitignore, en este caso, el de Unity que yo seleccioné. El archivo contiene lo siguiente:
# This .gitignore file should be placed at the root of your Unity project directory # # Get latest from https://github.com/github/gitignore/blob/master/Unity.gitignore # /[Ll]ibrary/ /[Tt]emp/ /[Oo]bj/ /[Bb]uild/ /[Bb]uilds/ /[Ll]ogs/ /[Mm]emoryCaptures/ # Asset meta data should only be ignored when the corresponding asset is also ignored !/[Aa]ssets/**/*.meta # Uncomment this line if you wish to ignore the asset store tools plugin # /[Aa]ssets/AssetStoreTools* # Autogenerated Jetbrains Rider plugin [Aa]ssets/Plugins/Editor/JetBrains* # Visual Studio cache directory .vs/ # Gradle cache directory .gradle/ # Autogenerated VS/MD/Consulo solution and project files ExportedObj/ .consulo/ *.csproj *.unityproj *.sln *.suo *.tmp *.user *.userprefs *.pidb *.booproj *.svd *.pdb *.mdb *.opendb *.VC.db # Unity3D generated meta files *.pidb.meta *.pdb.meta *.mdb.meta # Unity3D generated file on crash reports sysinfo.txt # Builds *.apk *.unitypackage # Crashlytics generated file crashlytics-build.properties
Básicamente son instrucciones para que no se suban carpetas como "Library", "Temp", "Builds", etc, que son carpetas que suele generar Unity, o incluso carpetas que suelen generar los programadores para guardar determinadas cosas, cuyos nombres son más que nada nomenclaturas. También incluye líneas para ignorar cosas que crea Visual Studio y Rider, que son dos entornos de desarrollo también muy usados.
Una cosa MUY IMPORTANTE a tener en cuenta es que este archivo no le está diciéndo al repositorio que ignore esos archivos, sino al programa que utiliza Git.
DIFERENCIA ENTRE GIT Y GITHUB
La diferencia entre estas dos cosas debe quedar clara, ya que si bien se relacionan, no son lo mismo. Vamos a explicarlas por separado:
GIT
Git (pronunciado "guit"2) es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Su propósito es llevar registro de los cambios en archivos de computadora y coordinar el trabajo que varias personas realizan sobre archivos compartidos.
GITHUB
GitHub es una forja (plataforma de desarrollo colaborativo) para alojar proyectos utilizando el sistema de control de versiones Git. Se utiliza principalmente para la creación de código fuente de programas de ordenador. El software que opera GitHub fue escrito en Ruby on Rails. Desde enero de 2010, GitHub opera bajo el nombre de GitHub, Inc. Anteriormente era conocida como Logical Awesome LLC. El código de los proyectos alojados en GitHub se almacena típicamente de forma pública, aunque utilizando una cuenta de pago, también permite hospedar repositorios privados.
Esta es la diferencia, técnica y general, entre uno y el otro. Aunque la otra vez me pasaron un meme que lo explica bastante mejor:
Aclarado eso, a grandes rasgos, uno es el sistema y el otro el lugar donde alojamos las cosas producidas con ese sistema. De más esta decir que así como existen varios sistemas similares a Git, existen otras alternativas también para el alojamiento. Incluso hay personas que lo alojan en su propia página web (no es mi caso), o incluso en sus propias compus. Si ninguna de estas alternativas te viene mejor, la página oficial siempre es una buena opción.
Una de las cosas que a mi parecer es muy buena de Git es que al descargar una copia del proyecto, estás bajando el repositorio entero, con todos los cambios históricos que se hicieron. Eso quiere decir que si alguien de tus colaboradores rompe el proyecto o incluso el repositorio en la página de Github (algo poco común, pero puede pasar), cualquiera de las personas con una copia puede reconstruir el repositorio entero.