Descargado 41 veces
Subido porJavier Latorre López-Villalta
Fundamentos de GIt y Github
Este documento ofrece una introducción a Git y GitHub. Explica qué es Git, cómo instalarlo, los comandos básicos como iniciar repositorios, añadir archivos, confirmar cambios y crear ramas. También cubre cómo crear una cuenta en GitHub, generar una clave SSH para conectar Git y GitHub, crear repositorios en GitHub y actualizarlos desde la línea de comandos. Incluye enlaces a recursos adicionales para aprender más sobre el control de versiones y estas herramientas.
Más contenido relacionado
La actualidad más candente
Similar a Fundamentos de GIt y Github
Fundamentos de GIt y Github
- 1. FUNDAMENTOS DE GIT YGITHUB Javier Latorre López-Villalta jlalovi@gmail.com 02/11/2015 IES Las Fuentezuelas www.ieslasfuentezuelas.com/ 2º DAA
- 2. 1. INTRODUCCIÓN GIT ¿Quées GIT? • Software de control de versiones. http://www.growingwiththeweb.com/2014/02/a-gentle-introduction-to-git.html
- 3. 1. INTRODUCCIÓN GIT ¿Quées GIT? • Diseñado por Linus Torvalds. http://tecnologia.elpais.com/tecnologia/2012/04/19/actualidad/1334852715_497713.html
- 4. 1. INTRODUCCIÓN GIT ¿Controlde versiones? http://videorrisa.blogspot.com.es/2014/01/control-z.html?spref=pi
- 5. 1. INTRODUCCIÓN GIT ¿Controlde versiones? http://www.growingwiththeweb.com/2014/02/a-gentle-introduction-to-git.html
- 6. 1. INTRODUCCIÓN GIT ¿Controlde versiones? http://svnbook.red-bean.com/es/1.0/images/ch02dia7.png Repositorio Estado /Versión
- 7.
- 8. 2. INSTALACIÓN GIT Enotros SOs https://git-scm.com/book/es/v1/Empezando-Instalando-Git
- 9. 2. INSTALACIÓN GIT Gitfor Windows GUI CMD BASH
- 10. 3. GIT: PRIMEROSCOMANDOS C:UsersNombre_Usuario Iniciamos Git Bash o Git CMD
- 11. 3. GIT: PRIMEROSCOMANDOS Compruebo que GIT funciona adecuadamente escribiendo ‘git’ Iniciamos Git Bash o Git CMD
- 12. 3. GIT: PRIMEROSCOMANDOS Asocio un correo electrónico y un nombre de usuario en el git BASH Asociando nuestros datos al git BASH Para asociar una cuenta de correo electrónico: Para asociar un nombre de usuario:
- 13. 3. GIT: PRIMEROSCOMANDOS Creo o copio un proyecto empezado en una ruta cualquiera Iniciamos repositorio de un proyecto Ejecuto el comando ‘git init’ en dentro de la carpeta que contiene el proyecto.
- 14. 3. GIT: PRIMEROSCOMANDOS Comprobar estado del repositorio ‘git status’ nos permite ver el estado del repositorio.
- 15. 3. GIT: PRIMEROSCOMANDOS Añadir archivos/carpetas al repo ‘git add’ nos permite añadir archivos/carpetas al repositorio.
- 16. 3. GIT: PRIMEROSCOMANDOS Confirmar cambios añadidos ‘git commit’ nos permite confirmar lo añadido al repositorio.
- 17. 3. GIT: PRIMEROSCOMANDOS Confirmar cambios añadidos 2
- 18. 3. GIT: PRIMEROSCOMANDOS Confirmar cambios añadidos 3
- 19. 3. GIT: PRIMEROSCOMANDOS Comprobar ‘commits’ en el repositorio ‘git log’ nos permite ver el historial de commits del repo.
- 20. 3. GIT: PRIMEROSCOMANDOS Crear ramas en el repositorio 1 ‘git branch’ y ‘git checkout’ nos permiten ver en qué rama estamos, y crear y cambiarnos de rama en el repositorio.
- 21. 3. GIT: PRIMEROSCOMANDOS Crear ramas en el repositorio 2
- 22. 3. GIT: PRIMEROSCOMANDOS Crear ramas en el repositorio 3
- 23. 3. GIT: PRIMEROSCOMANDOS Cambiar de estado y deshacer cambios ‘git checkout’ tiene otras utilidades interesantes:
- 24. 3. GIT: PRIMEROSCOMANDOS Cambiar de estado y deshacer cambios ‘git checkout’ tiene otras utilidades interesantes:
- 25. 3. GIT: PRIMEROSCOMANDOS Combinar cambios de dos ramas ‘git merge’ combina los ‘commits’ realizados en dos ramas:
- 26. 4. CREAR CUENTADE GITHUB ¿Qué es GitHub? GitHub es una plataforma de desarrollo colaborativo (también denominada forja) para alojar proyectos utilizando el sistema de control de versiones Git. https://es.wikipedia.org/wiki/GitHub
- 27. 4. CREAR CUENTADE GITHUB Creando una cuenta en GitHub https://github.com/join GitHub permite gestionar repositorios gratuitamente siempre y cuando sean públicos. Otras plataformas comoGitHub: BitBucket y GitLab.
- 28. 5. GENERAR UNACLAVE SSH ¿Qué es el SSH? SSH (Secure SHell, en español: intérprete de órdenes seguro) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. https://es.wikipedia.org/wiki/Secure_Shell Necesitamos configurar un SSH en nuestra máquina para poder acceder a la cuenta de GITHUB que hemos creado.
- 29. 5. GENERAR UNACLAVE SSH Generando la clave SSH De nuevo en la consola de git BASH, realizamos los siguientes pasos para crear una nueva clave SSH: Aparecerán las siguientes líneas: Introduce el siguiente comando, siendo el mail el vinculado en GitHub. En la siguiente se recomienda presionar ‘enter’ y mantener la ruta: Y en esta se introducirá el password y la confirmación del mismo:
- 30. 5. GENERAR UNACLAVE SSH Generando la clave SSH Si todo ha ido bien, te saldrá un nuevo mensaje como este: E introduciremos el siguiente comando para activar el ssh-agent: Obteniendo como respuesta algo parecido a esto: Y por último añadimos la clave SSH que creamos anteriormente al ssh-agent:
- 31. 5. GENERAR UNACLAVE SSH Añadiendo clave SSH a la cuenta de GitHub En la parte superior derecha, pinchamos sobre nuestro perfil, y en el menú desplegable seleccionamos “Settings” Y en la nueva ventana, en el menú de navegación izquierdo pulsamos sobre ‘SSH keys’
- 32. 5. GENERAR UNACLAVE SSH Añadiendo clave SSH a la cuenta de GitHub Nos dirigimos al archivo id_rsa.pub que hemos generado en los pasos anteriores y lo editamos para copiar todo su contenido sin espacios: El contenido puede ser algo parecido a esto: Al presionar sobre ‘Add SSH key’, nos aparece el siguiente cuadro en el que añadimos un título, pegamos el contenido copiado y aceptamos
- 33. 5. GENERAR UNACLAVE SSH Autentificar clave SSH a la cuenta de GitHub Por último, introducimos el siguiente comando en el Git Bash para establecer una primera conexión con Github desde nuestro GitBash: Y recibiremos los siguientes mensajes: Escribimos ‘yes’ en el último mensaje para confirmar que queremos realizar conexión y recibiremos este último mensaje:
- 34. 6. REPOSITORIOS ENGITHUB Creando repositorios en Github Una vez realizada toda esta configuración, ya podemos crear nuestros repositorios en GitHub y sincronizarlos con nuestro Git Bash. Para ello, en nuestra cuenta, nos dirigimos a ‘Repositories’ y pulsamos sobre ‘New’.
- 35. 6. REPOSITORIOS ENGITHUB Creando repositorios en Github En esta venta indicaremos el nombre del repositorio que estamos creando e introducimos una descripción. Si queremos utilizar la versión gratuita sólo puede ser público. Y el resto de opciones son autoexplicativas. Al finalizar presionamos ‘Create repository’.
- 36. 6. REPOSITORIOS ENGITHUB Creando repositorios en Github Al crear el repositorio, saldrá una ventana como esta, que nos indica varias opciones de lo que podemos hacer. Como ya hemos creado un repositorio en nuestro Git BASH, seguiremos la tercera opción.
- 37. 6. REPOSITORIOS ENGITHUB Enviando repositorio creado en Git Bash a Github Nos aseguramos de estar en la rama ‘master’ del proyecto que hemos estado haciendo de prueba e introducimos los comandos que nos han indicado al crear el repositorio en GitHub:
- 38. 6. REPOSITORIOS ENGITHUB Enviando repositorio creado en Git Bash a Github Comprobamos que en efecto se ha subido todo a nuestra cuenta de GitHub:
- 39. 6. REPOSITORIOS ENGITHUB Clonar un repositorio desde GitHub a nuestro Git Bash ‘git clone <url>’ nos permite descargar un repositorio de cualquier usuario a nuestro equipo a través de ‘Git Bash’. En el ejemplo siguiente, clonaré un repositorio de mi cuenta que no tengo descargado en este equipo. ¡Ojo con NO clonar o crear con ‘git init’ un repositorio dentro de otro! Este repositorio clonado a generado una carpeta nueva en este directorio lllamada ‘toggle’. Dentro de la carpeta toggle se podrá ver el proyecto completo con su configuración .git, sus commits, etc.
- 40. 7. ACTUALIZAR REPOSITORIOS Actualizarun repositorio almacenado en GitHub ‘git push’ nos permite actualizar los ‘commits’ realizados en local a través de nuestro Git BASH de la rama en la que nos encontramos:
- 41. 7. ACTUALIZAR REPOSITORIOS Actualizarun repositorio almacenado en GitHub ‘git push --all’ en caso de querer actualizar todas las ramas:
- 42. 7. ACTUALIZAR REPOSITORIOS Actualizarun repositorio en local a través de Git BASH ‘git pull’ nos permite actualizar en local los ‘commits’ que hayan realizado otros usuarios en GitHub (o aquellos que hayas hecho tú desde GitHub o desde otra máquina)
- 43. 8. WEBGRAFÍA https://librosweb.es/libro/pro_git/ ->Librosweb https://es.wikipedia.org/wiki/Git -> Wikipedia https://git-scm.com/docs/ -> Git reference http://www.growingwiththeweb.com/2014/02/a-gentle- introduction-to-git.html -> Growing with the web https://github.com/ -> GitHub https://git-for-windows.github.io/ -> Git for Windows
- 44. ¡Y RECORDAD! APARTIR DE AHORA… Javier Latorre López-Villalta jlalovi@gmail.com 02/11/2015 IES Las Fuentezuelas www.ieslasfuentezuelas.com/ 2º DAA
Notas del editor
- #2 Exposición realizada en IES las Fuentezuelas por Javier Latorre López-Villalta, alumno de 2ºDAA en el curso 2015/2016.
- #3 https://es.wikipedia.org/wiki/Git Git (pronunciado "guit" ) es un software de control de versiones diseñado por Linus Torvalds.
- #4 https://es.wikipedia.org/wiki/Git Git (pronunciado "guit" ) es un software de control de versiones diseñado por Linus Torvalds.
- #5 Anlalogía con el ‘control+z’ El control de versiones permite volver a estados anteriores de un proyecto. Estos estados en GIT se denominan ‘nodos’ o ‘versiones’, que son guardados cada vez que se realiza una acción de ‘commit’, y se puede volver a ellos si no se está satisfecho con los cambios realizados en los cambios posteriores. Todo esto tendrá más sentido una vez se empiece a poner en práctica GIT y GITHUB. https://librosweb.es/libro/pro_git/capitulo_1/acerca_del_control_de_versiones.html El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante. https://es.wikipedia.org/wiki/Control_de_versiones El control de versiones se realiza principalmente en la industria informática para controlar las distintas versiones del código fuente dando lugar a los sistemas de control de código fuente o SCM (siglas del inglés Source Code Management). Sin embargo, los mismos conceptos son aplicables a otros ámbitos como documentos, imágenes, sitios web, etc.
- #6 Desarrollo de proyectos en grupo El control de versiones permite trabajar a varias personas de manera colaborativa sobre un mismo proyecto a lo largo del tiempo. https://librosweb.es/libro/pro_git/capitulo_1/acerca_del_control_de_versiones.html El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante. https://es.wikipedia.org/wiki/Control_de_versiones El control de versiones se realiza principalmente en la industria informática para controlar las distintas versiones del código fuente dando lugar a los sistemas de control de código fuente o SCM (siglas del inglés Source Code Management). Sin embargo, los mismos conceptos son aplicables a otros ámbitos como documentos, imágenes, sitios web, etc.
- #7 Como veremos más adelante, GIT permite crear repositorios con el comando ‘git init’ o con el comando ‘git clone URL’. Cada repositorio contendrá las versiones o estados del proyecto que se vayan realizando a través del comando ‘git commit’ que también veremos más adelante. A GIT se le denomina ‘control de versiones’ precisamente por esta capacidad de crear repositorios que contienen versiones que pueden ser gestionadas a través de los comandos que proporciona GIT.
- #8 https://git-for-windows.github.io/ Existen varias maneras de instalar GIT en tu sistema, dependiendo del Sistema Operativo y de la configuración. En este caso seguiremos paso a paso como hacer una de las posibles instalaciones en Windows, a través de un paquete denominado ‘Git for Windows’, que permite la utilización de GIT por medio de la consola CMD, un emulador del BASH de linux o un GUI. El instalador, como en la mayoría de los instaladores, si te dan opciones de instalar o no instalar otros elementos, y no tienes claro qué conllevan dichas opciones, lo mejor suele ser dejarlo todo por defecto y continuar (a no ser que te estén pidiendo vender tu alma, instalar demos, spam y otras cosas que hay que rechazar por uso común, ya que ¡ojo!, no estoy instigando a pulsar el botón ‘siguiente’ frenéticamente sin leer cada apartado. ¡Qué somos informáticos, leñe!).
- #9 https://git-scm.com/book/es/v1/Empezando-Instalando-Git Como en este curso todos tenemos el SO de windows, nos centraremos en la instalación de ‘Git for Windows’, pero en caso de querer investigar más sobre cómo instalarlo en otros SOs, aquí va el enlace.
- #10 Una vez instalado el ‘Git for Windows’, podemos utilizar 3 tipos de interfaces para gestionar nuestros repositorios GIT: Git GUI. Interfaz gráfica sin uso de comandos GIT. Git BASH. Emulador de la consola de comandos de Linux. Git CMD. Consola de comandos de Windows. La exposición se centrará en cuáles son los comandos de GIT, por lo que se pueden utilizar BASH o CMD indistintamente, ya que los comandos GIT son iguales en ambos. Sólo cambiarían los comandos propios de cada consola (Ej. dir/ls, md/mkdir, notepad/vi, etc).
- #11 Git Bash y Git CMD se inician en la misma ruta, correspondiente a ‘C:\Users\Nombre_Usuario’. De aquí en adelante, continuaré con la interface Git Bash, ya que los comandos git serán los mismos.
- #12 Comprobación de que git está funcionando correctamente. Deben de aparecer un montón de instrucciones relacionadas con el uso de los comandos GIT.
- #13 Evidentemente hay que sustituir ‘tucorreo@electroni.co’ por el correo electrónico que queráis asociar, e igual con ‘nombreusuario’
- #14 Una vez realizado el ‘git init’, se puede comprobar que después de la ruta, en azul y entre paréntesis, está escrito ‘(master)’, que indica la ‘rama’ o ‘branch’ en la que nos encontramos del repositorio. Ya veremos esto más adelante. También, podremos ver que en la carpeta principal del proyecto se ha generado una carpeta oculta ‘.git’, que contiene la configuración GIT del repositorio que acabamos de crear en dicha carpeta. Podremos crear tantos repositorios como queramos en diferentes carpetas, y cada repositorio tendrá su configuración GIT propia, por lo que los comandos que explicaremos a continuación tendrán unos efectos diferentes en función del repositorio en el que estemos localizados. NOTA: Existen multitud de formas y editores para crear/copiar archivos y carpetas de un proyecto. No viene mal aprender a utilizar los comandos de consola del CMD o del BASH para agilizar dichos procesos.
- #15 ‘git status’ nos permite ver el estado del repositorio: La rama en la que nos encontramos, la posición y el estado de los archivos en esta rama y posición. Los colores y comentarios indicarán dicho estado, que quedará mucho más claro cuando se vean los siguientes comandos GIT básicos. Lo de la rama y posición también quedará más claro un poco más adelante. En cualquier caso, los comentarios dan pistas sobre en qué condición se encuentran los archivos o carpetas a los que se hace referencia, y qué se puede hacer con ellos. En este caso, nos están indicando que dichos archivos son nuevos o se han modificado, pero no forman parte del repositorio. Además se nos recomienda utilizar el comando ‘git add’ que veremos a continuación.
- #16 ‘git add’ nos permite añadir archivos/carpetas al repositorio. Como podemos ver en el ejemplo, podemos añadir uno a uno los elementos con el comando ‘git add <nombre_elemento.ext>’ , o todos al mismo tiempo con ‘git add .’ Al realizar de nuevo un un ‘git status’ podemos ver que ahora el color de los archivos y carpetas es verde y que se nos indican las opciones de ‘git rm --cached <nombre_elemento.ext>’ para deshacer el añadido, o bien realizar un ‘commit’ de dichos cambios. ‘git rm <nombre_elemento.ext>’ (sin --cached!!) puede resultar útil cuando se ha borrado un archivo del proyecto que ha sido confirmado con el commit en estados anteriores (se verá en un ejemplo más adelante). NOTA: Cada comando tiene una multitud de opciones. A lo largo de la exposición veremos sólo algunas de ellas (las que sé utilizar y las que me parecen más interesantes). Evidentemente, si quieres saber más, al final de la exposición tienes a tu disposición enlaces a buenas librerías en las que se puede profundizar enormemente.
- #17 ‘git commit’ nos permite confirmar lo añadido al repositorio. Al escribir dicho comando nos aparecerá la segunda pantalla, en la que escribimos la descripción que contendrá el commit. Es una buena práctica indicar una descripción relevante al commit realizado, ya que esa será la única pista que tendremos en cuanto a qué modificaciones se han hecho o el estado del proyecto en el que se está trabajando en ese momento determinado. Al realizar el commit, se pueden ver datos interesantes como en qué rama se ha realizado, las primeras cifras del código/id que se le ha asignado al commit, y detalles sobre los cambios con respecto al commit anterior (o estado inicial en este caso).
- #18 Añadimos una carpeta js con un archivo librería.js, y un archivo página.html y modificamos los archivos ya existentes README.txt e index.html. Realizamos las acciones anteriores: ‘git status’: Para comprobar los cambios realizados desde el último commit. ‘git add .’: Para añadir todos esos cambios. ‘git commit –m “mensaje” ’: Para realizar un commit añadiendo directamente el mensaje a continuación. Podemos ver en la descripción después del commit el número de archivos cambiados y cuántas líneas de código en total se han insertado. NOTA: Se podría haber hecho un ‘git status’ para comprobar el estado entre comando y comando para ver la evolución. Podréis comprobar, sino habéis realizado todavía los pasos el resultado de cada ‘git status’ después de cada acción.
- #19 Realizamos esta vez cambios en un solo archivo y volvemos a ejecutar los pasos que ya hemos visto.
- #20 Después de hacer un commit con éxito, al realizar un ‘git status’ se puede ver el mensaje: ‘nothing to commit, working directory clean’, que es bastante explicativo. ‘git log’ nos permite ver el historial de commits del repositorio. Se proporciona información sobre cada commit realizado hasta el momento: Id del commit. Autor que realizó el commit (esto tendrá sentido cuando aprendamos a compartir repositorios para los proyectos colaborativos) Fecha en la que se realizó el commit. Mensaje del commit.
- #21 ‘git branch’ y ‘git checkout’ nos permiten ver en qué rama estamos, y crear y cambiarnos de rama en el repositorio. ‘git branch’ . Nos permite ver en qué rama nos encontramos y qué ramas existen en el repositorio. ‘git branch <nombre_rama>’. Crea una rama nueva con el nombre especificado. ‘git checkout –b <nombre_rama>’. Crea una rama nueva con el nombre especificado y se cambia a dicha rama. (Ver en el ejemplo cómo se cambia el paréntesis azul (master) por (rama2), y cómo aparece marcado con un asterisco la rama en la que se está al escribir ‘git branch’ ) ‘git checkout <nombre_rama>’. Cambia de rama a la indicada.
- #22 Crear una nueva rama permite crear un nuevo camino a partir de dónde se ha creado la rama para hacer modificaciones y cuantos commits se quieran paralelamente. Cada rama NO se ve afectada por lo que se haga en las otras ramas. En este ejemplo cambiamos el archivo README.txt por un LEEME.txt en la rama1. Introducimos el comando ‘git rm README.txt’ para eliminar el archivo en el estado del commit que se va a realizar y añadimos el resto de cambios con ‘git add .’ Finalmente realizo un commit con el mensaje “cambio README.txt por LEEME.txt” (continúa en la siguiente diapositiva)
- #23 Comprobamos con un ‘git status’ que el commit se ha realizado correctamente en la rama 1. Comprobamos con un ls que el LEEME.txt aparece y el README.txt no existe, y con un ‘git checkout master’ nos cambiamos a la rama inicial ‘master’. En la rama master, realizamos también un ‘git status’ para comprobar que no hay cambios desde el último commit realizado en dicha rama. Después hacemos un ls y ¡tachán! Podemos ver que el archivo LEEME.txt NO existe en esta rama y sigue siendo el README.txt NOTA: Si se realizan cambios en una rama y se hace un checkout a otra, dichos cambios se trasladarán de una rama a otra o habrá conflictos. Por lo tanto, cuando se está en una rama y se realizan modificaciones, o bien se descartan dichas modificaciones con un ‘git checkout .’ (que veremos en las siguientes diapositivas), o bien se guardan y se realiza commit. Más adelante se verá también que se pueden combinar ramas a través del comando ‘git merge’.
- #24 ‘git checkout ’ tiene otras utilidades interesantes: ‘git checkout <idcommit>’ cambiar de estado de repositorio. Como se puede ver en el ejemplo, se ha creado una rama temporal en la que se encuentra en el estado del commit con el id indicado. El comando ‘ls’ es propio del BASH de Linux y es como el comando ‘dir’ en el CMD, que permite ver los ficheros de la carpeta en la que nos encontramos. Como se puede ver, los archivos que hay son los que estaban en el primer commit que realizamos, con el contenido que tenían en ese momento. Existe un comando de git más avanzado ‘git reset –hard <idcommit>’ que vuelve a dicho commit en la rama en la que se ejecute el comando, eliminando todos los commits posteriores a dicho commit. Supongo que no hace falta indicar el peligro de dicho comando y el no utilizarlo tan alegremente, sobre todo en proyectos colaborativos.
- #25 ‘git checkout ’ tiene otras utilidades interesantes: ‘git checkout <nombre_archivo>’ o ‘git checkout .’. Deshacer cambios realizados en los archivos que no se hayan añadido con ‘commit add’. En el ejemplo se ha modificado el archivo README.txt como se puede ver con el git status. Sin embargo, decido que los cambios realizados no me gustan y quiero volver a los que había hasta el último commit realizado. Para ello utilizo ‘checkout README.txt’ y al comprobar con el git status de nuevo, veo que el archivo README.txt ya no aparece como modificado. Si hubiesen varios archivos modificados y quisiese deshacer TODOS los cambios, utilizaría ‘checkout .’ (Ojo! Hay un punto “.” después del checkout!)
- #26 ‘git merge <nombre_rama>’ combina los ‘commits’ realizados en la rama que se indica a la rama en la que se ejecuta el comando. En el primer ‘merge’, antes de realizarlo he hecho varios cambios en la rama ‘master’, añadiendo un nuevo archivo (pagina3.html) y modificando el README.txt. Después de añadir los cambios y realizar el commit, desde la rama2, he introducido el comando ‘git merge master’ para unir los cambios realizados en ‘master’ con ‘rama1’. La descripción es bastante explicativa. En el segundo merge he unido los cambios realizados en ‘rama1’ con ‘rama2’ a través del comando ‘git merge rama1’ NOTA: Este comando es una de la mayor fuente de errores en el trabajo colaborativo, ya que si dos o más personas están modificando un mismo archivo, a la hora de hacer un merge entre las ramas de esas personas, git detectará conflictos que se tendrán que resolver manualmente.
- #31 La ‘~’ se escribe con ASCII presionando ‘alt+126’ con el teclado numérico.
- #32 La ‘~’ se escribe con ASCII presionando ‘alt+126’ con el teclado numérico.
- #34 En caso de tener algún error en estas últimas acciones, puedes leer la siguiente sección: https://help.github.com/articles/error-permission-denied-publickey/
- #38 Si hemos introducido una clave en las solicitudes SSH, en este momento se nos pedirá para poder realizar la petición
- #39 NOTA: No voy a profundizar más en lo que se puede hacer en GitHub, tiene una gran cantidad de herramientas muy interesantes que son fáciles de explorar y animo a que exploréis por vuestra cuenta. No obstante, estando en esta pantalla, os pido dirigir vuestra vista a la parte inferior derecha, en el apartado que dice ‘SSH clone URL’. Esa URL será la que se utilizará en el siguiente comando que explicaré ‘git clone <url>’ para descargar repositorios almacenados en GitHub de cualquier usuario registrado (Aquí entra en juego la definición de público que hemos mencionado en varias ocasiones).
- #40 ‘git clone <url>’ nos permite descargar un repositorio de cualquier usuario a nuestro equipo a través de ‘Git Bash’ y por medio de la URL que se indica en el apartado ‘SSH clone URL’ en la esquina inferior derecha una vez entramos en cualquier repositorio. Estos repositorios los podremos modificar en local, pero no podremos actualizarlos en GitHub, a no ser que tengamos los permisos, proporcionados por los usuarios propietarios. Actualizar un repositorio en Github se consigue con el comando ‘git push’ (después de hacer los commits) y actualizar nuestro repositorio en ‘Git Bash’ se realiza a través del comando ‘git pull’. Ambos los veremos a continuación.
- #41 ‘git push’ nos permite actualizar los ‘commits’ realizados en local a través de nuestro Git BASH de la rama en la que nos encontramos: En el ejemplo he añadido un nuevo archivo y realizado el correspondiente commit. Al introducir ahora el comando ‘git status’ observad que ahora se da información adicional con respecto a los commits de diferencia que existen entre el local y el remoto en GitHub. Al introducir el comando ‘git push’ se actualizan todos los cambios de la rama en la que nos encontramos en GitHub (se nos pedirá la contraseña SSH para ello).
- #43 ‘git pull’ nos permite actualizar en local los ‘commits’ que hayan realizado otros usuarios en GitHub (o aquellos que hayas hecho tú desde GitHub o desde otra máquina) Al introducir el comando ‘git pull’ se actualizan en local todos los cambios que existen en GitHub (se nos pedirá la contraseña SSH para ello). En este ejemplo, el archivo ‘creado_en_github.ea’, que fue creado en GITHUB, se ha descargado al repositorio local. NOTA: Utilizar ‘git pull’ es obligatorio hacerlo en los proyectos colaborativos antes de hacer un ‘git push’.