Git Y GitHub

En nuestra terminal usamos git para guardar nuestros proyectos, github nos permite tener un flujo de trabajo practico, con git podemos hacer ramas, remotos, fuciones y mucho mas, a continuacion vamos a ver todo lo que podemos ver en git ygithub, podemos trabajar muchas versionaes sin dañar ninguna, y trabajar de manera eficiente en equipo.

sistema de control de veriones

Git, creado por linux , guarda los cambios sin importar cuantos sean

Algunos comandos y sus funciones:

• git init : Empieza en tu carpeta un repositorio para guardar los cambios.
• git add “nombre del archivo” : Agrega ese archivo o cambio al “Staging Area”
• git commit -m “Versión 1” : Agrega finalmente el cambio realizado y le agrega un mensaje con -m
• git add . : Agrega todos los archivos a ese Staging Area
• git commit -m “Cambios a v1” : Aplica los cambios realizados.
• git status : Muestra el estado de tu respositorio
• git show : Muestra el historico de los cambios hechos
• git log “nombre del archivo” : Muestra el historial de ese archivo
• git push : Envia hacia un repositorio remoto
• git pull : Trae de un repositorio remoto a tu local

¿Cómo instalar git en windows?

Buscamos en google git y lo descargamos, en la parte de git bash debemos asegurarnos que sea asi, solo damos next, estas opciones son debido a que normalmente no se usa en windows el desarrollo, se usa mas que todo linux o sistemas basados en unix, pero con git bash podemos trabajar en windows, de esta manera trabajamos en una terminal emulada de windows.

Debemos asegurarnos de indicar git from the command line and also from 3rd-party software

Dando next llegamos a la libreria que debemos usar es use the OpenSSLlibrary, damos next y usamos la primera version checkout windows style-commit unix style-line ending,next y usamos sistema use MinTTY, seguimos dando next hasta llegar a install.Escojemos la siguiemte pantalla Launch git bash y posteriormente nos abre una consola interna parecida a la de linux, podemos empezar a interactuar con comandos como ls ,pwd, cd. Para buscarla vamos a nuestro inicio y bucamos Git Bash , alli abrira nuestra terminal.

¿Cómo intalar git en Mac?

Ingresamos anuestro safari y buscamos git, lo descargamos y una vez vemos una cajita que contiene nuestro programa ,le damos doble click a este paquete para abrir , en ocaciones nos niega la apertura ya que dice ser de un desarrollador no identificado, si te aparece asi solo das ok, clik derecho y open, open y abres , colocas continue, install, contraseña y se permite la instalacion.

Para abrirla solo das en el buscador terminal y enter, alli vas abrir tu ventana de terminal, alli puedes escribir comandos como git, que te va a mostrar la informacion de git, asi vas a confirmar que tu descarga fue efectiva y correcta o git –version y te muestra la version exacta que tienes.

¿Cómo intalar git en Linux?

sudo apt-get update es actualizar todos los archivos. sudo apt-get install git y de esta manera ya instalamos nuestro git, podemos verificarlo en git –version y te muestra la version exacta que tienes.

Editores de código, archivos binarios y de texto plano

“Un editor de código es una herramienta que nos brinda muchas ayudas para escribir código, algo así como un bloc de notas muy avanzado. Los editores más populares son VSCode, Sublime Text y Atom, pero no necesariamente debes usar alguno de estos para continuar con el curso.

Tipos de archivos y sus diferencias:

Archivos de Texto (.txt): Texto plano normal y sin nada especial. Lo vemos igual sin importar dónde lo abrImos, ya sea con el bloc de notas o con editores de texto avanzados.

Archivos RTF (.rtf): Podemos guardar texto con diferentes tamaños, estilos y colores. Pero si lo abrimos desde un editor de código, vamos a ver que es mucho más complejo que solo el texto plano. Esto es porque debe guardar todos los estilos del texto y, para esto, usa un código especial un poco difícil de entender y muy diferente a los textos con estilos especiales al que estamos acostumbrados.

