Mostrando entradas con la etiqueta git clone. Mostrar todas las entradas
Mostrando entradas con la etiqueta git clone. Mostrar todas las entradas

domingo, 9 de octubre de 2022

GIT - 3 - GITHUB - Clonar/Subir repositorio - Gestión de Credenciales.

 ¿Que es Github?


Es un portal creado para poder alojar el código de las aplicaciones de cualquier desarrollador. Utiliza el código de control de versiones Git que estamos viendo, que fue creado por Linus Torvalds.

No es el único que existe, ya que existen servicios similares como Bitbucket y GitLab.

Lógicamente antes de empezar a usarlo tenemos que darnos de alta en el servicio

Una vez registrado puedes hacer multitud de cosas, como por ejemplo crear tu propio repositorio, escribir el código en un navegador web, muy similar a  Visual Studio Code o trabajar en local desde el ordenador. 

Para ver como funciona vamos a crear un repositorio ficticio nuestro, lo clonaremos, trabajaremos con el en local y finalmente lo volveremos a subir a Github. Existen también infinidad de repositorios creados por la comunidad que puedes utilizar de la misma forma, es decir, buscas el que necesites y lo clonas a tu ordenador como vamos a ver a continuación.


Crear un repositorio y subirlo a Github



Si lo que quieres es clonar un repositorio que ya existe en Github o en cualquier otro servidor, para trabajar con él en local.

Por ejemplo este programa para resolver sudokus:

$ git clone https://github.com/kying18/sudoku.git
Copiará el contenido del repositorio dentro del directorio donde hayas lanzado 
el comando.
Si lo que quieres es crear tu propio repositorio y subirlo a Github.

Lo primero es abrir el navegador, ir a Github y logearnos.

Luego se pueden utilizar varias opciones:

a) Con una cuenta en esta plataforma, cuyo registro es gratuito, puedes subir archivos a GitHub. Para ello primero crearemos un repositorio en Github de la siguiente manera:

1.- Aunque existen varias formas, una de ellas es la siguiente. Utiliza el menú desplegable de la esquina superior derecha, y seleccionas tus repositorio. 



Luego le das al botón "New"  o  "Nuevo" según tengas configurado el idioma.



Se abrirá la pantalla donde podremos seleccionar varias opciones. La más importante es el nombre del repositorio. En este caso le he llamado "Prueba" y lo he dejado como Público para que cualquiera en la web pueda verlo y trabajar con él. También podemos añadir una descripción. En la parte inferior le damos al botón "Crear Repositorio".




En la siguiente pantalla nos darán información útil de como crear un repositorio nuevo o subir uno que ya tengamos a través de la línea de comandos a este proyecto. Lo que nos importa en este caso es apuntar el enlace al repositorio ya que nos será útil posteriormente.




Aunque lo puedes hacer antes de crear el proyecto, en este ejemplo vamos a crear el archivo README junto con la creación del repositorio (En este archivo puedes usar el lenguaje markdown para darle formato).  Ya un terminal de nuestro ordenador ponemos el repositorio en marcha.

Creamos el archivo readme.md que contendrá instrucciones de como funciona
el programa y como ponerlo en marcha.
$ echo "# Aquí Irán las instrucciones." > README.md

Ahora iniciamos el repositorio.
$ git init 

Creamos un archivo más para añadir al repositorio, para ver como funciona
el ejemplo.
$ touch main.py

Lo añadimos todo al árbol de trabajo y al stage.
$ git add .

Realizamos una confirmación.
$ git commit -m "Primer y único commit"

Como una de las cosas que recomienda Github es cambiar el nombre de la 
rama master a main, vamos a hacerlo. Ya ha habíamos visto una opción 
que era usar justo después del git init, el comando git checkout -b main.
Ahora haremos lo mismo pero ya al final con el siguiente comando:
$ git branch -M main

Ahora viene lo importante. Le decimos a git que añada el repositorio local,
el que tenemos en el ordenador, a github, que es el repositorio remoto. 
Aquí es donde tenemos que tener la ruta o enlace al repositorio remoto que 
apuntamos en un paso anterior.
$ git remote add origin https://github.com/Usuario/Prueba.git

