Mooc Git y GitHub – Repositorios públicos en GitHub
Articles,  Blog

Mooc Git y GitHub – Repositorios públicos en GitHub


Continuamos con Git y Github y vamos a ver cómo son los repositorios públicos en Github y los principales comandos para interaccionar con ellos. Que tiene dos tipos de repositorios: los repositorios con directorios de trabajo, que son los directorios en los cuales trabajamos en nuestro ordenador local como el tema anterior que se denominan también repositorios locales o de trabajo y sin directorio de trabajo (o “bare”) que están pensados para compartir desarrollos con otros a través de internet (por eso no tienen directorio de trabajo) y que se genera con el commit “git init –bare” que lo que crea es un único fichero que sólo tiene repositorio de commit y que tiene el número de repositorio y la extensión .git. Estos repositorios sin directorio de trabajo o “bare” suelen estar alojados en servidores de internet y se sincronizan con el repertorio loca en el que trabajamos con estos cuatro comandos: “git push” nos permite llevar desde nuestro repositorio local que tiene nuestro ordenador de trabajo al repositorio remoto en Github en algún lugar de internet, en algún lugar del mundo, una rama determinada para que otros la tengan accesible y puedan trabajar sobre ella. “git clone” lo que nos permite es copiar un repositorio completo que está en un servidor en la nube a nuestro repositorio local. Se nos crea un repositorio de la nada con los contenidos del que está en la nube en el que podemos empezar a trabajar en nuestro proyecto. “git fetch” nos permite, dado un repositorio local en el que estamos trabajando, traer una rama de otro repositorio en la nube y copiarla a nuestro repositorio local para trabajar con ella, y por último, “git pull” nos permite integrar directamente en una rama de nuestro repositorio local una rama de un repositorio que esté en la nube. Estos cuatro comandos son los básicos para interaccionar entre los repositorios locales y los repositorios en la nube. Este concepto de repositorios “bare” pensados para compartir desarrollo llevó a que se creasen muy rápidamente portales de repositorios web de tipo “bare” donde sólo hay repositorios que están pensados para compartir con otros. Github es el más conocido probablemente, el que vamos a utilizar nosotros, Gitbucket también es muy conocido y estos portales son utilizados muy comúnmente por organizaciones o por equipos para compartir repositorios con sus equipos o con sus clientes. Tienen tanto acceso web como acceso a través de estos cuatro comandos de aquí. Github es el que vamos a utilizar nosotros, es un portal que tiene estructura de red social bajo el lema de social coding porque los los desarrolladores de proyectos pueden compartir sus proyectos como si fuese una red social donde se comparten los mensajes, noticias, fotos o fiestas. Nos da acceso, como en todos los casos de portales web, a través del navegador web, que para ciertas cosas es mucho más cómodo, o a través de estos cuatro comandos Git, Tiene un modelo de negocio enormemente eficaz y popular porque los repositorios públicos son gratis, y por ello, casi todos los proyectos importantes de software libre del mundo, como estos de aquí y muchos otros más, están en GitHub porque se pueden almacenar sin ningún coste, y se puede utilizar para esos proyectos sin ningún coste con toda la gran cantidad de funcionalidades que nos da. Si queremos hacer negocio con nuestro software, entonces tenemos que ir a un plan de pago privado, entonces ya podemos tener repertorios privados que sólo compartimos con el equipo, con la organización o con los clientes. En este curso van a necesitar hacerse una cuenta, ya les hemos dicho que se pueden hacer aquí en el primer tema y aquí esto les dará una instrucción muy clara tanto del uso de Github como de Gib. yo recomendaría que la hagan lo antes posible si no lo han hecho ya para empezar a trabajar con ella. Los repositorios que no son el local se ven desde el punto de encuentro de nuestro repositorio local siempre como repositorios remotos a los que nosotros accedemos a través de un URL, como estos ejemplos que tengo aquí. Aquí tengo tres formatos de URL que identifican un mismo repositorio en la nube en GitHub, es el repositorio “cal” en mi cuenta “jquemada” que es el que va a contener el repositorio básico del desarrollo que utilizamos como ejemplo en este curso. Los URLs pueden tener varios formatos, aquí el primero es el formato web. Github utiliza “https” para que el acceso sea siempre seguro y no nos puedan espiar, luego está la dirección del portal del servidor, la dirección de dominio, “github.com” y luego el nombre de cuenta y el nombre de repositorio, que deben ser únicos, el primero en todo GitHub y el segundo en la cuenta, por lo tanto, esto da una dirección única en internet para este repositorio que permite referenciarlo desde cualquier lugar de internet sin ningún problema. Aquí tenemos otro equivalente donde simplemente se añade la extensión “.git” porque ya saben que esa es la extensión que lleva el repositorio “.bare” y el repositorio va a estar guardado en GitHub con un nombre de este tipo, y además tenemos aquí el formato original con el que se diseñaron, digamos porque internet permite diseñar formatos de URLs y de URIs específicos para cada servicio y cuando se creó git se diseñó este formato, pero hoy día apenas se utiliza. Se suele utilizar solamente éste, tanto para acceso web como para referenciar el repositorio “remotos” en comandos de de git. GitHub tiene una función principal que es compartir repositorios con terceros, para eso es enormemente útil, si uno se registra, además puede hacer estas tres operaciones: crear un repositorio remoto inicial directamente en GitHub en la nube, sin hacer nada el local, simplemente cuando ahora volvamos y creemos ahí un repositorio vacío exactamente igual que creamos en local dando al botón de ‘new repository’, hacer una copia de un repositorio albergado en GitHub en una cuenta a nuestra cuenta dando simplemente a un botón, al botón de ‘fork’, o también importar un repositorio identificado por un URL de cualquier lugar de internet, e incluso de otros repositorios en otros servidores y también desde GitHub, por supuesto, porque se identifica por una URL digamos a nuestra cuenta en GitHub con el botón de ‘importar repository’. Esto es cómodo, pero es equivalente a crear un repositorio vacío y luego rellenarlo con un repositorio a través de un ‘import’ con el URL. Además pueden crear organizaciones. Nosotros tenemos aquí creada una, “CORE-UPM”, que veremos ahora la utilidad que puede tener y luego, por supuesto, podemos hacer estas cuatro operaciones desde nuestro repositorio local al repositorio que tienen en gitHub en la nube. ‘push’ para subir una rama, ‘clone’ para copiar un repositorio entero, ‘fetch’ para traer una rama y ‘pool’ para integrar una rama remota. Nosotros vamos a ilustrar esto con estos tres repositorios que vamos a crear aquí. El repositorio “cal” va a ser el repositorio base y lo vamos a crear con ‘new repository’. El repositorio “cal_doscom” va a ser un repositorio donde vamos a congelar el estado de este repositorio cuando tenía sólo en la rama master dos ‘commits’ y lo vamos a crear con el botón de ‘import repository’, y el repositorio, este de aquí, va a ser un ‘fork’, un clon realizado dentro de GitHub de una cuenta a otra con el botón de ‘fork’. esos tres botones están aquí y ahora veremos en detalle cómo se invoca cada uno de ellos. el primer botón, el de ‘new repository’ es un botón que se despliega cuando vamos al ‘+’ ese que tenemos en la esquina superior derecha de GitHub en todas las páginas prácticamente. Sale este desplegable que tienen allí, se da al botón de ‘new repository’ y entonces nos sale aquí este formulario donde ponemos el nombre del repositorio que queremos crear, ya no sale predefinida nuestra cuenta, como estamos registrados con credenciales, esto sólo puede hacerlo un usuario registrado, pues ya sabe quiénes somos y nos pone nuestra cuenta, nuestro nombre de usuario. Y con esto pues tenemos ya el identificador único de este repositorio dentro de GitHub, porque nombres de cuentas son únicos y nombres de repositorios son únicos en la cuenta. Además nos permite crear este repositorio inicial con tres ficheros muy típicos: ‘.gitignore’ para decirle a git que debe ignorar la licencia de un proyecto y el fichero ‘readme’, que es el resumen de lo que hace un proyecto, Pero nosotros queremos crearlo totalmente vacío y por eso no le decimos que nos incluya ninguno de estos ficheros, por tanto, no seleccionamos ninguna de esas posibilidades. Además dejamos que sea un repositorio público, eso sale marcado por defecto, porque si ponemos que sea privado, empieza a cobrarnos, lo primero que hace es pedirnos la tarjeta. Damos a ‘create repository’ y nos sale aquí ya la página del repositorio en web. La página, que está identificada por el identificador único de GitHub del repositorio, cuenta y nombre del repositorio, que lleva a éste enlace, a este identificador único, a esta dirección única en internet que es el repositorio, y aquí están las instrucciones éstas que les he dicho, o parte de ellas: primero un ‘quick setup’, luego cómo crear un repositorio y subirlo con ‘push’, y por último, cómo importar un repositorio de otro lugar en internet a través de su URL. Vamos a ver ahora cómo subimos al repositorio local que creamos en el tema anterior con los dos ‘commits’ al repositorio base en GitHub, éste que acabamos de crear con ‘git push’. ‘git push’ es un comando que nos permite actualizar repositorios remotos de una forma muy sencilla. Tenemos que pasar simplemente el enlace, la dirección del repertorio remoto, ese URL que acabamos de ver, este es URL del GitHub del repositorio que acabamos de crear y la rama que queremos subir y automáticamente sube la rama máster. Si pasásemos este identificador y hubiésemos creado este repositorio aquí en GitHub, nos subiría este repositorio cal_doscom El contenido de la rama máster exactamente igual que en el caso anterior. ‘git push’ necesita dos condiciones para finalizar con éxito: debemos tener credenciales de acceso a la cuenta dónde está el repositorio porque nos las pide, si es el primer acceso, luego ya lo guarda en una cookie y no la vuelve a pedir, y la rama que subimos debe ser compatible con la que está almacenada en el repositorio remoto. Es decir, si en el repositorio remoto tenemos una rama máster que tiene un commit que es éste de aquí, y queremos subir esta rama que tiene exactamente el mismo commit con el mismo identificador (porque va a controlar los identificadores), y sólo añadimos commit al final, entonces serán compatibles y el push se hará correctamente. Si no son compatibles, entonces el push fallará. Aquí vamos a ver como subimos el repositorio que generamos en local en el tema anterior. Estamos en nuestro terminal de comandos en el ordenador local, Con “git log –oneline” vemos que tenemos estos dos commits que generamos, que son estos dos de aquí representados gráficamente, y si nosotros invocamos este comando de aquí: git push, identificador del repositorio remoto y la rama queremos subir, Nos sube a GitHub el repositorio y la página web donde tenía solo las instrucciones antes de hacer este push Contiene ahora ya en este repositorio los dos commits y bueno pues toda la información y ficheros de este repositorio, porque hemos subido este contenido al repositorio bare que tenemos en GitHub. Vamos a ver ahora cómo vemos nosotros este repositorio a través de web, que es una forma muy útil de inspeccionar repositorios. Si nosotros ponemos en un navegador el URL, éste que identifica el repositorio, entramos en la página, vemos aquí el nombre del repositorio, el identificador que es: cuenta y el nombre de repositorio, que llevan a este URL o a esta dirección única en internet. Vemos que tiene dos commits, que tiene estos ficheros, que aquí está el ‘readme’ presentado para tener un resumen de lo que hace el proyecto, y tenemos un botón de ‘download’ o de clonar que nos permite descargar a través del navegador el repositorio o la última versión del repositorio a una carpeta o a un ‘zip’ en nuestro ordenador por si queremos bajárnosla. Si nosotros hacemos clic en ‘calculator.html’ nos muestra el contenido de ese fichero, aquí tenemos el código, y que esto lo que implementa es la calculadora ésta que hemos visto. Si hacemos clic en dos commits Entonces vemos los commits, estos dos commits que hemos subido con los mismos nombres y los mismos identificadores, no aparecen los identificadores pero también nos los muestra. En este último commit tenemos la calculadora y si hacemos clic en él, nos salen las diferencias con el commit anterior, con este commit de aquí. Como sólo hemos añadido el fichero calculadora, se nos muestra en verde todo el contenido del fichero calculadora, este de aquí, porque solo se ha añadido código, eso se muestra en verde, si hubiésemos quitado algo aparecería en rojo y el contexto en negro. Vamos a ver ahora cómo importamos un repositorio a través de un URL a otro repositorio que creamos que lo hacemos con el desplegable también más éste que tiene en la esquina superior derecha de las páginas de GitHub desplegamos, hacemos import repositorio, sale este formulario donde ponemos el URL y el nombre del repositorio, damos a import, empieza a estar un rato haciendo cosas y al final nos aparece una página con el nuevo repositorio que está en mi cuenta también, es la misma cuenta, pero un nombre diferente. no podría tener el mismo nombre que el repositorio base del cual hemos copiado porque esos dos nombres iguales no pueden existir en una cuenta. Y otro proceso sería exactamente igual, las mismas ramas, los mismos commits con los mismos identificadores. Vamos a hacer ahora un fork a otra cuenta, a una organización CORE-UPM que nosotros hemos creado para este proyecto. Esto lo hacemos simplemente yendo a la página del proyecto que queremos copiar dentro del GitHub con este fork, esta bifurcación. hacemos clic, como el proyecto detecta que es un proyecto que está en mi cuenta, me muestra sólo las otras credenciales de acceso que yo tengo a estas dos organizaciones. Lo clono dando a la organización CORE-UPM haciendo clic en la opción CORE-UPM, y entonces me sale una copia exacta del repositorio inicial con los dos mismos commits, con los dos mismos indicadores también, pero que se ha copiado de GitHub también a GitHub sin pasar por mi ordenador local. Y con esto acabamos este tema. Muchas gracias.

3 Comments

Leave a Reply

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