16/12/2017 Git Creando nuestro primer repositorio en GitHub

Creando nuestro primer repositorio en GitHub

Una vez que tenemos claro qué es un remoto y queremos ponernos manos a la obra lo más fácil es optar por una de las tantas herramientas online que nos permiten crear un servidor de Git. Ya hemos dejado claro anteriormente que los nodos de Git son jerárquicamente iguales, sea mi ordenador, el de mi compañero de trabajo, el servidor del trabajo o el servidor de GitHub, pero cuando se crea un repositorio en GitHub se crea principalmente para que éste actúe de servidor y que sea a él a quien le enviemos código y de quien lo recibamos. ¡Vamos al lío!

Lo primero, lógicamente, es crearnos una cuenta de GitHub si todavía no tenemos una. Mal hecho, por otra parte, pero… Ahora que ya tenemos una cuenta, y que no explicaremos aquí cómo crearla porque es igual de fácil que en cualquier otro servicio online, en la parte derecha de la pantalla veremos un botón verde para añadir un nuevo repositorio.

Nuevo repositorio en GitHub

El próximo y último paso dentro de la web de GitHub viene en la siguiente ventana, en la que tendremos que rellenar los datos para crear un nuevo repositorio en GitHub.

Creando nuevo  repositorio en GitHub

En ella se nos pide un nombre de repositorio, si es público o privado (GitHub no permite repositorios privados con una cuenta estándar, así que vosotros no podréis elegirlo privado), y por último si queréis incluir un README (archivo en markdown en el que se escribe toda la información y ayuda acerca del proyecto), una licencia para el repositorio (todas las licencias son de código abierto, si no no tendría sentido que el código fuese público) y un archivo .gitignore lo cual es demasiado avanzado por ahora pero más adelante en un artículo de este curso explicaremos qué es esto. Básicamente, con que le deis un nombre al proyecto sería suficiente. En mi caso el repositorio se llamará test y por motivos obvios lo crearé privado.

Nuestro nuevo repositorio en GitHub

Y por último GitHub nos muestra los pasos que deberíamos seguir a continuación para enviar contenido a nuestro nuevo repositorio, que actualmente está creado pero vacío. Aseguraos de que en la parte resaltada seleccionáis el botón SSH.

$ echo "# test" >> README.md
$ git init
$ git add README.md
$ git commit -m "first commit"
$ git remote add origin git@github.com:fjpalacios/test.git
$ git push -u origin master

Explicación de todas estas líneas:

  1. Creamos un archivo markdown para el README cuyo único contenido es un titular con el nombre de nuestro peyecto (se puede y se debe mejorar, pero por ahora servirá).
  2. El comando git init ya os tendría que sonar: es con el que iniciamos un proyecto de Git (si habéis seguido todo el tutorial esto ya lo habréis hecho por lo que os podéis saltar este paso).
  3. git add ya sabemos que añade un archivo a la cola para que sea incluido en el próximo commit.
  4. Y aquí está el commit, si vais a subir un proyecto ya creado pues en lugar de first commit (porque no sería el primero realmente) podéis cambiar el mensaje del commit.
  5. Aquí viene la parte más interesante: con esta línea añadimos un nodo remoto a nuestro proyecto. Origin es el nombre que se le suele dar por defecto al nodo que actuará como servidor, pero si tenemos varios nodos remotos podríamos llamarle como quisiésemos, github por ejemplo. Y en cuanto a lo que advertimos antes de que seleccionáseis SSH se puede obseervar su cambio respecto a HTTPS en que el nodo que añadimos no es un enlace web sino SSH. Qué significa esto es quizá demasiado técnico y no es un de los objetivos de este curso que aprendáis esto, simplemente quedaos con que seleccionar SSH da menos problemas en el futuro que HTTPS.
  6. git push es el comando que utilizamos para indicarle a Git que queremos que envíe al remoto origin todos los cambios de la rama master que tenga pendientes. Lógicamente, si tuviésemos varios y en lugar de origin pusiésemos otro nodo enviaría esos commits a ese nodo; y si tuviésemos varias ramas y en vez de poner la rama master pusiésemos el nombre de otra rama enviaría sólo los cambios existentes en esa rama.
Counting objects: 3, done.
Writing objects: 100% (3/3), 870 bytes | 870.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:fjpalacios/test.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

Una vez ejecutados todos los comandos Git nos responderá con algo como lo que aparece en las líneas anteriores. Si ya teníais un repositorio previamente creado y sólo habéis añadido el nodo remoto y habéis enviado los commits es posible que el mensaje sea un poco diferente, pero en esencia es lo mismo y quiere decir que todo ha salido bien. Si ahora recargáis la página del repositorio en GitHub podréis confirmar que todo es correcto y que vuestros archivos están a salvo en GitHub.

Repositorio de GitHub creado correctamente

Y de esta forma tan sencilla es como hemos enviado nuestro primer archivo a nuestro nuevo repositorio alojado en un nodo remoto. En otro artículo veremos cómo podemos obtener cambios que nosotros (u otras personas) hayan hecho desde otras máquinas y los hayan enviado a GitHub pero que todavía no estén en nuestra máquina.

Y como siempre decimos en SargantanaCode: ¡nunca dejéis de programar!

¿Sed de conocimiento?

Este artículo forma parte del curso Domina Git desde cero. El anterior artículo de este curso es Introducción a los remotos en Git y el próximo es Clonando y obteniendo nuevos commits de un repositorio Git.

Javi Palacios

Javi Palacios

Editor

El primer día que programé supe que quería seguir haciéndolo durante el resto de mi vida. Compilando cosas en Linux desde 2003 y disfrutando de la estabilidad de macOS desde 2006. Amante de la tecnología y del software libre.

Nuevo comentario

Escribe tu nombre y correo electrónico para poder comentar, o inicia sesión para que estos campos se rellenen automáticamente.