* Usuario es tu nombre de usuario en Github

Para finalizar ejecutamos los cambios con el siguiente comando:
$ git push -u origin main
nos pedirá nuestro nombre de usuario y luego la contraseña de github.
Sin embargo cuando le das la Intro.

.....SORPREEEEEEEESAAAAAAA !!!!!
Support for password authentication was removed on August 13, 2021.


La autenticación basada en contraseña para Git se quitó en favor de métodos de autenticación más seguros, así que tendremos que usar uno de ellos para identificarnos ante el servidor y poder enviar el repositorio a Github.

Vamos a verlos:

1.- Creación de un Token de acceso personal.

Para entendernos, un Token es un código de seguridad que nos permite autenticarnos en Github cuando usamos la línea de comandos en el terminal. Como obtenerlo está muy bien explicado en el enlace a la página de documentación de Githubno me detendré a comentar como hacerlo.  Eso si en cuanto la página lo genere guárdalo en algún sitio, porque tal como dice el aviso no te lo volverán a mostrar de nuevo.

Una vez que lo tengamos ya podemos subir el repositorio, proseguimos donde lo dejamos:

$ git push -u origin main
Username: tu nombre de usuario
Password: tu token de acceso 
El problema de los tokens de seguridad es que, al igual que la contraseña hay que introducirlo cada vez que necesitemos conectarnos al servidor de github a través de la línea de comandos, bien sea porque queramos clonar un repositorio o subir el nuestro propio.  

Una forma de mitigar esto es usar un ayudante de credenciales que se almacena en la cache del ordenador para un determinado tiempo, de forma estándar 15 minutos. 

    $ git config --global credential.helper cache

Si quieres establecer un determinado periodo de tiempo, por ejemplo 2 horas hay que usar el parámetro  --timeout. (el tiempo en segundos)

    $ git config --global credential.helper cache --timeout=120

Puedes obtener más información en "Caching your Github credentials in Git".




Seguimos los siguientes pasos:

a) generar la llave privada y pública.
$ ssh-keygen -t ed25519 -C "your_email@example.com"
Dentro de las comillas ponemos nuestra dirección de correo, la que usamos al registrarnos en Github.

b) Añadir la llave ssh al agente ssh

- Nos aseguramos de que el agente está activo:
# start the ssh-agent in the background
$ eval "$(ssh-agent -s)"
> Agent pid 59566
- Agregamos nuestra llave ssh privada al agente para poder usarla. Si has creado tu clave con un nombre diferente o si estas agregando una clave existente que tenga un nombre diferente, reemplaza id_ed25519 en el comando con el nombre de tu archivo de clave privada.
Si has puesto contraseña a la clave cuando la generamos, el sistema de la pedirá en este momento.

    $ ssh-add ~/.ssh/id_ed25519


a) Abrimos la clave pública con cualquier editor de texto y la copiamos. Si no le has cambiado el nombre es el archivo id_ed25519.pub

b) En la esquina superior derecha de cualquier página, haz clic en la foto del perfil y, luego, en Settings (Configuración).

settings git

A la izquierda, en la sección que pone "Acess", haz click en "SSH and GPG KEYS"

c) Hacemos click en "New SSH Key" o en "Add SSH Key"

d) En el campo "Título", agrega una etiqueta descriptiva para la nueva clave. Por ejemplo, si estás utilizando una computadora portátil personal, puedes poner "Laptop personal".

e) Seleccionamos el tipo de clave "Autenticación" o "Firma". Si no sabes cual usar déjala en autenticación. Puedes encontrar más información aquí

f) Pega tu llave pública en el campo donde pone "Key"

key field



g)  Para finalizar haz click en "Add SSH Key"

botón añadir llave

Si se te solicita, confirma tu contraseña en GitHub

Para comprobar si todo ha ido correcto probáremos la conexión ssh con github siguiendo las instrucciones de este enlace tal como indica la documentación de github.

IMPORTANTE:

Recuerda cuando clones tus repositorio tomar la opción de copiar la url por SSH y no por HTTP, sino, no estarás usando la llave ssh que hemos creado.