Archivos de Word (.docx): Podemos guardar imágenes y texto con diferentes tamaños, estilos o colores. Al abrirlo desde un editor de código podemos ver que es código binario, muy difícil de entender y muy diferente al texto al que estamos acostumbrados. Esto es porque Word está optimizado para entender este código especial y representarlo gráficamente.

Recuerda que debes habilitar la opción de ver la extensión de los archivos, de lo contrario, solo podrás ver su nombre. La forma de hacerlo en Windows es Vista > Mostrar u ocultar > Extensiones de nombre de archivo.”

tomado de John Freddy vega

Descargamos en google o safari nuestro visual code que es el mas popular como editor de codigo.

¿Qué es el staging y los repositorios? Ciclo básico de trabajo en Git

Para iniciar un repositorio, o sea, activar el sistema de control de versiones de Git en tu proyecto, solo debes ejecutar el comando git init.

Este comando se encargará de dos cosas: primero, crear una carpeta .git, donde se guardará toda la base de datos con cambios atómicos de nuestro proyecto; y segundo, crear un área que conocemos como Staging, que guardará temporalmente nuestros archivos (cuando ejecutemos un comando especial para eso) y nos permitirá, más adelante, guardar estos cambios en el repositorio (también con un comando especial).

Ciclo de vida o estados de los archivos en Git:

Cuando trabajamos con Git nuestros archivos pueden vivir y moverse entre 4 diferentes estados (cuando trabajamos con repositorios remotos pueden ser más estados, pero lo estudiaremos más adelante):

• Archivos Tracked: son los archivos que viven dentro de Git, no tienen cambios pendientes y sus últimas actualizaciones han sido guardadas en el repositorio gracias a los comandos git add y git commit.

• Archivos Staged: son archivos en Staging. Viven dentro de Git y hay registro de ellos porque han sido afectados por el comando git add, aunque no sus últimos cambios. Git ya sabe de la existencia de estos últimos cambios, pero todavía no han sido guardados definitivamente en el repositorio porque falta ejecutar el comando git commit.

• Archivos Unstaged: entiéndelos como archivos “Tracked pero Unstaged”. Son archivos que viven dentro de Git pero no han sido afectados por el comando git add ni mucho menos por git commit. Git tiene un registro de estos archivos, pero está desactualizado, sus últimas versiones solo están guardadas en el disco duro.

• Archivos Untracked: son archivos que NO viven dentro de Git, solo en el disco duro. Nunca han sido afectados por git add, así que Git no tiene registros de su existencia.

Recuerda que hay un caso muy raro donde los archivos tienen dos estados al mismo tiempo:staged y untracked.

Esto pasa cuando guardas los cambios de un archivo en el área de Staging (con el comando git add), pero antes de hacer commit para guardar los cambios en el repositorio haces nuevos cambios que todavía no han sido guardados en el área de Staging (en realidad, todo sigue funcionando igual pero es un poco divertido).

Comandos para mover archivos entre los estados de Git:

• git status: nos permite ver el estado de todos nuestros archivos y carpetas.
• git add: nos ayuda a mover archivos del Untracked o Unstaged al estado Staged. Podemos usar git nombre-del-archivo-o-carpeta para añadir archivos y carpetas individuales o git add -A para mover todos los archivos de nuestro proyecto (tanto Untrackeds como unstageds).
• git reset HEAD: nos ayuda a sacar archivos del estado Staged para devolverlos a su estado anterior. Si los archivos venían de Unstaged, vuelven allí. Y lo mismo se venían de Untracked.
• git commit: nos ayuda a mover archivos de Unstaged a Staged. Esta es una ocasión especial, los archivos han sido guardado o actualizados en el repositorio. Git nos pedirá que dejemos un mensaje para recordar los cambios que hicimos y podemos usar el argumento -m para escribirlo (git commit -m “mensaje”).

