├── .gitignore ├── imagenes └── dragon.png ├── historia.txt ├── css └── estilos.css ├── git stash.md ├── blogpost.html └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | *.jpg 2 | -------------------------------------------------------------------------------- /imagenes/dragon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/behagoras/gitgithub/HEAD/imagenes/dragon.png -------------------------------------------------------------------------------- /historia.txt: -------------------------------------------------------------------------------- 1 | Esta es la historia de Freddy Vega 2 | 3 | Freddy Vega tiene 32 años y nació en Colombia 4 | 5 | Anita Platzi es una persona que contribuye a este proyecto open source y nació en Internet 6 | 7 | Experimento 1 8 | 9 | Experimento 2 10 | 11 | Master 1 12 | 13 | Master 2 14 | 15 | Mañana nos enfocaremos en su vida laboral 16 | -------------------------------------------------------------------------------- /css/estilos.css: -------------------------------------------------------------------------------- 1 | body 2 | { 3 | background: #1e1f24; 4 | color: #333; 5 | text-align: center; 6 | font-family: Arial; 7 | font-size: 16px; 8 | margin: 0; 9 | padding: 0; 10 | } 11 | 12 | #cabecera 13 | { 14 | background: #37488b; 15 | box-shadow: 0px 2px 20px 0px rgba(0,0,0,0.5); 16 | color: white; 17 | font-weight: bold; 18 | margin: 0; 19 | padding: 0.5em; 20 | } 21 | 22 | #cabecera #logo 23 | { 24 | width: 20px; 25 | vertical-align: middle; 26 | } 27 | 28 | #cabecera #tagline 29 | { 30 | padding: 0 0 0 1em; 31 | font-weight: normal; 32 | font-size: 0.8em; 33 | } 34 | 35 | #container 36 | { 37 | width: 70%; 38 | padding: 0; 39 | text-align: left; 40 | border: 1px solid #DDD; 41 | margin: 0 auto; 42 | } 43 | 44 | #container h1 45 | { 46 | font-size: 20px; 47 | } 48 | #post 49 | { 50 | background: white; 51 | padding: 1em; 52 | } 53 | 54 | #footer 55 | { 56 | background: #37488b; 57 | color: white; 58 | text-align: center; 59 | padding: 0.5em; 60 | } 61 | 62 | 63 | -------------------------------------------------------------------------------- /git stash.md: -------------------------------------------------------------------------------- 1 | https://platzi.com/blog/flujo-de-trabajo-y-comandos-oscuros-de-git/ 2 | 3 | ## Stashed area: 4 | 5 | El stashed nos sirve para guardar cambios para después, Es una lista de estados que nos guarda algunos cambios que hicimos en Staging para poder cambiar de rama sin perder el trabajo que todavía no guardamos en un commit 6 | 7 | Ésto es especialmente útil porque hay veces que no se permite cambiar de rama, ésto porque porque tenemos cambios sin guardar, no siempre es un cambio lo suficientemente bueno como para hacer un commit, pero no queremos perder ese código en el que estuvimos trabajando. 8 | 9 | El stashed nos permite cambiar de ramas, hacer cambios, trabajar en otras cosas y, más adelante, retomar el trabajo con los archivos que teníamos en Staging pero que podemos recuperar ya que los guardamos en el Stash. 10 | 11 | ### git stash 12 | 13 | El comando git stash guarda el trabajo actual del Staging en una lista diseñada para ser temporal llamada Stash, para que pueda ser recuperado en el futuro. 14 | 15 | Para agregar los cambios al stash se utiliza el comando: 16 | 17 | ```bash 18 | git stash 19 | ``` 20 | 21 | Podemos poner un mensaje en el stash, para asi diferenciarlos en git stash list por si tenemos varios elementos en el stash. Ésto con: 22 | 23 | ``` 24 | git stash save "mensaje identificador del elemento del stashed" 25 | ``` 26 | 27 | ### Obtener elelmentos del stash 28 | 29 | El stashed se comporta como una [Stack](https://es.wikipedia.org/wiki/Pila_(informática)) de datos comportándose de manera tipo [LIFO](https://es.wikipedia.org/wiki/LIFO) (del inglés *Last In, First Out*, «último en entrar, primero en salir»), así podemos acceder al método pop. 30 | 31 | El método **pop** recuperará y sacará de la lista el **último estado del stashed** y lo insertará en el **staging area**, por lo que es importante saber en qué branch te encuentras para poder recuperarlo, ya que el stash será **agnóstico a la rama o estado en el que te encuentres**, siempre recuperará los cambios que hiciste en el lugar que lo llamas. 32 | 33 | Para recuperar los últimos cambios desde el stash a tu staging area utiliza el comando: 34 | 35 | ```bash 36 | git stash pop 37 | ``` 38 | 39 | Para aplicar los cambios de un stash específico y eliminarlo del stash: 40 | 41 | ```bash 42 | git stash pop stash@{} 43 | ``` 44 | 45 | Para retomar los cambios de una posición específica del Stash puedes utilizar el comando: 46 | 47 | ```bash 48 | git stash apply stash@{} 49 | ``` 50 | 51 | Donde el `` lo obtienes desden el `git stash list` 52 | 53 | ### Listado de elementos en el stash 54 | 55 | Para ver la lista de cambios guardados en Stash y así poder recuperarlos o hacer algo con ellos podemos utilizar el comando: 56 | 57 | ```bash 58 | git stash list 59 | ``` 60 | 61 | Retomar los cambios de una posición específica del Stash || Aplica los cambios de un stash específico 62 | 63 | ### Crear una rama con el stash 64 | 65 | Para crear una rama y aplicar el stash mas reciente podemos utilizar el comando 66 | 67 | ```bash 68 | git stash branch 69 | ``` 70 | 71 | Si deseas crear una rama y aplicar un stash específico (obtenido desde `git stash list`) puedes utilizar el comando: 72 | 73 | ```bash 74 | git stash branch nombre_de_rama stash@{} 75 | ``` 76 | 77 | Al utilizar estos comandos **crearás una rama** con el nombre ``, te pasarás a ella y tendrás el **stash especificado** en tu **staging area**. 78 | 79 | ### Eliminar elementos del stash 80 | 81 | Para eliminar los cambios más recientes dentro del stash (el elemento 0), podemos utilizar el comando: 82 | 83 | ```bash 84 | git stash drop 85 | ``` 86 | 87 | Pero si en cambio conoces el `índice` del stash que quieres borrar (mediante `git stash list`) puedes utilizar el comando: 88 | 89 | ```bash 90 | git stash drop stash@{} 91 | ``` 92 | 93 | Donde el `` es el `índice` del cambio guardado. 94 | 95 | Si en cambio deseas eliminar todos los elementos del stash, puedes utilizar: 96 | 97 | ```bash 98 | git stash clear 99 | ``` 100 | 101 | Consideraciones: 102 | 103 | - El cambio más reciente (al crear un stash) **SIEMPRE** recibe el valor 0 y los que estaban antes aumentan su valor. 104 | - Al crear un stash tomará los archivos que han sido modificados y eliminados. Para que tome un archivo creado es necesario agregarlo al Staging Area con git add [nombre_archivo] con la intención de que git tenga un seguimiento de ese archivo, o también utilizando el comando git stash -u (que guardará en el stash los archivos que no estén en el staging). 105 | - Al aplicar un stash este no se elimina, es buena práctica eliminarlo. 106 | 107 | -------------------------------------------------------------------------------- /blogpost.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | Hyperblog 2.0 es un blog del futuro 4 | 5 | 6 | 7 |
8 |
9 | 10 | Hyperblog 11 | Tu blog de confianza 12 |
13 |
14 |

Aquí inicia la historia de un gran proyecto

15 |

Y este es el párrafo de inicio donde vamos a explicar las cosas increíbles que se pueden hacer con ramas

16 |

17 |

Los blogs son la mejor forma de compartir información y tus ideas. Mucho mas que ir a conferencias o salir en Youtube. Excepto si eres un rockstar. Pero estadísticamente no lo eres.... por ahora.

18 |

Suscribete y dale like

19 |

david-behar

20 |

Edgar Barragán

21 |

@luiscarlos

22 |

Christopher Andrés Acevedo Galo

23 |

Moises Patiño

24 |

Ismael Dominguez Moreno

25 |

Edgar Hernández

26 |

rafaelrrp

27 |

Giselle Castillo

28 |

@centenarioalta

29 |

JuanDC

30 |

@elyager

31 |

JamaHCS

32 |

Oscar Daniel

33 |

Claudio Vazquez

34 |

Juan Ageitos

35 |

galvismj

36 |

crumblecoder

37 |

BauTancredi

38 |

Angel Barrios

39 |

Victor Isaac Chavez Escamilla

40 |

Santiago Harkes

41 |

Matías Cariboni

42 |

Juan Pablo Leyva

43 |

Diego

44 |

Ildebrando

45 |

gonzalo986

46 |

Norbs

47 |

José Gregorio Hernández Arciles

48 |

Erik

49 |

Irvingsan

50 |

Mauricio Alejandro Escobar Sejas

51 |

Luis Daniel Caraballo

52 |

Adrian Moreno

53 |

JaredOrtz

54 |

Joel Gaspar

55 |

@Yerko0

56 |

Eden Verdugo

57 |

Alex Abel Lerman

58 |

Víctor Landa 59 |

Pablo Córdoba 60 |

FixingMind5

61 |

Max88

62 |

Uzziel Adolfo Solís Vega

63 |

Gustavo Quino

64 |

Juan Sebastian Montealegre Calle

65 |

Jhon Sánchez

66 |

Cristhian Ochoa

67 |

alirioAngel

68 |

Ricardo Tierra

69 |

Daniel Martinez Sarta

70 |

luisfloresdev

71 |

Daniel Guillermo Perico Sánchez

72 |

Rodri

73 |

Eric Rodriguez

74 |

Santiago Quintero

75 |

Paula Sierra

76 |

Abdel Mejia

77 |

Germám

78 |

Jhon Caceres

79 |

Jair Partida Santana

80 |

Rodrigo Rodríguez

81 |

David Casadiegos

82 |

Miguel Ángel Baquero

83 |

Angely Granados

84 |

Ernesto Cruz

85 |

Rogelio Lenin Godínez Mata

86 |

Alexis Delgado

87 |

Jhon Mario Ochoa Lemus

88 |

Bea P. Santana

89 |

Bernardo Ayala

90 |

Luis Fernando Raga Renteria

91 |

Santiago Dalmasso

92 |

Rubén Pipe Álvarez A.

93 |

Julio Cárdenas

94 |

Matias Urra

95 |

Sebastian Alejandro

96 |

Andres Carrero

97 |

Alexis Alvarez

98 |

Axel N. Gómez H.

99 |

Cristian Rosales

100 |

John Dev

101 |

Javier Eduardo Acevedo Altube

102 |

Santiago Moran

103 |

Jose Monterrey

104 |

Joshval97

105 |

Jesus Haans

106 |

Bryan Cipriano Tarazona

107 |

Rodrigo Gaona

108 |

Octavio Moreno García

109 |

@rojasleon

110 |

Augusto Cáceres Suárez

111 |

Leonardo Ortiz López

112 |

Junior Erny Aguayo Cuadros

113 |

Alejandro Dubon

114 |

Víctor Hugo Vázquez Gómez

115 |
116 | 119 |
120 | 121 | 122 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## Cómo utilizar git y GitHub 2 | 3 | Este repositorio sirve como resúmen del [curso de Git y github de Platzi](https://platzi.com/github), por [Freddy Vega](https://github.com/freddier/hyperblog). 4 | 5 | **Git** es un sistema de control de versiones (**VCS version control system**), 6 | 7 | Registra los **cambios** realizados sobre un archivo o conjunto de archivos a lo largo del **tiempo**, por lo tanto no tendrás versiones como 8 | 9 | * tarea.txt 10 | * tarea2.txt 11 | * tarea2-final.txt 12 | * tarea2-final2.txt 13 | * tarea2-final2-esteeselbueno.txt 14 | 15 | Además de que envés de guardar los archivos completos se guardan **sólo los cambios**. 16 | 17 | Git es algo así como el `Ctrl+Z` (deshacer) de los programadores, suponiendo que el `Ctrl Z` guardara todo el **historial de modificación** de los archivos, ya que con git puedes moverte en la historia (algo así como una máquina del tiempo). 18 | 19 | ## Flujo básico de git 20 | 21 | El flujo normal de git es el siguiente: 22 | 23 | `git init`: Empiezas un repositorio 24 | 25 | `git add archivo.txt`: Agregas los cambios del archivo.txt al **staging area** para decirle a git que se prepare para guardar los cambios 26 | 27 | `git commit -m 'Descripción del commit'`: Guarda los cambios en la base de datos del VCS (creando una nueva versión) 28 | 29 | **Tipos de Control de versiones:** 30 | 31 | * Local: Sólo funciona en una sóla máquina, es útil, pero no incorpora la colaboración. 32 | * Centralizado (en un sólo servidor): Toda la información está depositada en un sólo repositorio, lo que hace que el trabajo se maneje directamente en el servidor. 33 | * Distribuído: La información se encuentra respaldada en diferentes peers, diferentes servidores y/o diferentes máquinas, lo que permite trabajar y compartir de manera sencilla. 34 | 35 | ## Archivos binarios y de texto plano 36 | 37 | Git permite guardar tanto binarios como archivos de texto plano, pero está diseñado para modificar archivos de texto plano, ¿la razón? como git guarda los cambios entre versiones en el tiempo, son prácticamente no rastreables los cambios entre una versión y otra de un binario, mientras que son muy transparentes en los archivos de texto plano. 38 | 39 | ## Diferencias de git contra otros VCS 40 | 41 | Git guarda referencia a los archivos no cambiados 42 | 43 | Trabajo online efectivo 44 | 45 | Git tiene Integridad: No puedes perder información durante su transmición 46 | 47 | ### Ventajas de git contra otros manejadores de versiones 48 | 49 | * Veloz 50 | * Diseño sencillo 51 | * Fuerte apoyo del desarrollo no lineal 52 | * Completamente distribuido 53 | * Capaz de manejar grandes proyectos 54 | 55 | ## Operaciones principales de git 56 | 57 | Es importante saber cuál es el estatus de tus cambios, ya que al modificar un archivo, éste no por defecto se va a git, sino que se modifica en el **working directory**, para que sea trackeado por git debe de pasar por el **staging area** y llegar al **repositorio**, opcionalmente podría llegar al **repositorio remoto**. A continuación más detalle. 58 | 59 | * **Working directory (Local):** El working directory es el espacio de trabajo no rastreado por git, al modificar un archivo, este se modificará en el working directory andtes de que le des `git add` para agregarlo al staging area. 60 | 61 | * **Staging Area:** Es un espacio en memoria ram dónde están guardados los cambios, pero todavía no están en el repositorio (no son trackeados por git). para agregar al staging area se utiliza el comando `git add` 62 | 63 | ```bash 64 | git add archivo.txt #Agrega el archivo.txt al staging area 65 | git add . #Agrega todos los cambios de los archivos en las subcarpetas del directorio en el que te encuentras al staging area 66 | git add -A #Agrega todos los cambios del repositorio en el que estás trabajando al staging area 67 | ``` 68 | 69 | * **Git repository:** Es el lugar dónde se trackean los cambios, cuando algo está en el repositorio, ya está en la historia de git y puedes acceder a ese historial mediante los commits. `git commit` 70 | 71 | ```bash 72 | git commit -m 'Commit 1' #Crea un commit (sube los cambios al repositorio local) con el nombre 'Commit 1' 73 | git commit #Se prepara para hacer commit y abre el editor por defecto de la terminal para ponerle nombre 74 | ``` 75 | 76 | Es una buena práctica ser descriptivos con los cambios que se hicieron en cada commit. 77 | 78 | * **Remote repository**: Acá entra github, el repositorio remoto es una copia de tu repositorio local, pero en Internet. Para mandar cambios al repositorio remoto es con el comando `git push` 79 | 80 | ```bash 81 | git push origin master #Empuja (envía) los cambios de la rama master al servidor remoto 'origin' 82 | ``` 83 | 84 | ## Commit 85 | 86 | Un commit es un cambio rastreable (de 1 o varios archivos), es confirmar un conjunto de cambios provisionales de forma permanente y tenemos el superpoder de ponerle nombre a este cambio. 87 | 88 | La historia de tu desarrollo se van guardando mediante commits, ya que cada cambio confirmado tiene modificaciones importantes hasta llegar al cambio actual. 89 | 90 | Para hacer un commit, es muy sencillo, tenemos que tener agregado en el staging (`git add -A`) y usar el comando commit 91 | 92 | ```bash 93 | Git commit -m 'commit' 94 | ``` 95 | 96 | Si trabajamos en algo experimental o que no queremos que sea parte del flujo principal, podemos hacer una nueva rama (**branch**), recordemos que la rama principal suela llamarse **master**, por lo tanto ésta branch nueva tendrá su propia historia (posterior al punto donde se creó). 97 | 98 | Para crear una rama nueva con la información de la rama actual usamos el comando 99 | 100 | ```bash 101 | git checkout -b nombre-del-branch 102 | ``` 103 | 104 | Si los cambios que realizaste en tu rama nueva son un avance en el código, puedes fusionarlo a la rama master (o a otra), para ésto tienes que cambiarte a master y hacer el comando es `merge` 105 | 106 | ```bash 107 | git checkout master # nos cambiamos a la rama master 108 | git merge rama-nueva # Fusionamos los cambios de la 'rama-nueva' en master 109 | ``` 110 | 111 | ## Archivos trackeados 112 | 113 | - **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`. 114 | - **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`. 115 | - **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. 116 | - **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. 117 | 118 | ## Configurar el entorno de git 119 | 120 | Para configurar la información del usuario global de git de tu máquina deberás de utilizar el comando `git config` declarando que modificaras de manera `--global` la variable (`email` o `name`) de tú `user` lo que significa que estarás definiendo qué usuario está utilizando git en tu máquina (que firma su autenticidad) 121 | 122 | ```bash 123 | git config --global user.email "tu@email.com" # Configura el correo del usuario de git 124 | git config --global user.name "Tu Nombre" # Configura el nombre del usuario de git 125 | 126 | ``` 127 | 128 | Llaves SSH 129 | 130 | ```bash 131 | ssh-keygen -t rsa -b 4096 -C "email@dominio.org" 132 | ``` 133 | 134 | 135 | 136 | **git init** 137 | 138 | Con git init creas un entorno de trabajo para git, además de la carpeta oculta .git, dónde se guardará toda la información relevante al control de versiones, es muy sencillo, en un directorio que no esté trackeado por git usa el comando `git init` 139 | 140 | ```bash 141 | git init #Empiezas un repositorio 142 | ``` 143 | 144 | **git add** 145 | 146 | Git add agrega los archivos y carpetas que elijas al staging area, que es como el espacio en memoria ram donde están los cambios que se van a subir en el futuro. 147 | 148 | ```bash 149 | git add # Agregas los cambios del archivo.txt al **staging area** para decirle a git que se prepare para guardar los cambios 150 | git add -A # Agregas todos los cambios al staging area 151 | git add . # Agregas los cambios de los subdirectorios de la carpeta en la que te encuentras 152 | ``` 153 | 154 | **git commit** 155 | 156 | Graba los cambios que están en el `staging area` en el `repositorio`. 157 | 158 | ```bash 159 | git commit #Se prepara para hacer commit y abre el editor por defecto de la terminal para ponerle nombre 160 | git commit -m 'Descripción del commit': #Guarda los cambios en la base de datos del VCS (creando una nueva versión) 161 | git commit --amend: 162 | ``` 163 | 164 | **Estado** 165 | 166 | Muestra el estado del working directory, muestra si hay cambios en el working directory sin agregar, o si hay algo en el staging area sin que se haya hecho un commit. 167 | 168 | ```bash 169 | git status 170 | ``` 171 | 172 | **git log** 173 | 174 | Te muestra el historial de los commits que has hecho 175 | 176 | ```bash 177 | git log # Muestra todos los commits con la información default 178 | git log -3 #ultimos tres commits 179 | git log --oneline #Resumido 180 | git log --oneline --graph #Te lo muestra Resumido y bonito 181 | ``` 182 | 183 | **Show** 184 | 185 | Muestra el mensaje del último commit y la diferencia textual. Es como log, pero con la diferencia de que muestra los cambios precisos que se hicieron en el commit 186 | 187 | ```bash 188 | git show 189 | ``` 190 | 191 | **git diff** 192 | 193 | Nos compara y muestra los cambios sufridos entre los dos commits. Los id de los commit se pueden encontrar ejecutando git log. 194 | 195 | ```bash 196 | git diff # 197 | git diff 198 | ``` 199 | 200 | **git reset** 201 | 202 | ```bash 203 | git reset --soft #Agrega al staging 204 | git reset --mixed #No lo agrega al staging 205 | git reset --hard # 206 | ``` 207 | 208 | **Cambiar el editor de código default de git** 209 | 210 | ```bash 211 | git config --global core.editor “nano --wait” 212 | ``` 213 | 214 | **Branchs (Ramas)** 215 | 216 | Versiones alternas de un proyecto 217 | 218 | ```bash 219 | git branch nombre 220 | git branch -d nombre # Eliminar rama 221 | git branch -D nombre # Forzar eliminado de rama 222 | git branch -m nombre_viejo nombre_nuevo # Cambiar nombre de la rama 223 | git checkout #cambiar de ramas 224 | git checkout cambio_rama # Cambiar a la rama 225 | git checkout -b nueva-imagen # Crear rama y switchear a ésta 226 | git merge # mezclando la rama actual con la 227 | # Tenemos que estar en la rama output para hacer un merge o un rebase 228 | git merge --abort 229 | git rebase # hace prácticamente lo mismo que merge, cambiamos la historia de nuestro proyecto sin crear bifurcaciones del proyecto. Es mejor usar merge, 230 | #Usar solo git rebase de manera local. 231 | 232 | ``` 233 | 234 | ## Repositorio remoto (GitHub) 235 | 236 | GitHub es un sistema online de manejo de repositorios de Git, es el cliente de git más popular, tanto que, se podría decir que es la red social del código, ésto porque te permite tener tus repositorios en la nube, tener un perfil profesional (con los aportes, tus repositorios y demás información de tu vidad de programador) y todo con un núcleo de git por dentro. 237 | 238 | Como git es un VMS distribuído, entonces el código funciona en diferentes servidores (máquinas), pero para que vinculemos un servidor remoto tenemos que configurar un origen que indique con qué repositorio remoto estaremos trabajando, básicamente es una sintaxis que nos indica que le vamos a poner un pseudónimo a la url de dónde vamos a trabajar. 239 | 240 | El comando para agregar un orígen remoto es: 241 | 242 | ```bash 243 | git remote add origin 244 | ``` 245 | 246 | Donde: 247 | 248 | * **git remote** = El comando que indica que vamos a trabajar con un servidor remoto 249 | * **add** = Agrega un alias para el servidor remoto 250 | * **origin** = Es el alias del servidor remoto (ésto para no tener que poner la url completa cada que quieres hacer un cambio) 251 | * **** = Es la url dónde está el repositorio en la nube, en este caso de github (https://github.com//) 252 | 253 | Ya que agregaste tu servidor remoto `origin` puedes jalaro o empujar los cambios, osea sincronizar tu servidor remoto con el local, para eso tenemos 2 comandos 254 | 255 | * git pull: Jala los cambios del servidor, pero cómo podemos tener configurados diferentes repositorios remotos, tenemos que definir de dónde lo vamos a bajar y qué rama vamos a bajar, para eso podemos utilizar el siguiente comando: 256 | 257 | ```bash 258 | git pull 259 | ``` 260 | 261 | En el caso de la rama master y el remoto origin: 262 | 263 | ```bash 264 | git pull origin master 265 | ``` 266 | 267 | Ésto bajará todos los cambios a tu local, pero si de pura casualidad la historia es diferente (el repositorio remoto tiene commits diferentes, puede ser un Readme nuevo) tienes que forzar bajar los cambios con el flag `--allow-unrelated-histories`. 268 | 269 | ```bash 270 | git pull origin master --allow-unrelated-histories 271 | ``` 272 | 273 | * git push: Empuja los cambios desde el local al remoto. 274 | 275 | ```bash 276 | git push 277 | ``` 278 | 279 | La sintaxis es la misma que para el pull: 280 | 281 | ```bash 282 | git push origin master 283 | ``` 284 | 285 | 286 | 287 | ## Llaves públicas y privadas 288 | 289 | Es un problema guardar el usuario y la contraseña de tu cuenta de github en tu máquina porque puede ser extraído si alguien accede a tu equipo, para eso podemos cifrar tu identidad con el algoritmo de Llaves públicas y privadas (o Cifrado asimétrico de un sólo camino ) 290 | 291 | Este algoritmo sirve para mandar mensajes privados entre varios nodos con la lógica de que firmas tu mensaje con una llave pública vinculada con una llave privada que puede leer el mensaje. 292 | 293 | El flujo es: 294 | 295 | 1. Creas una llave pública y una llave privada (ambas están vinculadas) 296 | 2. Cifras el mensaje con la llave pública (puede ser llave de otra persona) 297 | 3. Envías el mensaje 298 | 4. El receptor, al tener la llave privada puede descifrar el mensaje. 299 | 300 | Este algoritmo es completamente seguro, así es cómo se mandan las comunicaciones en bancos, la comunicación entre servidores o las firmas electrónicas. 301 | 302 | ### Git stash 303 | 304 | git stash: es otro de los limbos, como el staging area. Para agregar los cambios estos deben estar en el staging area. 305 | git stash list: nos muestra la lista de stash que tengamos. 306 | git stash drop stash@{numero}: nos permite borrar un stash. 307 | git stash apply: aplicamos el último cambio 308 | Guardar en el limbo los cambios 309 | 310 | git stash 311 | git stash drop #eliminar un stash 312 | git stash apply #Agrega el estado ultimo 313 | git stash apply #agregar stash exacto 314 | 315 | ### git cherry-pick 316 | 317 | Escoger commits 318 | git cherry-pick [SHA1] nos permite cambiar un commit a otra rama para salvarnos la vida. 319 | Vim 320 | :wq #guardar y salir 321 | 322 | MAC 323 | pbcopy < “archivo” 324 | 325 | ## Forks o Bifurcaciones 326 | 327 | Es una característica única de GitHub en la que se crea una copia exacta del estado actual de un repositorio público a mis repositorios en Github, éste repositorio podrá servir como otro origen y se podrá clonar (como cualquier otro repositorio), en pocas palabras, lo podremos utilizar como un git cualquiera. 328 | 329 | Copiar un repositorio público a mis repositorios en Github, con todas sus ramas e historia anterior 330 | 331 | Un fork es como una bifurcación del repositorio completo, tiene una historia en común, pero de repente se bifurca y pueden variar los cambios, ya que ambos proyectos podrán ser modificados en paralelo y para estar al día un colaborador tendrá que estar actualizando su fork con la información del original. 332 | 333 | Al hacer un fork de un poryecto en GitHub, te conviertes en dueñ@ del repositorio fork, puedes trabajar en éste con todos los permisos, pero es un repositorio completamente diferente que el original, teniendo alguna historia en común. 334 | 335 | Los forks son importantes porque es la manera en la que funciona el open source, ya que, una persona puede no ser colaborador de un proyecto, pero puede contribuír al mismo, haciendo mejor software que pueda ser utilizado por cualquiera. 336 | 337 | Al hacer un fork, GitHub sabe que se hizo el fork del proyecto, por lo que se le permite al colaborador hacer pull request desde su repositorio propio. 338 | 339 | ## Trabajando con más de 1 repositorio remoto 340 | 341 | Cuando trabajas en un proyecto que existe en **diferentes repositorios remotos** (normalmente a causa de un **fork**) es muy probable que desees poder **trabajar con ambos repositorios**, para ésto puedes crear un **remoto adicional** desde consola. 342 | 343 | ```bash 344 | git remote add 345 | ``` 346 | 347 | ```bash 348 | git remote upstream https://github.com/freddier/hyperblog 349 | ``` 350 | 351 | Al crear un **remoto adicional** podremos, hacer **pull** desde el nuevo **origen** (en caso de tener permisos podremos hacer fetch y push) 352 | 353 | ```bash 354 | git pull 355 | ``` 356 | 357 | ```bash 358 | git pull upstream master 359 | ``` 360 | 361 | Éste `pull` nos traerá los **cambios del remoto**, por lo que se estará al día en el proyecto, el flujo de trabajo cambia, en adelante se estará trabajando haciendo **pull desde el upstream** y **push al origin** para pasar a hacer **pull request**. 362 | 363 | ```bash 364 | git pull upstream master 365 | git push origin master 366 | ``` 367 | 368 | ## Etiquetas, versiones 369 | 370 | Comandos para trabajar con etiquetas: 371 | 372 | - Crear un nuevo tag y asignarlo a un commit: 373 | 374 | ```bash 375 | git tag -f -a -m 376 | git tag -f -a nombre-del-tag id-del-commit 377 | ``` 378 | 379 | * Borrar un tag en el repositorio local: 380 | 381 | ```bash 382 | git tag -d nombre-del-tag 383 | ``` 384 | 385 | - Listar los tags de nuestro repositorio local: 386 | 387 | ```bash 388 | git tag 389 | git show-refs --tags 390 | ``` 391 | 392 | - Publicar un tag en el repositorio remoto 393 | 394 | ```bash 395 | git push origin --tags 396 | ``` 397 | 398 | - Borrar un tag del repositorio remoto: 399 | 400 | ```bash 401 | git tag -d nombre-del-tag # Borrar los tags en local 402 | git push origin :refs/tags/nombre-del-tag # Borrar los tags en remoto 403 | ``` 404 | 405 | ## Pull request: 406 | 407 | Es una funcionalidad de github (en gitlab llamada merge request y en bitbucket push request), en la que un colaborador pide que revisen sus cambios antes de hacer merge a una rama, normalmente master. 408 | 409 | Al hacer un pull request se genera una conversación que pueden seguir los demás usuarios del repositorio, así como autorizar y rechazar los cambios. 410 | 411 | El flujo del pull request es el siguiente 412 | 413 | 1. Se trabaja en una **rama paralela** los cambios que se desean (`git checkout -b `) 414 | 2. Se hace un **commit** a la rama (`git commit -am ''`) 415 | 3. Se **suben** al **remoto** los **cambios** (`git push origin `) 416 | 4. En GitHub se hace el `pull request` comparando la **rama master** con la rama del **fix**. 417 | 5. Uno, o varios colaboradores revisan que el **código sea correcto** y dan **feedback** (en el chat del pull request) 418 | 6. El colaborador hace los cambios que desea en la **rama** y lo **vuelve a subir** al remoto (automáticamente jala la historia de los cambios que se hagan en la rama, en remoto) 419 | 7. Se **aceptan los cambios** en GitHub 420 | 8. Se hace **merge** a `master` desde GitHub 421 | 422 | **Importante**: Cuando se modifica una `rama`, también se modifica el `pull request` 423 | 424 | ## Ignorar archivos para no subirlos al repositorio (.gitignore) 425 | 426 | Por diversas razones, **no todos los archivos** que agregas a un proyecto **deberían guardarse** en un repositorio, ésto porque hay archivos que no todo el mundo debería de ver, y hay archivos que al estar en el repositorio alentan el proceso de desarrollo (por ejemplo los binary large objects, blob, que se tardan en descargarse). 427 | 428 | Para que no se suban estos archivos no deseados se puede crear un archivo con el nombre `.gitignore` en la raíz del repositorio con las reglas para los archivos que no se deberían subir (ver [sintaxis de los .gitignore](https://git-scm.com/docs/gitignore). 429 | 430 | Las razones principales para tomar la decisión de no agregar un archivo a un repositorio son: 431 | 432 | * Es un archivo con contraseñas (normalmente con la extensión `.env`) 433 | * Es un blob (binary large object, objeto binario grande), mismos que son difíciles de gestionar en git. 434 | * Son archivos que se generan corriendo comandos, por ejemplo la carpeta `node_modules` que genera npm al correr el comando `npm install` 435 | 436 | ## Readme.md y markdown 437 | 438 | `README.md` es el lugar dónde se explica de qué trata el proyecto, cómo utilizarlo y demás información que se considere que se deba conocer antes de utilizar un proyecto. 439 | 440 | Los archivos README son escritos en un lenguaje llamado [**markdown**](https://www.markdownguide.org/getting-started/), por eso la extensión `.md`, mismo que es un estándar de escritura en diversos sitios ([como platzi](https://platzi.com/tutoriales/1339-fundamentos-javascript/1615-markdown-el-lenguaje-de-estilos-para-los-readmemd-de-tus-paquetes-npm-y-de-los-tutoriales-de-platzi/), como [wikipedia](https://en.wikipedia.org/wiki/Help:Wikitext) y obvio GitHub), ver [reglas de markdown](https://www.markdownguide.org/extended-syntax). 441 | 442 | Los `README.md` pueden estar en todas las carpetas, pero el más importante es el que se encuentra en la raíz y ayudan a que los colaboradores sepan información importante del proyecto, módulo o sección, puedes crear cualquier cualquier archivo con la extensión `.md` pero sólo losn `README.md` los mostrará por defecto GitHub. 443 | 444 | Un ejemplo de archivo `Readme.md` son [mis apuntes de este curso](https://github.com/behagoras/gitgithub/blob/master/README.md). 445 | 446 | ## Git Stash: Guardar cambios en memoria y recuperarlos después 447 | 448 | 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. 449 | 450 | `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. 451 | 452 | ## Stashed area: 453 | 454 | El stashed nos sirve para guardar cambios para después, Es una lista de estados que nos guarda algunos cambios que hicimos en Staging para poder cambiar de rama sin perder el trabajo que todavía no guardamos en un commit 455 | 456 | Ésto es especialmente útil porque hay veces que no se permite cambiar de rama, ésto porque porque tenemos cambios sin guardar, no siempre es un cambio lo suficientemente bueno como para hacer un commit, pero no queremos perder ese código en el que estuvimos trabajando. 457 | 458 | El stashed nos permite cambiar de ramas, hacer cambios, trabajar en otras cosas y, más adelante, retomar el trabajo con los archivos que teníamos en Staging pero que podemos recuperar ya que los guardamos en el Stash. 459 | 460 | ### git stash 461 | 462 | El comando git stash guarda el trabajo actual del Staging en una lista diseñada para ser temporal llamada Stash, para que pueda ser recuperado en el futuro. 463 | 464 | Para agregar los cambios al stash se utiliza el comando: 465 | 466 | ```bash 467 | git stash 468 | ``` 469 | 470 | Podemos poner un mensaje en el stash, para asi diferenciarlos en git stash list por si tenemos varios elementos en el stash. Ésto con: 471 | 472 | ``` 473 | git stash save "mensaje identificador del elemento del stashed" 474 | ``` 475 | 476 | ### Obtener elelmentos del stash 477 | 478 | El stashed se comporta como una [Stack](https://es.wikipedia.org/wiki/Pila_(informática)) de datos comportándose de manera tipo [LIFO](https://es.wikipedia.org/wiki/LIFO) (del inglés *Last In, First Out*, «último en entrar, primero en salir»), así podemos acceder al método pop. 479 | 480 | El método **pop** recuperará y sacará de la lista el **último estado del stashed** y lo insertará en el **staging area**, por lo que es importante saber en qué branch te encuentras para poder recuperarlo, ya que el stash será **agnóstico a la rama o estado en el que te encuentres**, siempre recuperará los cambios que hiciste en el lugar que lo llamas. 481 | 482 | Para recuperar los últimos cambios desde el stash a tu staging area utiliza el comando: 483 | 484 | ```bash 485 | git stash pop 486 | ``` 487 | 488 | Para aplicar los cambios de un stash específico y eliminarlo del stash: 489 | 490 | ```bash 491 | git stash pop stash@{} 492 | ``` 493 | 494 | Para retomar los cambios de una posición específica del Stash puedes utilizar el comando: 495 | 496 | ```bash 497 | git stash apply stash@{} 498 | ``` 499 | 500 | Donde el `` lo obtienes desden el `git stash list` 501 | 502 | ### Listado de elementos en el stash 503 | 504 | Para ver la lista de cambios guardados en Stash y así poder recuperarlos o hacer algo con ellos podemos utilizar el comando: 505 | 506 | ```bash 507 | git stash list 508 | ``` 509 | 510 | Retomar los cambios de una posición específica del Stash || Aplica los cambios de un stash específico 511 | 512 | ### Crear una rama con el stash 513 | 514 | Para crear una rama y aplicar el stash mas reciente podemos utilizar el comando 515 | 516 | ```bash 517 | git stash branch 518 | ``` 519 | 520 | Si deseas crear una rama y aplicar un stash específico (obtenido desde `git stash list`) puedes utilizar el comando: 521 | 522 | ```bash 523 | git stash branch nombre_de_rama stash@{} 524 | ``` 525 | 526 | Al utilizar estos comandos **crearás una rama** con el nombre ``, te pasarás a ella y tendrás el **stash especificado** en tu **staging area**. 527 | 528 | ### Eliminar elementos del stash 529 | 530 | Para eliminar los cambios más recientes dentro del stash (el elemento 0), podemos utilizar el comando: 531 | 532 | ```bash 533 | git stash drop 534 | ``` 535 | 536 | Pero si en cambio conoces el `índice` del stash que quieres borrar (mediante `git stash list`) puedes utilizar el comando: 537 | 538 | ```bash 539 | git stash drop stash@{} 540 | ``` 541 | 542 | Donde el `` es el `índice` del cambio guardado. 543 | 544 | Si en cambio deseas eliminar todos los elementos del stash, puedes utilizar: 545 | 546 | ```bash 547 | git stash clear 548 | ``` 549 | 550 | Consideraciones: 551 | 552 | - El cambio más reciente (al crear un stash) **SIEMPRE** recibe el valor 0 y los que estaban antes aumentan su valor. 553 | - Al crear un stash tomará los archivos que han sido modificados y eliminados. Para que tome un archivo creado es necesario agregarlo al Staging Area con git add [nombre_archivo] con la intención de que git tenga un seguimiento de ese archivo, o también utilizando el comando git stash -u (que guardará en el stash los archivos que no estén en el staging). 554 | - Al aplicar un stash este no se elimina, es buena práctica eliminarlo. 555 | 556 | ## Remendar un commit 557 | 558 | Puede modificar el commit más reciente (enmendar) en la misma rama ejecutando: 559 | 560 | ```bash 561 | git add -A # Para hacer uso de ammend los archivos deben de estar en staging 562 | git commit --amend # Remendar último commit 563 | ``` 564 | 565 | Este comando sirve para agregar archivos nuevos o actualizar el commit anterior y no generar commits innecesarios. 566 | 567 | También es una forma sencilla de **editar o agregar comentarios al commit anterior** porque abrirá la consola para editar el commit anterior. 568 | 569 | **Nota**: Es una **mala práctica** hacer ammend de un commit que ya ha sido **pusheado o pulleado** del repositorio remoto, al momento de hacer ammend con algún `commit` que esté en remoto va a generar un **conflicto** que se va a arreglar haciendo un `commit adicional` y se **perderá el beneficio** del ammend. 570 | 571 | ## Git nunca olvida, `git reflog` 572 | 573 | Git guarda todos los cambios aunque decidas borrarlos, al borrar un cambio lo que estás haciendo sólo es actualizar la punta del branch, para gestionar éstas puntas existe un mecanismo llamado registros de referencia o `reflogs`. 574 | 575 | La gestión de estos cambios es mediante los hash'es de referencia (o `ref`) que son apuntadores a los commits. 576 | 577 | Los recoges registran cuándo se actualizaron las referencias de Git en el repositorio local (sólo en el local), por lo que si deseas ver cómo has modificado la historia puedes utilizar el comando: 578 | 579 | ```bash 580 | git reflog 581 | ``` 582 | 583 | Muchos comandos de Git aceptan un parámetro para especificar una referencia o "ref", que es un puntero a una confirmación sobre todo los comandos: 584 | 585 | - `git checkout` Puedes moverte sin realizar ningún cambio al commit exacto de la `ref` 586 | 587 | ```bash 588 | git checkout eff544f 589 | ``` 590 | 591 | - `git reset`: Hará que el último commit sea el pasado por la `ref`, usar este comando sólo si sabes exactamente qué estás haciendo 592 | 593 | ```bash 594 | git reset --hard eff544f # Perderá todo lo que se encuentra en staging y en el Working directory y se moverá el head al commit eff544f 595 | git reset --soft eff544f # Te recuperará todos los cambios que tengas diferentes al commit eff544f, los agregará al staging area y moverá el head al commit eff544f 596 | ``` 597 | 598 | - `git merge`: Puedes hacer merge de un commit en específico, funciona igual que con una branch, pero te hace el merge del estado específico del commit mandado 599 | 600 | ```bash 601 | git checkout master 602 | git merge eff544f # Fusionará en un nuevo commit la historia de master con el momento específico en el que vive eff544f 603 | ``` 604 | 605 | ## Comandos no documentados 606 | 607 | ```bash 608 | git config --global alias.platzi "shortlog" 609 | ``` 610 | 611 | ```bash 612 | ssh-keygen -t rsa -b 4096 -C "davbelom@gmail.com" 613 | ``` 614 | 615 | --------------------------------------------------------------------------------