Por ejemplo, para clonar el repositorio del sudoku que puse al principio utilizando la conexión SSH seria:

    $ git clone git@github.com:kying18/sudoku.git


Si volvemos al repositorio que dejamos preparado para subir a Github, ya vimos como subirlo usando un token de seguridad, ahora usando SSH el proceso se hace directamente (aunque tendrás que poner la contraseña de la llave la primera vez que lo utilices seguramente). El comando sigue siendo el mismo, solo que ahora va automáticamente:

    $ git push -u origin main



3) Si trabajas con Visual Studio Code el tema es sencillo también. Puedes crear el repositorio como hemos antes y una vez que tengas el proyecto finalizado le das al icono de Git o haces que se muestre yendo al menú view --> Source Control y ejecutas la opción de push y sigues las instrucciones. 




miércoles, 14 de septiembre de 2022

Curso Esquemático de Git y Github

imagen de entrada de git







Curso Esquemático de Git y Github.


Cuando pasas de un proyecto sencillo a otro más complicado, estas trabajando con más personas en un mismo programa o si simplemente quieres tener un registro de como está evolucionando el código que estas desarrollando para que un tú del futuro sepa lo que has hecho, tenemos que utilizar si o si un administrador de versiones. El más conocido en términos de rendimiento, seguridad y flexibilidad es Git y su plataforma GitHub.

Antes de meternos en materia de como funciona, es necesario entender como se pueden controlar las diferentes versiones de un programa. Si tuviéramos que hacer nosotros manualmente un control de como evoluciona un programa podríamos usar el comando "diff" de Linux de la siguiente forma.

Imaginemos un programa como el siguiente:

# version 0.1 
print("Hola Mundo")

Vamos a ponerle un nombre y guardarlo. Yo lo llamaré archivo_1.py. Ahora vamos a añadir una nueva línea:

# version 0.2 
print("Hola Mundo")
print("Esta es la segunda versión")

Lo vamos a guardar con un nombre distinto para poder comparar ambas versiones. Este se llamará archivo_2.py

Si en el shell de Linux tecleamos:

$ diff archivo_1.py archivo2_py

Veremos lo siguiente:

1c1
< # version 0.1 
---
> # version 0.2 
2a3
> print("Esta es la segunda versión")
Aunque se pueden intuir las diferencias existentes entre los archivos, el resultado no es fácilmente comprensible. Esto es debido a que fue diseñado para ser usado por computadoras y no por humanos. Pero a groso modo lo que viene a decir es que la primera línea del primer archivo debe cambiarse por la primera del segundo para que estén sincronizados. El símbolo "<" es el texto que sale y el ">" el que entra
Y que a la segunda línea del primer archivo que no cambia, hay que añadirle la tercera del segundo archivo.

Otras formas de hacer los mismo es usando el parámetro -u que compara ambos programas línea por línea.

$ diff -u archivo_1.py archivo2_py
--- archivo_1.py	2022-08-15 18:15:18.939411615 +0200
+++ archivo_2.py	2022-08-15 18:15:31.091518676 +0200
@@ -1,2 +1,3 @@
-# version 0.1 
+# version 0.2 
 print("Hola Mundo")
+print("Esta es la segunda versión")

Y quizá la más intuitiva es la que lo compara a dos columnas:

$ diff -y archivo_1.py archivo2_py
# version 0.1 			|# version 0.2 
print("Hola Mundo")		   print("Hola Mundo")
				>  print("Esta es la segunda versión")

Aplicando Cambios.

Para guardar los cambios que ha habido de la versión 0.1 del programa a la 0.2 usaríamos la siguiente instrucción:

$ diff -u archivo_1.py archivo2_py > cambios.diff

Si ahora, por ejemplo, se nos borra el archivo_2.py pero conservamos el archivo con las diferencias podemos volver a generarlo con las siguiente instrucción.

$ patch archivo_1.py < cambios.diff

Esto nos dará el archivo_2.py que se nos había borrado.