• git rm: este comando necesita alguno de los siguientes argumentos para poder ejecutarse correctamente:

  • git rm –cached: Mueve los archivos que le indiquemos al estado Untracked.

  • git rm –force: Elimina los archivos de Git y del disco duro. Git guarda el registro de la existencia de los archivos, por lo que podremos recuperarlos si es necesario (pero debemos usar comandos más avanzados).

  ¿Qué es un Branch (rama) y cómo funciona un Merge en Git?

Git es una base de datos muy precisa con todos los cambios y crecimiento que ha tenido nuestro proyecto. Los commits son la única forma de tener un registro de los cambios. Pero las ramas amplifican mucho más el potencial de Git.

Todos los commits se aplican sobre una rama. Por defecto, siempre empezamos en la rama master (pero puedes cambiarle el nombre si no te gusta) y creamos nuevas ramas, a partir de esta, para crear flujos de trabajo independientes.

Crear una nueva rama se trata de copiar un commit (de cualquier rama), pasarlo a otro lado (a otra rama) y continuar el trabajo de una parte específica de nuestro proyecto sin afectar el flujo de trabajo principal (que continúa en la rama master o la rama principal).

Los equipos de desarrollo tienen un estándar: Todo lo que esté en la rama master va a producción, las nuevas features, características y experimentos van en una rama “development” (para unirse a master cuando estén definitivamente listas) y los issues o errores se solucionan en una rama “hotfix” para unirse a master tan pronto como sea posible.

Crear una nueva rama lo conocemos como Checkout. Unir dos ramas lo conocemos como Merge.

Podemos crear todas las ramas y commits que queramos. De hecho, podemos aprovechar el registro de cambios de Git para crear ramas, traer versiones viejas del código, arreglarlas y combinarlas de nuevo para mejorar el proyecto.

Solo ten en cuenta que combinar estas ramas (sí, hacer “merge”) puede generar conflictos. Algunos archivos pueden ser diferentes en ambas ramas. Git es muy inteligente y puede intentar unir estos cambios automáticamente, pero no siempre funciona. En algunos casos, somos nosotros los que debemos resolver estos conflictos “a mano”.

Crea un repositorio de Git y haz tu primer commit

Si quieres ver los archivos ocultos de una carpeta puedes habilitar la opción de Vista > Mostrar u ocultar > Elementos ocultos (en Windows) o ejecutar el comando ls -a.

Le indicaremos a Git que queremos crear un nuevo repositorio para utilizar su sistema de control de versiones. Solo debemos posicionarnos en la carpeta raíz de nuestro proyecto y ejecutar el comando git init.

Recuerda que al ejecutar este comando (y de aquí en adelante) vamos a tener una nueva carpeta oculta llamada .git con toda la base de datos con cambios atómicos en nuestro proyecto.

Recuerda que Git está optimizado para trabajar en equipo, por lo tanto, debemos darle un poco de información sobre nosotros. No debemos hacerlo todas las veces que ejecutamos un comando, basta con ejecutar solo una sola vez los siguientes comandos con tu información:

git config --global user.email "tu@email.com"
git config --global user.name "Tu Nombre" 

Existen muchas otras configuraciones de Git que puedes encontrar ejecutando el comando git config –list (o solo git config para ver una explicación más detallada).

Analizar cambios en los archivos de tu proyecto con Git

El comando git show nos muestra los cambios que han existido sobre un archivo y es muy útil para detectar cuándo se produjeron ciertos cambios, qué se rompió y cómo lo podemos solucionar. Pero podemos ser más detallados.

Si queremos ver la diferencia entre una versión y otra, no necesariamente todos los cambios desde la creación del archivo, podemos usar el comando git diff commitA commitB.

Recuerda que puedes obtener el ID de tus commits con el comando git log.

si se te olvida agrgar un comentario dentro de un commit, puedes escribirlo en el momento que te pide escribir el comentario y sales con esc shift zz , lo puedes usar con vim tambien

Volver en el tiempo en nuestro repositorio utilizando branches y checkout

