31. rhavi,
hoola muchas gracias eso va ser de gran utilidade para mi tambien
Skor: +0
95 poruka, 4 stranica: 12 3 4 ↖ Vrati se nazad na listu tema
Skor: +3
hoola muchas gracias eso va ser de gran utilidade para mi tambien
Skor: +0
¡Buenos días!
Vamos a continuar hablando sobre Git. Ya nos falta muy muy poco para poder usarlo en Internet, pero eso será en el próximo post, no en este. Hoy seguiremos conociendo por dentro los repositorios locales. En esta ocasión, toca hablar de ramas. ¡Empezamos!
Hasta ahora, al trabajar con repositorios, lo único que hemos hecho es agregar commits. Los commits se han apilado unos sobre otros, contando una historia. Podemos imaginarnos esta pila de commits como el tronco de un árbol. Para simplificar, un repositorio Git es un árbol muy poco desarrollado en el que sólo hay ramas. No tenemos hojas, ni flores, ni frutos, sólo ramas. El tronco, por increíble que parezca, también es una rama, y su commit inicial es la "raíz" del árbol.
Las ramas se emplean normalmente para hacer cambios experimentales que no queremos que afecten al desarrollo principal hasta más tarde. Cada rama tiene un punto de partida, situado en un lugar de otra rama, y va evolucionando aparte. Cuando el cambio experimental funciona, se puede fusionar con la rama principal para que forme parte del desarrollo estándar.
Para crear ramas, utilizaremos el comando git branch. Para viajar a ellas, emplearemos el comando git checkout. En el siguiente ejercicio, será necesario crear un repositorio nuevo y hacer varios commits. Consulta los posts anteriores si necesitas refrescar alguna de estas cosas.
Los miembros del equipo de NVDA en español están hambrientos después de pasarse meses sin comer mientras traducían el libro de formación de PowerPoint. Para saciarse, han decidido comer una ensalada, y quieren que tú redactes una lista de la compra con los ingredientes necesarios. Para ello, debes crear un repositorio y hacer varios cambios en la lista hasta que todos estén satisfechos.
0,5 kg de lechuga
6 tomate
6 pepino
1 botella de aceite
1 botella de vinagre
1 paquete de sal
1 lata de aceitunas sin hueso
1 lata de maíz
Llegados a este punto, parecen satisfechos, pero deciden hacer un experimento y echar pollo crujiente a la ensalada. Para ello, vamos a utilizar una rama independiente, porque no queremos que nuestra ensalada actual se vea perjudicada en caso de que algo salga mal.
Cuando hacemos un experimento en una rama independiente, corremos el riesgo de quedarnos anticuados. El desarrollo principal puede continuar, y pueden cambiar cosas que nos afecten. Para prevenir esta situación, tenemos a nuestra disposición los comandos merge y rebase. El comando merge fusiona los cambios de una rama en otra, ordenando los commits cronológicamente. El comando rebase, en cambio, modifica el punto de partida de nuestra rama para que nuestro trabajo sobre esa rama siga quedando en lo alto del historial de commits. En el ejemplo anterior del árbol, rebase "arranca" la rama del tronco y la ingerta más arriba. Una buena forma de saber dónde se han situado nuestros commits es con el comando git log, que ya vimos antes. Ahora, continuemos preparando nuestra ensalada. Queremos experimentar añadiendo pollo, pero sobre las modificaciones más recientes, y no sobre la ensalada del principio:
Cuando ya hemos terminado de experimentar en una rama independiente, si los cambios han salido bien, hay que fusionarla en la principal para que nuestros valiosos aportes contribuyan con lo que se esté desarrollando en ese repositorio. Para ello, tenemos a nuestra disposición el comando merge. Merge, a diferencia de rebase, toma todos los commits de la rama y los fusiona con los commits de la otra rama. De esta forma, hay commits cuya presencia es visible en varias ramas, o en una rama y el tronco del árbol, según lo apliquemos. Demostremos su funcionamiento en el siguiente ejercicio.
Mientras preparábamos la lista de la compra con los ingredientes necesarios para hacer una ensalada, ha venido una pandemia que ha activado el estado de alarma en todo el país y ha puesto a todos sus habitantes en cuarentena. Debemos preparar todo lo necesario para no salir de casa nunca más, y para ello haremos otra lista de la compra.
Cuando hacemos merge, la rama desde la que tomamos cambios no se elimina. Podemos seguir trabajando en esa rama, seguir trabajando en master, y llamar a merge y rebase tantas veces como sea necesario. Para eliminar una rama, se puede usar el comando git branch -d. Por ejemplo: git branch -d pollo
No obstante, en esta serie de tutoriales no trataremos la eliminación de ramas, tags o commits.
Esto es todo por el momento. En la próxima entrega, empezaremos a conocer GitHub y veremos cómo clonar un repositorio público. ¡Feliz martes!
Skor: +1
Esto si me interesa, leyendo voy mirando e imaginando como quedan las cosas, así que jithub se usa desde consola.
Vaya y con comandos, parece fácil, pero se requiere trabajo. Vaya.
Skor: +0
¡Hola!
El otro día dije que comenzaríamos a hacer cosas con repositorios remotos, pero me he dado cuenta de que me dejé algo importante, así que vamos a acabarlo primero. ¿Qué pasa cuando las cosas salen mal y provocamos un conflicto? Vamos a verlo.
En ocasiones nos vamos a encontrar situaciones que los comandos reset y clean no van a poder arreglar. Por ejemplo, imaginemos que hacemos un commit cambiando un par de líneas de un archivo, y cuando nos descargamos los cambios más recientes del servidor, descubrimos que otra persona se nos ha adelantado y ha manipulado las mismas líneas del mismo archivo. Aunque Git es relativamente inteligente, hay cosas que se le escapan, y esta es una de ellas. Afortunadamente, en la consola se nos indicará qué ha salido mal y qué podemos hacer para remediarlo. Los comandos varían, dependiendo de si estamos haciendo merge o rebase.
En el siguiente ejercicio, vamos a utilizar el repositorio de la lista de la compra para provocar un conflicto. A continuación, vamos a resolverlo.
<<<<<<< HEAD
6 kg de lechuga
Para resolver este conflicto, debemos elegir la línea que sea más adecuada para lo que queremos conseguir. En ocasiones, no basta con seleccionar una de las dos opciones que se nos presentan, hay que tomar cambios de ambos lados y crear un cambio totalmente nuevo. Para facilitar la tarea, decidimos quedarnos con la segunda opción, 7 kg de lechuga.
¡Mucho cuidado! Si hacemos commit o continuamos con la operación de rebase sin haber resuelto los conflictos, Git no lo sabrá y pensará que los hemos arreglado. El sistema de descarga de complementos de la comunidad internacional de NVDA estuvo caído durante varias semanas por culpa de un conflicto que se dejó sin resolver. En medio del archivo get.php, había líneas <<<<<<< HEAD, ======= y >>>>>>> master, algo que al intérprete PHP no le sentó demasiado bien.
Esto es todo por el momento. Si os gusta, escribid en el hilo y seguimos adelante!
Skor: +0
Como fue lo de NVDA?
Skor: +0
Como he dicho más arriba. No voy a dar más detalles. Pasó, se arregló y ahora todo está bien. Además pasó hace mucho.
Skor: +0
Otro que se guarda el tema. Gracias por el currazo.
Skor: +0
Hola, subo hilo para preguntar:
¿Habrá más capítulos?
Gracias por la atención de antemano :D
Skor: +0
lo mismo que kabo erain,
donde están más capítulos? se que la gente tiene cosas que hacer(pa que luego no me salten los de siempre) pero esto tenía un gran camino que pena que hayan como 2 meces de inactividad u. :(
Skor: +0
Solo puedo decirque estoy enormemente agradecido, este hilo ayudó a muchos a usar git, o a refrescar como es mi caso. Con lo que vieron ya es un paso enorme, se pueden ya gestionar repositorios muy bien. Claro, hacen falta cositas, pero son ya cosas un poco extremas.
Skor: +0
Sí, habrá más, pero estas semanas he tenido bastante lío. Perdón por eso.
Skor: +0
¡me encantó esto!
No conocía este hilo, yo uso github por ahí para algunas cosas, y sin duda esto sirbe mucho para gestionarlo mejor. Gracias pichón.
Skor: +0
Acabo de practicar todo esto. Ha salido bien, así que espero el próximo capítulo y aquí tengo los dos repositorios de la lista de la compra y el reglamento.
Ahora que soy el principal mantenedor de la traducción al inglés de un complemento para NVDA, supe que necesito aprender a usar Git y GitHub para trabajar mucho mejor.
Skor: +0
Poslednja izmena od strane carlospianista3, 5 Sep 2021 20:48:01
¡Hola!
Vamos a seguir con esto, ¿no? Que ya llevaba demasiado tiempo aparcado, y eso no se puede consentir. Hoy aprenderemos cosas de Github, pero aún no es necesario registrarse allí. Eso lo veremos en el próximo capítulo. ¡Empecemos!
GitHub es una plataforma web colaborativa construida alrededor de Git y todo lo que nos ofrece. Los usuarios pueden publicar allí sus repositorios, interactuar con otros usuarios, corregir fallos o aplicar mejoras en otros proyectos, y aceptar cambios en su propio código procedentes de otras personas. Si bien es cierto que GitHub es la plataforma más popular de este tipo, no es la única. Tenemos también GitLab o BitBucket. Todas ellas tienen características en común, pero en cada una existen pros y contras. Por ejemplo, GitLab se puede instalar en cualquier servidor, mientras que para hacer eso con GitHub hay que pagar una suscripción de empresa.
La interfaz web de GitHub, a priori, puede ser bastante compleja. Accesible, por supuesto, pero compleja. El hecho de que sólo esté en inglés tampoco lo pone nada fácil. Por suerte, y para agilizar las cosas, tenemos a nuestra disposición un importante aliado: la barra de direcciones del navegador. Las direcciones son muy sencillas de construir, como veremos enseguida.
En GitHub, cada usuario u organización tiene una dirección propia y única, que se corresponde con el nombre de usuario elegido. Cuando visitamos el perfil de un usuario, podemos ver qué repositorios tiene, sus últimas contribuciones a otros proyectos, su actividad y todo lo que nos quiera contar de sí mismo en los distintos campos del perfil (nombre, país de origen, biografía...). Pongamos algunos ejemplos.
Como se puede ver, es muy fácil acceder al perfil de un usuario conociendo su nombre. Por este motivo, y aunque es posible, no se recomienda cambiar el nombre de usuario. Lo ideal es que se quede como está para siempre.
Si queremos ver todos los repositorios que tiene, añadimos el sufijo ?tab=repositories. La dirección de nvda-es podría quedar así: https://github.com/nvda-es?tab=repositories
Para acceder a un repositorio, se incluye el nombre de dicho repositorio después del nombre de usuario, intercalando una barra entre ellos. Este sería el repositorio de NVDA: https://github.com/nvaccess/nvda
Al acceder a un repositorio, veremos un montón de opciones. Una de las que más nos puede interesar es el archivo léame, que los desarrolladores suelen situar en la raíz del repositorio para que GitHub lo muestre. Lo encontraremos después de un encabezado de nivel 2, que suele llamarse Readme.md. En el repositorio del lector de pantalla Habla, el contenido del archivo readme.md es fácilmente identificable porque está en español, pero no es lo habitual. El sufijo md, por su parte, indica que el archivo está escrito en sintaxis Markdown, que luego GitHub se encarga de traducir a HTML cuando cargamos la página.
GitHub nos permite descargar el código fuente alojado en un repositorio de distintas maneras. La más común para quienes no usan Git es descargar un archivo zip con los contenidos. Sin embargo, esto no nos va a permitir ver el historial de los cambios, hacer un seguimiento del trabajo realizado o colaborar por nuestra cuenta. En esta ocasión, vamos a aprender sólo a descargar un repositorio, pero sin colaborar enviando cambios. Más adelante veremos cómo clonar por SSH, hacer un fork y enviar nuestros propios commits.
Para descargar un repositorio, utilizaremos el comando clone. Su sintaxis es la siguiente: git clone URL_del_repositorio
NVDA es un proyecto bastante activo, por lo que nos servirá para descargar el código fuente y actualizarlo cuando alguien haga cambios. Para descargar el código fuente de NVDA, sigue estos pasos:
A veces, un proyecto es tan complejo y tiene tantos equipos de desarrollo, que lo ideal es dividir sus componentes entre varios repositorios. De hecho, el proyecto puede depender de repositorios de terceros con los que no tenemos relación alguna. Sin embargo, es importante mantenerlos conectados entre sí. Un submódulo es un repositorio que se aloja en una carpeta dentro de otro repositorio. En esta guía no aprenderemos a crearlos, pero sí a descargarlos y mantenerlos actualizados. Vamos a completar la descarga del código fuente de NVDA. Para ello, primero vamos a inicializar los submódulos, y luego a descargarlos todos a la vez. La lista de submódulos de un repositorio se puede encontrar en el archivo .gitmodules, dentro de la carpeta raíz. Es perfectamente legible con editores de texto plano, como el bloc de notas.
Ahora que tenemos descargado un repositorio, es importante mantenerlo al día con los últimos cambios. Podríamos borrarlo y clonarlo otra vez, pero este enfoque no parece muy práctico. Por suerte, Git lo tiene todo previsto. Vamos a conocer el comando git pull.
Git pull busca los cambios más recientes del origen remoto asociado a la rama actual, los descarga, los inserta en la base de datos del repositorio local y los integra en nuestro directorio de trabajo, haciendo avanzar el HEAD o cursor de posición. Gracias a git log, podremos estudiar el historial y saber qué ha cambiado desde la última vez que actualizamos o clonamos. Vamos a actualizar NVDA para recibir los últimos commits de la rama master. Se recomienda esperar unos días para poder descargar cambios.
¡Y esto es todo por hoy! En el próximo mensaje crearemos una cuenta en GitHub, la configuraremos, y sabremos qué son las incidencias y las pull requests y cómo explorarlas.
¡Espero que os haya gustado!
Skor: +0
hola resien comienso a leer la entrada como puedo ver la guía completa, la verdad nunca habia entrado a esta sección de la sala me interesaría la guía saludos.
Skor: +0
Pulsa abrir esta discusión en la web, puede ser un buen punto de partida.
Skor: +0
Hola, hoy me puse al día con los últimos 2 posts, esto seguro me ayudará para no peder mi pequeño cacharro jaja.
Skor: +0
Yo quiero saber y creo que se abordará en el próximo post, ¿cómo hago para configurar git con mi usuario de github? He estado buscando información pero no logro comprender bien como es que se hace.
Skor: +0
Muchas gracias @el_pichon, excelente trabajo y muy bien explicado. Me había perdido este hilo.
Skor: +0
Poslednja izmena od strane kvothe, 13 Sep 2021 09:57:52
@coachJos: En git, antes de hacer commits pusiste un correo, con:git config --global user.email x@y.z
Si te registras con ese mismo correo a github, o lo añades a tu usuario desde la configuración de tu cuenta, tus commits quedan asociados a tu usuario.
Skor: +0
Aaah, ya, muchas gracias por la respuesta.
Skor: +0
Sí, pero yo creo que está preguntando por la autenticación a la hora de enviar cambios. Aviso que en esa parte me voy a olvidar de https y voy a ir con ssh a tope, por lo que espero que todo el mundo que está siguiendo esta guía tenga su clave generada.
Skor: +0
Eso presisamente me confunde, pues en github lei que es recomendable trabajar con http en lugar de ssh.
Skor: +0
No. De hecho, https se está empezando a marcar como obsoleto e inseguro a la hora de enviar cambios. Lo ideal es usarlo únicamente para clonar repositorios que vayas a mirar de otras personas. Para clonar los tuyos propios, ssh sin duda. Por cierto, se me olvidó decirlo antes: he editado el post 1 explicando cómo actualizar Git a la última versión cómodamente desde consola. El comando que allí se menciona sólo funcionará en Windows, no existe en ninguna otra plataforma.
Skor: +0
Sí, acabo de ver el comando, yo prefiero usar la versión portable de git for windows, sabes si existe algún comando para actualizarla automáticamente.
Skor: +0
Podrías probar con ese mismo. Nunca he usado Git en modo portable, te obliga a emplear Mintty como terminal. Ya nos contarás si funciona.
Skor: +0
No, la versión portable también trae la consola CMD, el comando no funciona, lo que hace es que instala git. Ahora tengo una duda, como puedo verificar que los commits y tags si se están firmando, pues no me solicita la passfreis cuando hago commits o tags.
Skor: +0
He investigado un poco, y esto se resuelve con los comandos git verify-commit y git verify-tag. Hay que pasar el identificador del commit o el tag. Por ejemplo:
git commit-verify HEAD
Esto dará la información gpg asociada al commit actual, si la hay.
Información extraída de aquí: https://stackoverflow.com/questions/17371955/verifying-signed-git-commits
Voy a preparar el siguiente capítulo, que esto continúa!
Skor: +0
Muchas gracias, lo logré solucionar eliminando la configuración anterior y volviendo a hacer todo el proceso nuevamente, Estoy pendiente del próximo capítulo. Me adelaanté un poco y me creé una cuenta pero en gitlab, me pareció más intuitiva que github la interfaz web.
Skor: +0
¡Hola!
Hoy avanzaremos en esta serie de pequeños tutoriales adentrándonos en el mundo de GitHub. Crearemos una cuenta de usuario, y haremos algo verdaderamente útil con las claves ssh y gpg que generamos al principio. Preparados, listos... ¡vamos!
Como dijimos anteriormente, GitHub es la plataforma colaborativa de repositorios Git más popular y conocida. Es hora de hacerse una cuenta allí y mostrar el fruto de nuestro trabajo a la comunidad.
Ahora ya tenemos una cuenta en GitHub, ¡primer paso conseguido! Sin embargo, aún no queda muy claro cómo se va a comunicar Git con ella. Y firmar los commits y los tags, aunque es útil, tampoco va a ayudar a GitHub a que marque nuestro trabajo como verificado... a menos que agreguemos allí nuestras claves. Vamos a ello.
Ahora, Git podrá comunicarse desde la consola con GitHub. Gracias a la clave, GitHub sabrá que somos nosotros sin tener que introducir usuario ni contraseña. Vamos con la clave gpg.
Agregar una clave GPG a nuestra cuenta se parece mucho a lo que acabamos de hacer con la clave SSH. Sin embargo, obtener la clave pública no es tan sencillo en este caso. Deberemos recurrir a la consola Git Bash:
Como paso opcional, aunque todavía está en fase beta, se recomienda activar el Vigilant mode. Para ello, simplemente hay que marcar la casilla que está en la página de gestión de claves.
Para comprobar que podemos comunicarnos correctamente con GitHub, ejecutaremos el siguiente comando desde la consola: ssh git@github.com
Como es la primera vez que conectamos con este servidor, el cliente ssh preguntará si confiamos en él. Para decirle que sí, escribimos yes y pulsamos intro. A continuación, ssh preguntará por nuestra contraseña de la clave. Al escribir la contraseña, el resultado no se reflejará en pantalla, por lo que parecerá que no estamos escribiendo nada. Sin embargo, sí lo estamos haciendo.
Si todo ha ido bien, GitHub nos saludará diciéndonos que no nos puede ofrecer una consola, pero incluirá nuestro nombre de usuario en el saludo, indicando que la conexión se ha hecho bien.
Llega la última sección de este capítulo, y el primer paso hacia un sinfín de aventuras. En este ejercicio, crearemos nuestro primer repositorio en GitHub, lo clonaremos, haremos cambios en él y los publicaremos. ¡Empecemos!
Ahora, tenemos en nuestra cuenta de GitHub un repositorio. Dentro de él, se encuentra un único archivo: readme.md. Vamos a clonar dicho repositorio. En los próximos pasos, se asume que el nick elegido en GitHub es usuario. Las URLs para clonar repositorios por SSH son muy distintas a las que vimos en el capítulo anterior, pero comienzan exactamente igual. Por tanto, será fácil familiarizarse con ellas.
¡Esto es todo por hoy! En la próxima entrega, rellenaremos el perfil de GitHub para que quede más presentable, y aprenderemos a abrir incidencias. Mientras tanto, ¿alguien se anima a compartir lo que ha hecho en este hilo? Yo me he tenido que hacer una cuenta llamada jmdaweb-pruebas, porque hace años que tengo perfil ahí y no sabía si el formulario habría cambiado. Por cierto, y antes de que alguien lo pregunte: esto que hemos hecho con las claves ssh y gpg también sirve en Gitlab y Bitbucket. El procedimiento es exactamente el mismo, con las pequeñas diferencias que se puedan presentar en cada interfaz. También se pueden clonar por ssh los repositorios de otras personas, no sólo los nuestros. Cualquier repositorio público es accesible por https y ssh.
¡Hasta la próxima!
Skor: +0
Poslednja izmena od strane el_pichon, 18 Sep 2021 17:37:12
95 poruka, 4 stranica: 12 3 4 ↖ Vrati se nazad na listu tema
Morate da se prijavite kako biste mogli da pišete