Esto es especialmente útil cuando tienes un programa que contiene un error y que tu no localizas. Imagina que se lo pasas a un amigo que te lo soluciona. Este amigo genera un nuevo archivo con las diferencias "cambios.diff" y te lo reenvía. Tu aplicas la solución ejecutando el comando "patch" tal como vimos en el ejemplo anterior sobre tu archivo.

IMPORTANTE: estos comandos se pueden aplicar también sobre directorios.

No obstante imagínate el lio que supondría aplicar estos métodos cada vez que hayas realizado modificaciones significativas en tus programas. Para hacerlo de forma automática por ti están los controladores de versiones como es el caso de Git.


Instalando GIT, configuración y uso.


1.- Instalando GIT.

Primeramente debemos comprobar si tenemos Git instalado. Para ello podemos usar:

$ git --version
git version 2.34.1

Esto nos dice que tenemos la versión 2.34.1 instalada. 

Si no lo tuviésemos instalado, en Linux una de las formas de hacerlo es con:

$ sudo apt-get install git

Si no usas un gestor de paquetes entonces hay que ir a su página web y seguir las instrucciones.

En Ubuntu además puedes considerar instalar estos dos paquetes que te pueden ayudar aunques son opcionales:

- Gitk 

Es un navegador gráfico que se usa para ver de manera gráfica el historial de un repositorio git.

Se instala con:

$ sudo apt-get install gitk

Ejemplo con $ gitk -all sobre un repositorio.

gtik ejemplo

- Git-gui

Es un entorno gráfico para usar los comandos de git sobre los repositorios.

Se instala con:

$ sudo apt-get install git-gui

Ejemplo de uso de $git gui

git gui



2.- CONFIGURANDO GIT.

Una vez instalado lo primero que tenemos que hacer es configurarlo con nuestro nombre y correo electrónico:

$ git config --global user.email  micorreo@ejemplo.com

$ git config --global user.name  mi_nombre

Usamos el parámetro "--global" porque queremos usar estos valores para todos los repositorios que creemos. Si queremos usar un correo y nombre especifico para un proyecto concreto, dentro de ese proyecto usaremos la mima instrucción pero con el parámetro "--local".

Si quieres ver como está la configuración actual de Git puedes usar el siguiente comando:

$ git config -l  o $ git config --list


3.- INICIANDO EL REPOSITORIO.

Dentro de la carpeta del proyecto hay dos formas de iniciar git.

Si empezamos el repositorio desde cero:

$ git init

Sin argumentos nos crea una carpeta oculta .git en la carpeta de trabajo donde iran todos los archivos que git necesita para funcionar. Si le pasamos como argumento un nombre entonces nos crea una carpeta con ese nombre y dentro crea la carpeta oculta .git.

Si lo que queremos es hacer una copia de un repositorio ya existente en otro lugar, entonces usaremos:

$ git clone dirección@delrepositorio


Antes de continuar hay que aclarar estos tres conceptos:

escenarios en git

El directorio
. Ahí están todos los archivos del proyecto tanto los que queramos realizar un seguimiento como los que no. Es el directorio de trabajo con todos sus archivos y directorios.

Working Tree. En este mismo directorio, a todo lo que queremos realizar un seguimiento para controlar sus cambios, tanto si son archivos concretos como directorios, es lo que va a formar el llamado árbol de trabajo. Esta lleno de archivo que editas, donde se agregan nuevos archivos y de los que eliminamos archivos innecesarios. Cualquier cambio en el árbol de trabajo, queda registrado y se muestra como archivos o directorios modificados.

Stage. Es el lugar donde se guardan los cambios, para luego ser llevados definitivamente al repositorio cuando hagamos instantáneas del proyecto llamadas confirmaciones o commits en inglés.

Vamos a ver un pequeño ejemplo de como crear un repositorio desde cero. Primero creamos el directorio de trabajo (proyecto), entramos en él y posteriormente iniciamos el repositorio.

creación de un repositorio desde cero


4.- Añadir archivos al árbol de trabajo o rastrearlos.

Si queremos ir añadiendo archivos uno a uno.

$ git add [nombre_del_archivo]

Pasa los archivos del directorio al staging area.