El comando git checkout + ID + archivo nos permite viajar en el tiempo. Podemos volver a cualquier versión anterior de un archivo específico o incluso del proyecto entero. Esta también es la forma de crear ramas y movernos entre ellas.

También hay una forma de hacerlo un poco más “ruda”: usando el comando git reset. En este caso, no solo “volvemos en el tiempo”, sino que borramos los cambios que hicimos después de este commit.

Hay dos formas de usar git reset: con el argumento –hard, borrando toda la información que tengamos en el área de staging (y perdiendo todo para siempre). O, un poco más seguro, con el argumento –soft, que mantiene allí los archivos del área de staging para que podamos aplicar nuestros últimos cambios pero desde un commit anterior.

git log –stat podemos ver los commits con los cambios especificos.

Git reset vs. Git rm

Texto: @juandc

Git reset y git rm son comandos con utilidades muy diferentes, pero aún así se confunden muy fácilmente.

• git rm Este comando nos ayuda a eliminar archivos de Git sin eliminar su historial del sistema de versiones. Esto quiere decir que si necesitamos recuperar el archivo solo debemos “viajar en el tiempo” y recuperar el último commit antes de borrar el archivo en cuestión.

Recuerda que git rm no puede usarse así nomás. Debemos usar uno de los flags para indicarle a Git cómo eliminar los archivos que ya no necesitamos en la última versión del proyecto:

• git rm –cached: Elimina los archivos del área de Staging y del próximo commit pero los mantiene en nuestro disco duro.

• git rm –force: Elimina los archivos de Git y del disco duro. Git siempre guarda todo, por lo que podemos acceder al registro de la existencia de los archivos, de modo que podremos recuperarlos si es necesario (pero debemos usar comandos más avanzados).

git reset

Este comando nos ayuda a volver en el tiempo. Pero no como git checkout que nos deja ir, mirar, pasear y volver. Con git reset volvemos al pasado sin la posibilidad de volver al futuro. Borramos la historia y la debemos sobreescribir. No hay vuelta atrás.

Este comando es muy peligroso y debemos usarlo solo en caso de emergencia. Recuerda que debemos usar alguna de estas dos opciones:

Hay dos formas de usar git reset: con el argumento –hard, borrando toda la información que tengamos en el área de staging (y perdiendo todo para siempre). O, un poco más seguro, con el argumento –soft, que mantiene allí los archivos del área de staging para que podamos aplicar nuestros últimos cambios pero desde un commit anterior.

• git reset –soft: Borramos todo el historial y los registros de Git pero guardamos los cambios que tengamos en Staging, así podemos aplicar las últimas actualizaciones a un nuevo commit.

• git reset –hard: Borra toda la información de los commits y del área de staging se borra del historial.

git reset HEAD: Este es el comando para sacar archivos del área de Staging. No para borrarlos ni nada de eso, solo para que los últimos cambios de estos archivos no se envíen al último commit, a menos que cambiemos de opinión y los incluyamos de nuevo en staging con git add.

Si usamos git reset HEAD, lo único que haremos será mover cambios de Staging a Unstaged. Seguiremos teniendo los últimos cambios del archivo, el repositorio mantendrá el archivo (no con sus últimos cambios pero sí con los últimos en los que hicimos commit) y no habremos perdido nada

Introducción a las ramas o branches de Git

Las ramas son la forma de hacer cambios en nuestro proyecto sin afectar el flujo de trabajo de la rama principal. Esto porque queremos trabajar una parte muy específica de la aplicación o simplemente experimentar.

La cabecera o HEAD representan la rama y el commit de esa rama donde estamos trabajando. Por defecto, esta cabecera aparecerá en el último commit de nuestra rama principal. Pero podemos cambiarlo al crear una rama (git branch rama, git checkout -b rama) o movernos en el tiempo a cualquier otro commit de cualquier otra rama con los comandos (git reset id-commit, git checkout rama-o-id-commit).

