├── assets ├── 0001.jpg ├── 0002.jpg ├── 0003.jpg ├── 0004.jpg ├── 0005.jpg ├── 0006.jpg ├── 0007.jpg ├── 0008.jpg ├── 0009.jpg ├── 0010.jpg ├── 0011.jpg └── 0012.jpg └── README.md /assets/0001.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bryan2811/Curso-de-Git-y-Github-Platzi/HEAD/assets/0001.jpg -------------------------------------------------------------------------------- /assets/0002.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bryan2811/Curso-de-Git-y-Github-Platzi/HEAD/assets/0002.jpg -------------------------------------------------------------------------------- /assets/0003.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bryan2811/Curso-de-Git-y-Github-Platzi/HEAD/assets/0003.jpg -------------------------------------------------------------------------------- /assets/0004.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bryan2811/Curso-de-Git-y-Github-Platzi/HEAD/assets/0004.jpg -------------------------------------------------------------------------------- /assets/0005.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bryan2811/Curso-de-Git-y-Github-Platzi/HEAD/assets/0005.jpg -------------------------------------------------------------------------------- /assets/0006.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bryan2811/Curso-de-Git-y-Github-Platzi/HEAD/assets/0006.jpg -------------------------------------------------------------------------------- /assets/0007.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bryan2811/Curso-de-Git-y-Github-Platzi/HEAD/assets/0007.jpg -------------------------------------------------------------------------------- /assets/0008.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bryan2811/Curso-de-Git-y-Github-Platzi/HEAD/assets/0008.jpg -------------------------------------------------------------------------------- /assets/0009.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bryan2811/Curso-de-Git-y-Github-Platzi/HEAD/assets/0009.jpg -------------------------------------------------------------------------------- /assets/0010.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bryan2811/Curso-de-Git-y-Github-Platzi/HEAD/assets/0010.jpg -------------------------------------------------------------------------------- /assets/0011.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bryan2811/Curso-de-Git-y-Github-Platzi/HEAD/assets/0011.jpg -------------------------------------------------------------------------------- /assets/0012.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bryan2811/Curso-de-Git-y-Github-Platzi/HEAD/assets/0012.jpg -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ![preview-couse](https://miro.medium.com/max/2732/1*mtsk3fQ_BRemFidhkel3dA.png) 2 | 3 | # Curso de Git y Github en Platzi 🔥 4 | - **PDF del curso:** [Git-Github](https://static.platzi.com/media/public/uploads/git-github_917f1c24-de6d-4d30-99ca-f47214e6ae16.pdf) 5 | 6 | ## Temario 7 | 8 | ### Introducción a Git 9 | 10 | - [Usar un sistema de control de versiones como Git](#usar-un-sistema-de-control-de-versiones-como-git) 11 | - [Instalando Git y GitBash en Windows](#instalando-git-y-gitbash-en-windows) 12 | - [Pasos](#pasos) 13 | - [Instalando Git en OSX](#instalando-git-en-osx) 14 | - [Instalando Git en Linux](#instalando-git-en-linux) 15 | - [Tipos de archivos y sus diferencias](#tipos-de-archivos-y-sus-diferencias) 16 | - [Introducción a la terminal y línea de comandos](#introducci%c3%b3n-a-la-terminal-y-l%c3%adnea-de-comandos) 17 | - [Diferencias entre la estructura de archivos de Windows, Mac o Linux.](#diferencias-entre-la-estructura-de-archivos-de-windows-mac-o-linux) 18 | - [Comandos básicos en la terminal:](#comandos-b%c3%a1sicos-en-la-terminal) 19 | 20 | ### Comandos básicos en Git 21 | - [Qué es staging, repositorios y cuál es el ciclo básico de trabajo en GitHub](#qu%c3%a9-es-staging-repositorios-y-cu%c3%a1l-es-el-ciclo-b%c3%a1sico-de-trabajo-en-github) 22 | - [Ciclo de vida o estados de los archivos en Git:](#ciclo-de-vida-o-estados-de-los-archivos-en-git) 23 | - [Comandos para mover archivos entre los estados de Git:](#comandos-para-mover-archivos-entre-los-estados-de-git) 24 | - [Qué es un Branch (rama) y cómo funciona un Merge en Git](#qu%c3%a9-es-un-branch-rama-y-c%c3%b3mo-funciona-un-merge-en-git) 25 | - [Crea un repositorio de Git y haz tu primer commit](#crea-un-repositorio-de-git-y-haz-tu-primer-commit) 26 | - [Analizar cambios en los archivos de tu proyecto con Git](#analizar-cambios-en-los-archivos-de-tu-proyecto-con-git) 27 | - [Volver en el tiempo en nuestro repositorio utilizando branches y checkout](#volver-en-el-tiempo-en-nuestro-repositorio-utilizando-branches-y-checkout) 28 | - [git reset vs git rm](#git-reset-vs-git-rm) 29 | - [git rm](#git-rm) 30 | 31 | ### Flujo de trabajo básico en Git 32 | - [Flujo de trabajo básico con un repositorio remoto](#flujo-de-trabajo-b%c3%a1sico-con-un-repositorio-remoto) 33 | - [Introducción a las ramas o branches de Git](#introducci%c3%b3n-a-las-ramas-o-branches-de-git) 34 | - [Fusión de ramas con Git merge](#fusi%c3%b3n-de-ramas-con-git-merge) 35 | - [Solución de conflictos al hacer un merge](#soluci%c3%b3n-de-conflictos-al-hacer-un-merge) 36 | 37 | ### Trabajando con repositorios remotos en Github 38 | - [Uso de Github](#uso-de-github) 39 | - [Cómo funcionan las llaves públicas y privadas](#c%c3%b3mo-funcionan-las-llaves-p%c3%bablicas-y-privadas) 40 | - [Configura tus llaves SSH en local](#configura-tus-llaves-ssh-en-local) 41 | - [En Windows y Linux:](#en-windows-y-linux) 42 | - [En Mac](#en-mac) 43 | - [Conexión a GitHub con SSH](#conexi%c3%b3n-a-github-con-ssh) 44 | - [Tags y versiones en Git y GitHub](#tags-y-versiones-en-git-y-github) 45 | - [Manejo de ramas en GitHub](#manejo-de-ramas-en-github) 46 | - [Ver gráficamente nuestro entorno y flujo de trabajo local en Git](#ver-gr%c3%a1ficamente-nuestro-entorno-y-flujo-de-trabajo-local-en-git) 47 | - [Configurar múltiples colaboradores en un repositorio de GitHub](#configurar-m%c3%baltiples-colaboradores-en-un-repositorio-de-github) 48 | 49 | ### Flujos de trabajo profesionales 50 | - [Flujo de trabajo profesional con Pull requests](#flujo-de-trabajo-profesional-con-pull-requests) 51 | - [Caso ejemplo: Error tipográfico en la rama master](#caso-ejemplo-error-tipogr%c3%a1fico-en-la-rama-master) 52 | - [Ignorar archivos en el respositorio con .gitignore](#ignorar-archivos-en-el-respositorio-con-gitignore) 53 | - [Readme.md es una excelente práctica](#readmemd-es-una-excelente-pr%c3%a1ctica) 54 | - [Tu sitio web público con GitHub Pages](#tu-sitio-web-p%c3%bablico-con-github-pages) 55 | 56 | ### Multiples entornos de trabajo 57 | - [Git Rebase: Reorganizando el trabajo realizado](#git-rebase-reorganizando-el-trabajo-realizado) 58 | - [Git Stash: Guardar cambios en memoria y recuperarlos después](#git-stash-guardar-cambios-en-memoria-y-recuperarlos-despu%c3%a9s) 59 | - [Git Clean: Limpiar tu proyecto de archivos no deseados](#git-clean-limpiar-tu-proyecto-de-archivos-no-deseados) 60 | - [Git cherry-pick: Traer commits viejos al head de un branch](#git-cherry-pick-traer-commits-viejos-al-head-de-un-branch) 61 | 62 | ### Comandos en Git para casos de emergencia 63 | - [Reconstruír commits en Git con amend](#reconstru%c3%adr-commits-en-git-con-amend) 64 | - [Git Reset y Reflog: Úsese en caso de emergencia](#git-reset-y-reflog-%c3%9asese-en-caso-de-emergencia) 65 | - [Buscar en archivos y commits de Git con Grep y log](#buscar-en-archivos-y-commits-de-git-con-grep-y-log) 66 | - [Comandos y recursos colaborativos en Git y Github](#comandos-y-recursos-colaborativos-en-git-y-github) 67 | 68 | ## Usar un sistema de control de versiones como Git 69 | 70 | Un sistema de control de versiones como Git nos ayuda a guardar el historial de cambios y crecimiento de los archivos de nuestro proyecto. 71 | 72 | En realidad, los cambios y diferencias entre las versiones de nuestros proyectos pueden tener similitudes, algunas veces los cambios pueden ser solo una palabra o una parte específica de un archivo específico. Git está optimizado para guardar todos estos cambios de forma atómica e incremental, o sea, aplicando cambios sobre los últimos cambios, estos sobre los cambios anteriores y así hasta el inicio de nuestro proyecto. 73 | 74 | El comando para iniciar nuestro repositorio, o sea, indicarle a Git que queremos usar su sistema de control de versiones en nuestro proyecto, es **`git init`**. 75 | 76 | El comando para que nuestro repositorio sepa de la existencia de un archivo o sus últimos cambios es **`git add`**. Este comando no almacena las actualizaciones de forma definitiva, solo las guarda en algo que conocemos como **“Staging Area”** 77 | 78 | El comando para almacenar definitivamente todos los cambios que por ahora viven en el staging area es **git commit**. También podemos guardar un mensaje para recordar muy bien qué cambios hicimos en este commit con el argumento **`-m "Mensaje del commit"`.** 79 | 80 | **TIP:** 81 | **Se puede usar `git commit -am "Mensaje del commit"` para hacer `git add .` y `git commit -m "Mensaje"` al mismo tiempo!** 82 | 83 | Por último, si queremos mandar nuestros commits a un servidor remoto, un lugar donde todos podamos conectar nuestros proyectos, usamos el comando **`git push`**. 84 | 85 | ## Instalando Git y GitBash en Windows 86 | 87 | Windows y Linux comandos diferentes, graban el enter de formas diferentes y tienen muchas otras diferencias. Cuando instales Git Bash en Windows debes elegir si prefieres trabajar con la forma de Windows o la forma de UNIX (Linux y Mac) . 88 | 89 | Ten en cuenta que, normalmente, los entornos de desarrollo profesionales tienen personas que usan sistemas operativos diferentes. Esto significa que, si todos podemos usar los mismos comandos, el trabajo resultará más fácil para todos en el equipo. 90 | 91 | Los comandos de UNIX son los más comunes entre los equipos de desarrollo. Así que, a menos que trabajes con tecnologías nativas de Microsoft (por ejemplo, .NET), la recomendación es que elijas la opción de la terminal tipo UNIX para obtener una mejor compatibilidad con todo tu equipo. 92 | 93 | ### Pasos 94 | 95 | 1. **Ir a la página de Github:** https://git-scm.com/downloads 96 | 2. **Iniciar el instalador** 97 | - Asegurarse te marcar la opción **Git Bash** 98 | - **Activar TrueType** (Mejora las fuentes cuando usas la línea de comandos) 99 | - Marcar **Git from the command line and also from 3rd party software** (Recomendado) 100 | - Marcar **use the OpenSSL library** 101 | - Marcar **checkout Windows-style, commit unix-style line endings** (Compatibilidad con UNIX y Linux) 102 | - Marcar **MinTTY** 103 | - Ejecutar **Git Bash** 104 | 105 | ## Instalando Git en OSX 106 | 107 | La instalación de GIT en Mac es un poco más sencilla. No debemos instalar GitBash porque Mac ya trae por defecto una consola de comandos **(la puedes encontrar como “Terminal”)**. Tampoco debemos configurar OpenSSL porque viene listo por defecto. 108 | 109 | OSX está basado en un Kernel de UNIX llamado **BSD**. Estos significa que hay algunas diferencias entre las consolas de Mac y Linux. Pero no vas a notar la diferencia a menos que trabajes con acceso profundo a las interfaces de red o los archivos del sistema operativo. Ambas consolas funcionan muy parecido y comparten los comandos que vamos a ver durante el curso. 110 | 111 | - **Puedes descargar Git aquí**: https://git-scm.com 112 | 113 | Puedes verificar que Git fue instalado correctamente con el comando **`git --version`**. 114 | 115 | ## Instalando Git en Linux 116 | 117 | Cada distribución de Linux tiene un comando especial para instalar herramientas y actualizar el sistema. 118 | 119 | **Cada distribución tiene su comando especial y debes averiguar cómo funciona para poder instalar Git.** 120 | 121 | - En las distribuciones derivadas de Debian **(como Ubuntu)** el comando especial es **`apt-get`** 122 | - En **Red Hat** es **`yum`** y en **`ArchLinux`** es **`pacman`**. 123 | 124 | Antes de hacer la instalación, debemos hacer una actualización del sistema. En nuestro caso, los comandos para hacerlo son **`sudo apt-get update`** y **`sudo apt-get upgrade`**. 125 | 126 | Con el sistema actualizado, ahora sí podemos instalar Git y, en este caso, el comando para hacerlo es **`sudo apt-get install git`**. También puedes verificar que Git fue instalado correctamente con el comando **`git --version`**. 127 | 128 | Editores de código, archivos binarios y de texto plano 129 | 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. 130 | 131 | ## Tipos de archivos y sus diferencias 132 | 133 | **Archivos de Texto (.txt):** Texto plano normal y sin nada especial. Lo vemos igual sin importar dónde lo abramos, ya sea con el bloc de notas o con editores de texto avanzados. 134 | 135 | **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. 136 | 137 | **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. 138 | 139 | Recuerda que debes habilitar la opción de ver la extensión de los archivos, de lo contrario, solo podrás ver su nombre. 140 | 141 | **La forma de hacerlo en Windows es Vista > Mostrar u ocultar > Extensiones de nombre de archivo**. 142 | 143 | ## Introducción a la terminal y línea de comandos 144 | 145 | ### Diferencias entre la estructura de archivos de Windows, Mac o Linux. 146 | 147 | **La ruta principal en Windows es C:/** 148 | **en UNIX es solo /** 149 | 150 | **Windows no hace diferencia entre mayúsculas y minúsculas pero UNIX sí.** 151 | 152 | **Recuerda que GitBash usa la ruta /c para dirigirse a C:\ (o /d para dirigirse a D:/ ) 153 | en Windows. Por lo tanto, la ruta del usuario con el que estás trabajando es /C/Users/Nombre de tu usuario** 154 | 155 | ### Comandos básicos en la terminal: 156 | 157 | - **pwd:** Nos muestra la ruta de carpetas en la que te encuentras ahora mismo. 158 | - **mkdir:** Nos permite crear carpetas (por ejemplo, mkdir Carpeta-Importante). 159 | - touch: Nos permite crear archivos (por ejemplo, touch archivo.txt). 160 | - **rm:** Nos permite borrar un archivo o carpeta (por ejemplo, rm archivo.txt). Mucho cuidado con este comando, puedes borrar todo tu disco duro. 161 | - **cat:** Ver el contenido de un archivo (por ejemplo, cat nombre-archivo.txt). 162 | - **ls:** Nos permite cambiar ver los archivos de la carpeta donde estamos ahora mismo. Podemos usar uno o más argumentos para ver más información sobre estos archivos (los argumentos pueden ser -- + el nombre del argumento o - + una sola letra o shortcut por cada argumento). 163 | - **ls -a:** Mostrar todos los archivos, incluso los ocultos. 164 | - **ls -l:** Ver todos los archivos como una lista. 165 | - **cd:** Nos permite navegar entre carpetas. 166 | - **cd /:** Ir a la ruta principal: 167 | - **cd o cd ~:** Ir a la ruta de tu usuario 168 | - **cd carpeta/subcarpeta:** Navegar a una ruta dentro de la carpeta donde estamos ahora mismo. 169 | - **cd .. (cd + dos puntos)**: Regresar una carpeta hacia atrás. 170 | - Si quieres referirte al directorio en el que te encuentras ahora mismo puedes usar **cd . (cd + un punto)**. 171 | - **history:** Ver los últimos comandos que ejecutamos y un número especial con el que podemos repetir su ejecución. 172 | - **! + número:** Ejecutar algún comando con el número que nos muestra el comando history **(por ejemplo, !72)**. 173 | - **clear:** Para limpiar la terminal. También podemos usar los atajos de teclado **Ctrl + L o Command + L**. 174 | 175 | **Todos estos comandos tiene una función de autocompletado, o sea, puedes escribir la primera parte y presionar la tecla Tab para que la terminal nos muestre todas las posibles carpetas o comandos que podemos ejecutar. Si presionas la tecla Arriba puedes ver el último comando que ejecutamos.** 176 | 177 | **Recuerda que podemos descubrir todos los argumentos de un comando con el argumento --help (por ejemplo, cat --help).** 178 | 179 | ## Qué es staging, repositorios y cuál es el ciclo básico de trabajo en GitHub 180 | 181 | **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`.** 182 | 183 | **Este comando se encargará de dos cosas:** 184 | 185 | - Primero, crear una carpeta **.git** donde se guardará toda la base de datos con cambios atómicos de nuestro proyecto. 186 | - Segundo, crear un área en la memoria RAM, 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)**. 187 | 188 | ### Ciclo de vida o estados de los archivos en Git: 189 | 190 | ![ciclo de vida en git](https://git-scm.com/book/en/v2/images/lifecycle.png "ciclo de vida en git") 191 | 192 | 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):** 193 | 194 | **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. 195 | 196 | **Archivos Unstaged:** Entiendelos 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. 197 | 198 | **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`**. 199 | 200 | **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`.** 201 | 202 | **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).** 203 | 204 | ### Comandos para mover archivos entre los estados de Git: 205 | 206 | - **git status:** Nos permite ver el estado de todos nuestros archivos y carpetas. 207 | 208 | - **git add:** Nos ayuda a mover archivos del Untracked o Unstaged al estado Staged. Podemos usar **`git add 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).** 209 | 210 | - **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**. 211 | 212 | - **git commit:** Nos ayuda a mover archivos de **Staged a Tracked**. 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"**). 213 | 214 | - **git rm:** Este comando necesita alguno de los siguientes argumentos para poder ejecutarse correctamente: 215 | - **git rm --cached:** Mueve los archivos que le indiquemos al estado **Untracked.** 216 | - **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).** 217 | 218 | ## Qué es un Branch (rama) y cómo funciona un Merge en Git 219 | 220 | ![Preview Branches](https://static.platzi.com/media/public/uploads/branches_f9d7e237-6a15-4143-a4e9-cc5af06be833.PNG) 221 | 222 | 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. 223 | 224 | 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. 225 | 226 | 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).** 227 | 228 | **Los equipos de desarrollo tienen un estándar:** 229 | - **Todo lo que esté en la rama master va a producción.** 230 | - **Las nuevas features, características y experimentos van en una rama “development” (para unirse a master cuando estén definitivamente listas).** 231 | - **Y los issues o errores se solucionan en una rama “hotfix” para unirse a master tan pronto como sea posible.** 232 | 233 | **Crear una nueva rama lo conocemos como Checkout. 234 | Unir dos ramas lo conocemos como Merge.** 235 | 236 | 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. 237 | 238 | 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”.** 239 | 240 | ## Crea un repositorio de Git y haz tu primer commit 241 | 242 | **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.** 243 | 244 | 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`**. 245 | 246 | 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. 247 | 248 | 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: 249 | ``` 250 | git config --global user.email "tu@email.com" 251 | git config --global user.name "Tu Nombre" 252 | git config --global color.ui true 253 | ``` 254 | 255 | 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).** 256 | 257 | ## Analizar cambios en los archivos de tu proyecto con Git 258 | 259 | 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. 260 | 261 | 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`**. 262 | 263 | Recuerda que puedes obtener el ID de tus commits con el comando **`git log`**. 264 | 265 | ## Volver en el tiempo en nuestro repositorio utilizando branches y checkout 266 | 267 | El comando **`git checkout + ID del commit`** 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.** 268 | 269 | 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. 270 | 271 | **Hay dos formas de usar git reset:** 272 | - **Con el argumento `--hard`, borrando toda la información que tengamos en el área de staging (y perdiendo todo para siempre).** 273 | **- 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.** 274 | 275 | ## git reset vs git rm 276 | 277 | **Git reset y git rm son comandos con utilidades muy diferentes, pero aún así se confunden muy fácilmente.** 278 | 279 | ### git rm 280 | 281 | 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. 282 | 283 | 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: 284 | 285 | - **git rm --cached:** Elimina los archivos del área de Staging y del próximo commit pero los mantiene en nuestro disco duro. 286 | - **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)**. 287 | -**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. 288 | 289 | **Este comando es muy peligroso y debemos usarlo solo en caso de emergencia. Recuerda que debemos usar alguna de estas dos opciones:** 290 | 291 | **Hay dos formas de usar git reset:** 292 | - con el argumento **`--hard`**, borrando toda la información que tengamos en el área de staging **(y perdiendo todo para siempre)**. 293 | - 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. 294 | 295 | - **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. 296 | - **git reset --hard:** Borra todo. Todo todito, absolutamente todo. Toda la información de los commits y del área de staging se borra del historial. 297 | 298 | **¡Pero todavía falta algo!** 299 | 300 | **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, por supuesto.** 301 | 302 | **¿Por que esto es importante?** 303 | **Imagina el siguiente caso:** 304 | 305 | Hacemos cambios en los archivos de un proyecto para una nueva actualización. Todos los archivos con cambios se mueven al área de staging con el comando **`git add`**. Pero te das cuenta de que uno de esos archivos no está listo todavía. Actualizaste el archivo pero ese cambio no debe ir en el próximo commit por ahora. 306 | 307 | **¿Qué podemos hacer**? 308 | 309 | Bueno, todos los cambios están en el área de Staging, incluido el archivo con los cambios que no están listos. Esto significa que debemos sacar ese archivo de Staging para poder hacer commit de todos los demás. 310 | 311 | ¡Al usar **`git rm`** lo que haremos será eliminar este archivo completamente de git! Todavía tendremos el historial de cambios de este archivo, con la eliminación del archivo como su última actualización. Recuerda que en este caso no buscábamos eliminar un archivo, solo dejarlo como estaba y actualizarlo después, no en este commit. 312 | 313 | En cambio, si usamos **`git reset HEAD`**, lo único que haremos será mover estos 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. 314 | 315 | **Conclusión: Lo mejor que puedes hacer para salvar tu puesto y evitar un incendio en tu trabajo es conocer muy bien la diferencia y los riesgos de todos los comandos de Git.** 316 | 317 | ## Flujo de trabajo básico con un repositorio remoto 318 | 319 | ![preview-1](assets/0001.jpg) 320 | ![preview-1](assets/0002.jpg) 321 | ![preview-1](assets/0003.jpg) 322 | ![preview-1](assets/0004.jpg) 323 | ![preview-1](assets/0005.jpg) 324 | ![preview-1](assets/0006.jpg) 325 | ![preview-1](assets/0007.jpg) 326 | ![preview-1](assets/0008.jpg) 327 | ![preview-1](assets/0009.jpg) 328 | ![preview-1](assets/0010.jpg) 329 | ![preview-1](assets/0011.jpg) 330 | ![preview-1](assets/0012.jpg) 331 | 332 | 333 | Por ahora, nuestro proyecto vive únicamente en nuestra computadora. Esto significa que no hay forma de que otros miembros del equipo trabajen en él. 334 | 335 | **Para solucionar esto están los servidores remotos:** un nuevo estado que deben seguir nuestros archivos para conectarse y trabajar con equipos de cualquier parte del mundo. 336 | 337 | Estos servidores remotos pueden estar alojados en **GitHub, GitLab, BitBucket, entre otros**. Lo que van a hacer es guardar el mismo repositorio que tienes en tu computadora y darnos una URL con la que todos podremos acceder a los archivos del proyecto para descargarlos, hacer cambios y volverlos a enviar al servidor remoto para que otras personas vean los cambios, comparen sus versiones y creen nuevas propuestas para el proyecto. 338 | 339 | **Esto significa que debes aprender algunos nuevos comandos:** 340 | 341 | - **`git clone url_del_servidor_remoto`:** Nos permite descargar los archivos de la última versión de la rama principal y todo el historial de cambios en la carpeta .git. 342 | - **`git push`:** Luego de hacer git add y git commit debemos ejecutar este comando para mandar los cambios al servidor remoto. 343 | - **`git fetch`:** Lo usamos para traer actualizaciones del servidor remoto y guardarlas en nuestro repositorio local (en caso de que hayan, por supuesto). 344 | - **`git merge`:** También usamos el comando git fetch con servidores remotos. Lo necesitamos para combinar los últimos cambios del servidor remoto y nuestro directorio de trabajo. 345 | - **`git pull`:** Básicamente, git fetch y git merge al mismo tiempo. 346 | 347 | ## Introducción a las ramas o branches de Git 348 | 349 | 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. 350 | 351 | 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:** 352 | ``` 353 | git branch rama 354 | git checkout -b rama 355 | ``` 356 | 357 | **O movernos en el tiempo a cualquier otro commit de cualquier otra rama con los comandos:** 358 | ``` 359 | git reset id-commit 360 | git checkout rama-o-id-commit 361 | ``` 362 | 363 | **O eliminar una rama desde Git:** 364 | ``` 365 | git branch -D nombre-de-la-rama 366 | ``` 367 | 368 | 369 | ## Fusión de ramas con Git merge 370 | 371 | El comando **`git merge`** nos permite crear un nuevo commit con la combinación de dos ramas **(la rama donde nos encontramos cuando ejecutamos el comando y la rama que indiquemos después del comando).** 372 | 373 | **Crear un nuevo commit en la rama master combinando** 374 | **los cambios de la rama cabecera:** 375 | ``` 376 | git checkout master 377 | git merge cabecera 378 | ``` 379 | 380 | **Crear un nuevo commit en la rama cabecera combinando los cambios de cualquier otra rama:** 381 | ``` 382 | git checkout cabecera 383 | git merge cualquier-otra-rama 384 | ``` 385 | 386 | Asombroso, ¿verdad? Es como si Git tuviera super poderes para saber qué cambios queremos conservar de una rama y qué otros de la otra. El problema es que no siempre puede adivinar, sobretodo en algunos casos donde dos ramas tienen actualizaciones diferentes en ciertas líneas en los archivos. Esto lo conocemos como un conflicto y aprenderemos a solucionarlos en la siguiente clase. 387 | 388 | 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`**. 389 | 390 | ## Solución de conflictos al hacer un merge 391 | 392 | **Git nunca borra nada a menos que nosotros se lo indiquemos.** Cuando usamos los comandos **`git merge`** o **`git checkout`** estamos cambiando de rama o creando un nuevo commit, no borrando ramas ni commits **(recuerda que puedes borrar commits con `git reset` y ramas con `git branch -d`)**. 393 | 394 | 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.** 395 | 396 | 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. 397 | 398 | 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. 399 | 400 | 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. 401 | 402 | ## Uso de Github 403 | 404 | 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). 405 | 406 | 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. 407 | 408 | 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. 409 | 410 | 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. 411 | 412 | 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: 413 | 414 | **Primero: Guardar la URL del repositorio de GitHub con el nombre de origin:** 415 | ``` 416 | git remote add origin URL 417 | ``` 418 | 419 | **Segundo: Verificar que la URL se haya guardado correctamente:** 420 | ``` 421 | git remote 422 | git remote -v 423 | ``` 424 | 425 | **Tercero: Traer la versión del repositorio remoto y hacer merge para crear un commit con los archivos de ambas partes:** 426 | 427 | **Podemos usar:** 428 | ``` 429 | git fetch y git merge 430 | ``` 431 | **O solo:** 432 | ``` 433 | git pull origin master --allow-unrelated-histories 434 | ``` 435 | **Por último, ahora sí podemos hacer git push para guardar los cambios de nuestro repositorio local en GitHub:** 436 | ``` 437 | git push origin master 438 | ``` 439 | 440 | 441 | ## Cómo funcionan las llaves públicas y privadas 442 | 443 | **Las llaves públicas y privadas nos ayudan a cifrar y descifrar nuestros archivos de forma que los podamos compartir archivos sin correr el riesgo de que sean interceptados por personas con malas intenciones.** 444 | 445 | **La forma de hacerlo es la siguiente:** 446 | 447 | 1. Ambas personas deben crear su llave pública y privada. 448 | 2. Ambas personas pueden compartir su llave pública a las otras partes **(recuerda que esta llave es pública, no hay problema si la “interceptan”).** 449 | 3. La persona que quiere compartir un mensaje puede usar la llave pública de la otra persona para cifrar los archivos y asegurarse que solo puedan ser descifrados con la llave privada de la persona con la que queremos compartir el mensaje. 450 | 4. El mensaje está cifrado y puede ser enviado a la otra persona sin problemas en caso de que los archivos sean interceptados. 451 | 5. La persona a la que enviamos el mensaje cifrado puede usar su llave privada para descifrar el mensaje y ver los archivos. 452 | 453 | **Puedes compartir tu llave pública pero nunca tu llave privada.** 454 | 455 | ## Configura tus llaves SSH en local 456 | 457 | **Primer paso: Generar tus llaves SSH. Recuerda que es muy buena idea proteger tu llave privada con una contraseña.** 458 | ``` 459 | ssh-keygen -t rsa -b 4096 -C "tu@email.com" 460 | ``` 461 | **Segundo paso: Terminar de configurar nuestro sistema.** 462 | #### En Windows y Linux: 463 | 464 | 1. **Encender el "servidor" de llaves SSH de tu computadora:** 465 | ``` 466 | eval $(ssh-agent -s) 467 | ``` 468 | 2. **Añadir tu llave SSH a este "servidor":** 469 | ``` 470 | ssh-add ruta-donde-guardaste-tu-llave-privada 471 | ``` 472 | 473 | #### En Mac 474 | 475 | 1. **Encender el "servidor" de llaves SSH de tu computadora:** 476 | ``` 477 | eval "$(ssh-agent -s)" 478 | ``` 479 | 480 | **Si usas una versión de OSX superior a Mac Sierra (v10.12) 481 | debes crear o modificar un archivo "config" en la carpeta 482 | de tu usuario con el siguiente contenido (ten cuidado con 483 | las mayúsculas):** 484 | ``` 485 | Host * 486 | AddKeysToAgent yes 487 | UseKeychain yes 488 | IdentityFile ruta-donde-guardaste-tu-llave-privada 489 | ``` 490 | 491 | 2. **Añadir tu llave SSH al "servidor" de llaves SSH de tu 492 | computadora (en caso de error puedes ejecutar este 493 | mismo comando pero sin el argumento -K):** 494 | ``` 495 | ssh-add -K ruta-donde-guardaste-tu-llave-privada 496 | ``` 497 | 498 | ## Conexión a GitHub con SSH 499 | 500 | Luego de crear nuestras llaves SSH podemos entregarle la llave pública a GitHub para comunicarnos de forma segura y sin necesidad de escribir nuestro usuario y contraseña todo el tiempo. 501 | 502 | Para esto debes entrar a la Configuración de Llaves SSH en GitHub, crear una nueva llave con el nombre que le quieras dar y el contenido de la llave pública de tu computadora. 503 | 504 | Ahora podemos actualizar la URL que guardamos en nuestro repositorio remoto, solo que, en vez de guardar la URL con HTTPS, vamos a usar la URL con SSH: 505 | ``` 506 | git remote add origin URL 507 | ``` 508 | **O para configurar nuevamente una nueva URL** 509 | ``` 510 | git remote set-url origin url-ssh-del-repositorio-en-github 511 | ``` 512 | 513 | ## Tags y versiones en Git y GitHub 514 | 515 | Los tags o etiquetas nos permiten asignar versiones a los commits con cambios más importantes o significativos de nuestro proyecto. 516 | 517 | **Comandos para trabajar con etiquetas:** 518 | 519 | - **Crear un nuevo tag y asignarlo a un commit:** 520 | ``` 521 | git tag -a nombre-del-tag id-del-commit 522 | ``` 523 | - **Borrar un tag en el repositorio local:** 524 | ``` 525 | git tag -d nombre-del-tag 526 | ``` 527 | - **Listar los tags de nuestro repositorio local:** 528 | ``` 529 | git tag o git show-refs --tags 530 | ``` 531 | - **Publicar un tag en el repositorio remoto:** 532 | ``` 533 | git push origin --tags 534 | ``` 535 | - **Borrar un tag del repositorio remoto:** 536 | ``` 537 | git tag -d nombre-del-tag 538 | ``` 539 | ``` 540 | git push origin :refs/tags/nombre-del-tag 541 | ``` 542 | 543 | ## Manejo de ramas en GitHub 544 | 545 | 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. 546 | 547 | **Crear una rama en el repositorio local:** 548 | ``` 549 | git branch nombre-de-la-rama 550 | ``` 551 | ``` 552 | git checkout -b nombre-de-la-rama 553 | ``` 554 | 555 | **Publicar una rama local al repositorio remoto:** 556 | 557 | ``` 558 | git push origin nombre-de-la-rama 559 | ``` 560 | 561 | **Eliminar ramas remotas desde Git:** 562 | 563 | Puedes borrar la rama remota desde git utilizando este comando: 564 | 565 | ``` 566 | git push nombre-remoto :nombre-de-la-rama 567 | ``` 568 | 569 | **Por ejemplo, si quieres borrar la rama bugfix del servidor, puedes utilizar:** 570 | 571 | ``` 572 | git push origin :bugfix 573 | ``` 574 | 575 | ## Ver gráficamente nuestro entorno y flujo de trabajo local en Git 576 | 577 | Recuerda que podemos ver gráficamente nuestro entorno y flujo de trabajo local con Git usando el comando **`gitk`** 578 | 579 | ## Configurar múltiples colaboradores en un repositorio de GitHub 580 | 581 | Por defecto, cualquier persona puede clonar o descargar tu proyecto desde GitHub, pero no pueden crear commits, ni ramas, ni nada. 582 | 583 | 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. 584 | 585 | 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. 586 | 587 | ## Flujo de trabajo profesional con Pull requests 588 | ![PR](https://static.platzi.com/media/public/uploads/flujodetrabprofbranches_96136aab-1884-4a9a-8b1e-83421630464d.PNG) 589 | 590 | 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.** 591 | 592 | 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.** 593 | 594 | ## Caso ejemplo: Error tipográfico en la rama master 595 | 596 | ``` 597 | $ git branch fix-typo 598 | $ git checkout fix-typo 599 | ``` 600 | 601 | **Luego de solucionar el problema:** 602 | ``` 603 | $ git commit… 604 | $ git push origin fix-typo 605 | ``` 606 | 607 | **Luego se crea un nuevo Pull Request de master con fix-typo (En GitHub)** 608 | 609 | Se puede asignar el Pull Request a un miembro, o agregar miembros para que le hagan review, luego hay que "Crear el pull request" y el request pasa al proceso de: **Code Review** 610 | 611 | Los reviewers pueden pedir cambios o aprobar el **Pull Request**, al terminar esto, quien sea que este a cargo de realizar los merge, debe realizarlo. 612 | **(Se debe respetar quien es el que hace los merges para tener consistencia en los Code Reviews).** 613 | Ya después se puede borrar el branch fix-typo de GitHub dependiendo de las prácticas de cada equipo. 614 | 615 | ## Ignorar archivos en el respositorio con .gitignore 616 | 617 | 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. 618 | 619 | ## Readme.md es una excelente práctica 620 | 621 | 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. 622 | 623 | 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. 624 | 625 | ## Tu sitio web público con GitHub Pages 626 | 627 | GitHub tiene un servicio de hosting gratis llamado GitHub Pages, tu puedes tener un repositorio donde el contenido del repositorio se vaya a GitHub y se vea online. 628 | 629 | ## Git Rebase: Reorganizando el trabajo realizado 630 | 631 | El comando `rebase` es **una mala práctica, nunca se debe usar**, pero para efectos de curso te lo vamos a enseñar para que hagas tus propios experimentos. **Con rebase puedes recoger todos los cambios confirmados en una rama y ponerlos sobre otra.** 632 | 633 | **Cambiamos a la rama que queremos traer los cambios:** 634 | ``` 635 | git checkout experiment 636 | ``` 637 | 638 | **Aplicamos rebase para traer los cambios de la rama que queremos:** 639 | ``` 640 | git rebase master 641 | ``` 642 | 643 | ## Git Stash: Guardar cambios en memoria y recuperarlos después 644 | 645 | Cuando necesitamos regresar en el tiempo porque borramos alguna línea de código pero no queremos pasarnos a otra rama porque nos daría un error ya que debemos pasar ese **“mal cambio”** que hicimos a stage, podemos usar `git stash` para regresar el cambio anterior que hicimos. 646 | 647 | `git stash` es típico cuando estamos cambios que no merecen una rama o no merecen un rebase si no simplemente estamos probando algo y luego quieres volver rápidamente a tu versión anterior la cual es la correcta. 648 | 649 | ![git-stash](https://static.platzi.com/media/user_upload/lol-05d691f0-6747-4697-babf-51fb46ccdf7c.jpg) 650 | 651 | ## Git Clean: Limpiar tu proyecto de archivos no deseados 652 | 653 | A veces creamos archivos cuando estamos realizando nuestro proyecto que realmente no forman parte de nuestro directorio de trabajo, que no se debería agregar y lo sabemos. 654 | 655 | **Para saber qué archivos vamos a borrar tecleamos:** 656 | ``` 657 | git clean --dry-run 658 | ``` 659 | 660 | **Para borrar todos los archivos listados (que no son carpetas) tecleamos:** 661 | ``` 662 | git clean -f 663 | ``` 664 | 665 | ## Git cherry-pick: Traer commits viejos al head de un branch 666 | 667 | Existe un mundo alternativo en el cual vamos avanzando en una rama pero necesitamos en master uno de esos avances de la rama, para eso utilizamos el comando `git cherry-pick IDCommit` 668 | 669 | ## Reconstruír commits en Git con amend 670 | 671 | A veces hacemos un commit, pero resulta que no queríamos mandarlo porque faltaba algo más. Utilizamos `git commit --amend`, **amend en inglés es remendar** y lo que hará es que los cambios que hicimos nos lo agregará al commit anterior. 672 | 673 | Si el caso es que únicamente olvidamos incluir archivos al commit **y el mensaje que habíamos ingresado estaba bien**, también podríamos ejecutar el siguiente comando: 674 | ``` 675 | gitcommit--amend--no-edit 676 | ``` 677 | 678 | Con el `--no-edit` además de todo lo que significa el `--amend` estamos diciéndole a git que utilice el mensaje que ya habíamos ingresado. 679 | 680 | ## Git Reset y Reflog: Úsese en caso de emergencia 681 | 682 | ¿Qué pasa cuando todo se rompe y no sabemos qué está pasando? Con git reset HashDelHEAD nos devolveremos al estado en que el proyecto funcionaba. 683 | 684 | git reset --soft HashDelHEAD te mantiene lo que tengas en staging ahí. 685 | git reset --hard HashDelHEAD resetea absolutamente todo incluyendo lo que tengas en staging. 686 | 687 | git reset es una mala práctica, no deberías usarlo en ningún momento; debe ser nuestro último recurso. 688 | 689 | ## Buscar en archivos y commits de Git con Grep y log 690 | 691 | A medida que nuestro proyecto se hace grande vamos a querer buscar ciertas cosas. 692 | 693 | **Por ejemplo: ¿cuántas veces en nuestro proyecto utilizamos la palabra color?** 694 | 695 | Para buscar utilizamos el comando `git grep color` y nos buscará en todo el proyecto los archivos en donde está la palabra **color**. 696 | 697 | Con `git grep -n color` nos saldrá un output el cual nos dirá en **qué línea está lo que estamos buscando.** 698 | 699 | Con `git grep -c color` nos saldrá un output el cual nos dirá **cuántas veces se repite esa palabra y en qué archivo.** 700 | 701 | Si queremos buscar cuántas veces utilizamos un atributo de HTML lo hacemos con `git grep -c "

"` 702 | 703 | ## Comandos y recursos colaborativos en Git y Github 704 | 705 | 1. **Comando para ver cuántos commits ha hecho cada miembro del equipo:** 706 | ``` 707 | git shortlog -sn 708 | git shortlog -sn -all 709 | git shortlog -sn -all --no-merges 710 | ``` 711 | 712 | **Crear un shortcode en Git para el shortlog:** 713 | 714 | ``` 715 | git config --global alias.stats "shortlog -sn -all --no-merges" 716 | ``` 717 | 718 | **Ejecutarlo:** 719 | ``` 720 | git stats 721 | ``` 722 | 723 | 2. **Saber quién hizo qué:** 724 | 725 | ``` 726 | git blame -c nombre-del-archivo / git blame -c index.html 727 | ``` 728 | 729 | 3. **Saber cómo funciona un comando** 730 | 731 | ``` 732 | git blame --help / Mostrará una guía de su funcionamiento 733 | ``` 734 | 735 | 4. **Ver las ramas de Git y Github** 736 | 737 | **Ver las ramas locales:** 738 | ``` 739 | git branch 740 | ``` 741 | 742 | **Ver las ramas remotas:** 743 | ``` 744 | git branch -r 745 | ``` 746 | 747 | **Ver todas las ramas:** 748 | ``` 749 | git branch -a 750 | ``` 751 | --------------------------------------------------------------------------------