Si queremos añadir todo el directorio. (el punto al final aquí es importante, no es una errata)

$ git add .


primer archivo añadido



En el ejemplo anterior creamos un archivo nuevo llamado main.py, que antes no estaba. Quise ver en que estado estaba para git. 

Lo realizamos con la sentencia:

$ git status

Git nos dijo como estaba el árbol de trabajo y la situación actual del repositorio. También que estamos en la rama "master", que aún no hemos hecho ningún "commit" y que tenemos un archivo sin seguimiento, que es el main.py vacío que hemos creado.

Lo añadimos al seguimiento con "git add" y como vemos después, otra vez con git status, el archivo aparece ahora en verde y está listo para acciones posteriores.


5.- Pasar los cambios del Working Tree al Stage.


Ahora que ya tenemos un repositorio git, lo hemos configurado y hemos creado un archivo. El siguiente paso es realizar algunos cambios en el mismo y confirmar instantáneas de esos cambios en el repositorio cada vez que el proyecto alcance un estado que quieras conservar.  Tendremos que poner todo lo que queramos que se conserve en el Stage Area "Escenario" para poder realizarle una instantánea.

Abre el archivo main.py e incluye algún comentario o algo de texto. 

Ahora queremos conservar nuestro proyecto tal como esta en este momento, con el comentario o texto que acabamos de añadir. Como hemos modificado el archivo que ya teníamos rastreado, si hacemos un "git status"  el programa nos avisa que tenemos un archivo que ya teníamos rastreado pero que hemos hecho cambios. Como queremos hacer la instantánea del archivo con el comentario nuevo introducido tenemos nuevamente que confirmar ese cambio para que el archivo pase del área de trabajo al Escenario (Stage).

Hacemos nuevamente:

$ git add main.py

Ahora si que podemos tomar la instantánea del proyecto ya que el archivo está en el staging area. Para conservar el repositorio tal como está en este momento y hacer la instantánea o foto del proyecto en su estado actual.

El comando a utilizar es:

$ git commit

Como ves este comando toma los archivo, directorios etc que están en el área de trabajo y crea el repositorio.

Al hacerlo se abrirá tu editor de texto por defecto, el mío en Ubuntu es nano y podrás escribir de forma detallada en que consisten las modificaciones, para que tu yo del futuro o cualquiera que lo lea pueda saber lo que se ha hecho.

El editor por defecto se puede modificar con:

$ git config --global core.editor <nombre_editor>                   (nano, vim, emac etc)

Existen unas reglas de estilo a seguir que brevemente son:

- La primera línea se pondrá una breve descripción de no más de 50 caracteres de lo que se ha hecho desde el último commit.

- Luego añadimos una descripción ya más detallada del mismo.

primer commit

Guardamos y ya está. 

Nota: Si no escribes nada o sales se aborta el commit.

Si el repositorio es para tí y no estás muy interesado en realizar una descripción detallada de los cambios puedes utilizar el comando:

$ git commit -m "texto con la descripción abreviada del cambio"

Por ejemplo:

$ git commit -m "Primer commit"

No te saldrá el editor de texto y el commit se guardará con el texto introducido.


Otro atajo para realizar los commits, puede ser también:

$ git commit -a 

Es un atajo para confirmar cualquier cambio en los archivos que tengamos rastreados y confirmarlos en un solo paso. Pero ¡Ojo! no realiza commit de los archivos nuevos, solamente de los que estén en seguimiento, es decir de aquellos que hayamos hecho un "git add [archivo]" primero.

Es una mezcla de "git add . + git commit"

Luego, para ver los comentarios de los commits usaremos el argumento "log". Hay varios parámetros que podemos usar.

El más sencillo es:

$ git log

chema@lenovo:~/proyecto$ git log
commit 168d6f4f8baa5c29310309b82c5e7b9232ff877d (HEAD -> master)
Author: usuario <usuario@correo.es>
Date:   Fri Sep 9 19:33:22 2022 +0200

    Proyecto inicial para aprender git básico
    
    Este es el commit o primera instantanea del proyecto. Hemos iniciado un
    repositorio, creado un archivo. Luego hemos añadido ese archivo al segui-
    miento de git. Añadimos un comentario volvimos a confirmar los cambios y
    realizamos el primer commit.