Recuerda que al ejecutar el comando git checkout para cambiar de rama o commit puedes perder el trabajo que no hayas guardado. Guarda tus cambios antes de hacer git checkout.

podemos guardar nuestros cambios con git commit -am mensajeque queramos y esto da por entendido el git add, esto nos simplifica el proceso de commit

Recuerda que puedes borrar commits con git reset y ramas con git branch -d

Solución de conflictos al hacer un merge

Git es muy inteligente y puede resolver algunos conflictos automáticamente: cambios, nuevas líneas, entre otros. Pero algunas veces no sabe cómo resolver estas diferencias, por ejemplo, cuando dos ramas diferentes hacen cambios distintos a una misma línea.

Esto lo conocemos como conflicto y lo podemos resolver manualmente, solo debemos hacer el merge, ir a nuestro editor de código y elegir si queremos quedarnos con alguna de estas dos versiones o algo diferente. Algunos editores de código como VSCode nos ayudan a resolver estos conflictos sin necesidad de borrar o escribir líneas de texto, basta con hundir un botón y guardar el archivo.

Recuerda que siempre debemos crear un nuevo commit para aplicar los cambios del merge. Si Git puede resolver el conflicto hará commit automáticamente. Pero, en caso de no pueda resolverlo, debemos solucionarlo y hacer el commit.

Los archivos con conflictos por el comando git merge entran en un nuevo estado que conocemos como Unmerged. Funcionan muy parecido a los archivos en estado Unstaged, algo así como un estado intermedio entre Untracked y Unstaged, solo debemos ejecutar git add para pasarlos al área de staging y git commit para aplicar los cambios en el repositorio.

Uso de GitHub

GitHub es una plataforma que nos permite guardar repositorios de Git que podemos usar como servidores remotos y ejecutar algunos comandos de forma visual e interactiva (sin necesidad de la consola de comandos).

Luego de crear nuestra cuenta, podemos crear o importar repositorios, crear organizaciones y proyectos de trabajo, descubrir repositorios de otras personas, contribuir a esos proyectos, dar estrellas y muchas otras cosas.

El README.md es el archivo que veremos por defecto al entrar a un repositorio. Es una muy buena práctica configurarlo para describir el proyecto, los requerimientos y las instrucciones que debemos seguir para contribuir correctamente.

Para clonar un repositorio desde GitHub (o cualquier otro servidor remoto) debemos copiar la URL (por ahora, usando HTTPS) y ejecutar el comando git clone + la URL que acabamos de copiar. Esto descargara la versión de nuestro proyecto que se encuentra en GitHub.

Sin embargo, esto solo funciona para las personas que quieren empezar a contribuir en el proyecto. Si queremos conectar el repositorio de GitHub con nuestro repositorio local, el que creamos con git init, debemos ejecutar las siguientes instrucciones:

git remote add origin URL
git remote
git remote -v
git pull origin master 
git push origin master

Debemos asegurarnos que estamos en el lugar correcto, es decir en la carpeta correcta con pwd

• git remote: nos relaciona con la URL de github
• git remote: nos muestra un origin que fue creado
• git remote -v: nos muestra la opcion de traer información y de enviar información
• git pull origin master: trae la información de github “–allow-unrelated-histories” se usa para traer por primera vez tus archivos e integrar de github a visual.
• git push origin master: permite enviar la información a github

Tags y versiones en Git y GitHub

Los tags o etiquetas nos permiten asignar versiones a los commits con cambios más importantes o significativos de nuestro proyecto.

git log –all muestra todos los commits git log –all –graph muestra ademas las ramitas que se han realizado git log –all –graph –decorate –oneline muestra todo más comprimido con los id y la historia en nuestro archivo

Para simplificar este codigo y trabajr siempre con el podemos ponerle un alias como un nombre arbolito asi: alias arbolito=”git log –all –graph –decorate –oneline” y en el momento de escribir arbolito, nos muestra toda la lista que encerramos en ese nombre.

Comandos para trabajar con etiquetas:

• Crear un nuevo tag y asignarlo a un commit: git tag -a nombre -m”mensaje del commit.
• Borrar un tag en el repositorio local: git tag -d nombretag.
• Listar los tags de nuestro repositorio local: git tag o git show-ref –tags.
• Publicar un tag en el repositorio remoto: git push origin –tags.
• Borrar un tag del repositorio remoto: git tag -d nombretag y git push origin :refs/tags/nombreStag.

Manejo de ramas en GitHub

Puedes trabajar con ramas que nunca envias a GitHub, así como pueden haber ramas importantes en GitHub que nunca usas en el repositorio local. Lo importantes que aprendas a manejarlas para trabajar profesionalmente.

• Crear una rama en el repositorio local: git branch nombrerama o git checkout -b nombrerama.
• Publicar una rama local al repositorio remoto: git push origin nombrerama. Recuerda que podemos ver gráficamente nuestro entorno y flujo de trabajo local con Git usando el comando gitk.

con git show branch –all muestra las ramas con detalle

Configurar múltiples colaboradores en un repositorio de GitHub

Por defecto, cualquier persona puede clonar o descargar tu proyecto desde GitHub, pero no pueden crear commits, ni ramas, ni nada.

Existen varias formas de solucionar esto para poder aceptar contribuciones. Una de ellas es añadir a cada persona de nuestro equipo como colaborador de nuestro repositorio.

Solo debemos entrar a la configuración de colaboradores de nuestro proyecto (Repositorio > Settings > Collaborators) y añadir el email o username de los nuevos colaboradores.

Flujo de trabajo profesional con Pull requests

En un entorno profesional normalmente se bloquea la rama master, y para enviar código a dicha rama pasa por un code review y luego de su aprobación se unen códigos con los llamados merge request.

Para realizar pruebas enviamos el código a servidores que normalmente los llamamos staging develop (servidores de pruebas) luego de que se realizan las pruebas pertinentes tanto de código como de la aplicación estos pasan a el servidor de producción con el ya antes mencionado merge request.

Creando un Fork, contribuyendo a un repositorio

El fork es para personas que no están como colaboradores, sin embargo pueden pedir y colaborar desde afuera, allí hace fork tomando una copia actual del proyecto, al hacer fork puedo ver todos los cambios que ha tenido el proyecto, luego para llevarlo a local, debe ir clone or dowland en el repositorio propio, y copiar la url , ir a la terminal git clone y la url, como es publica la trae completa.

Allí puedo entrar a la carpeta y codificarla , luego de los cambios hacer git add . git commit -m “mensaje” git pull para buenas prácticas y git push para subirlo a nuestro github

Allí ya esta el repositorio con los cambios que adecue desde mi terminal, y para hacer un pull request que seria como un permiso para que hicieran merge a esos cambios, debo ir a pull request y new pull request, escoje las ramas que necesito usar que seria la que clone y la que modifique, le doy clonar y hago commit , cierro con create pull request .

De esta manera envío los cambios desde afuera del proyecto

Ignorar archivos en el repositorio con .gitignore

No todos los archivos que agregas a un proyecto deberían ir a un repositorio, por ejemplo cuando tienes un archivo donde están tus contraseñas que comúnmente tienen la extensión .env o cuando te estás conectando a una base de datos; son archivos que nadie debe ver.

Hay que tener en cuenta que no se deben subir fotos a nuestro github, ya que son archivos muy pesados, para esto desde nuestra terminal debemos usar un new file .gitignore alli supongamos quiero ignorar una foto le colocamos *.jpg allí se ignora las fotos que se suban con push a nuestro github desde este archivo

Readme.md es una excelente práctica

README.md es una excelente práctica en tus proyectos, md significa Markdown es un especie de código que te permite cambiar la manera en que se ve un archivo de texto.

Lo interesante de Markdown es que funciona en muchas páginas, por ejemplo la edición en Wikipedia; es un lenguaje intermedio que no es HTML, no es texto plano, es una manera de crear excelentes texto formateados.

volver al indice