$ git log --stat

Muestra estadísticas de los commits.

chema@lenovo:~/proyecto$ git log --stat
commit 168d6f4f8baa5c29310309b82c5e7b9232ff877d (HEAD -> master)
Author: usuario <usuario@correo.es>
Date:   Fri Sep 9 19:33:22 2022 +0200

    Proyecto inicial para aprender git básico
    
    Este es el commit o primera instantánea del proyecto. Hemos iniciado un
    repositorio, creado un archivo. Luego hemos añadido ese archivo al segui-
    miento de git. Añadimos un comentario volvimos a confirmar los cambios y
    realizamos el primer commit.

 main.py | 1 +
 1 file changed, 1 insertion(+)

$ git log -p 

Nos indica los cambios entre commits, equivalente a la salida de la instrucción "diff -u" que vimos al principio del capitulo. Página la salida.

chema@lenovo:~/proyecto$ git log -p
commit 168d6f4f8baa5c29310309b82c5e7b9232ff877d (HEAD -> master)
Author: usuario <usuario@correo.es>
Date:   Fri Sep 9 19:33:22 2022 +0200

    Proyecto inicial para aprender git básico
    
    Este es el commit o primera instantánea del proyecto. Hemos iniciado un
    repositorio, creado un archivo. Luego hemos añadido ese archivo al segui-
    miento de git. Añadimos un comentario volvimos a confirmar los cambios y
    realizamos el primer commit.

diff --git a/main.py b/main.py
new file mode 100644
index 0000000..1274ace
--- /dev/null
+++ b/main.py
@@ -0,0 +1 @@
+# comentario

$ git log --oneline

Muestra cada commit que hayamos hecho en una sola línea, con lo que es más fácil de ver.


$ git show [id]

Lo mismo que el comando anterior pero mostrando solamente el último commit realizado. Si se introduce un ID concreto nos muestra solamente ese. El ID es el número largo que aparece después del commit, (en el siguiente ejemplo el ID es 168d6f4f8baa5c29310309b82c5e7b9232ff877d. Se puede usar abreviadamente los 6 primeros caracteres, en vez de teclear el número entero.)

chema@lenovo:~/proyecto$ git show
commit 168d6f4f8baa5c29310309b82c5e7b9232ff877d (HEAD -> master)
Author: usuario <usuario@correo.es>
Date:   Fri Sep 9 19:33:22 2022 +0200

    Proyecto inicial para aprender git básico
    
    Este es el commit o primera instantanea del proyecto. Hemos iniciado un
    repositorio, creado un archivo. Luego hemos añadido ese archivo al segui-
    miento de git. Añadimos un comentario volvimos a confirmar los cambios y
    realizamos el primer commit.

diff --git a/main.py b/main.py
new file mode 100644
index 0000000..1274ace
--- /dev/null
+++ b/main.py
@@ -0,0 +1 @@
+# comentario

$ git diff (archivo) 

Equivale al comando "diff -u" que vimos al principio, para comparar las diferencias entre dos versiones del mismo archivo. Nos muestra los cambios en los archivos en seguimiento PERO teniendo en cuenta el último commit y antes de realizar uno nuevo. Se le puede especificar tambien el nombre de un archivo en concreto.

$ git add -p  

Para confirmar las modificaciones realizadas a los archivos, antes de hacer el commit. En vez de realizar las confirmaciones de los cambios en los archivos de forma automática nos muestra los cambios y nos permite confirmarlos o no. Es como "git add" pero nos permite ver antes los cambios y confírmalos para añadirlos al stage.

chema@lenovo:~/proyecto$ git add -p
diff --git a/main.py b/main.py
index 3808744..91479a0 100644
--- a/main.py
+++ b/main.py
@@ -1,2 +1,2 @@
 # comentario

(1/1) Stage this hunk [y,n,q,a,d,e,?]? 

$ git diff --staged

Para ver los cambios en el stage pero que aún no tienen commit.