-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathindex.html
More file actions
495 lines (313 loc) · 25.9 KB
/
Copy pathindex.html
File metadata and controls
495 lines (313 loc) · 25.9 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- Sintaxis del código de colores (highlight.js)-->
<!-- Hosted -->
<!-- <link rel="stylesheet"
href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/10.7.2/styles/default.min.css">
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/10.7.2/highlight.min.js"></script> -->
<!-- Local -->
<script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.15.8/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
<link rel="stylesheet" href="css/code_styles/zenburn.css">
<!-- Fin -->
<title>Practice 3</title>
<link rel="stylesheet" href="./css/style.css">
<link rel="icon" href="images/fi_p_64px.svg">
<link rel="mask-icon" href="images/fi_p_64px.svg" color="#000000">
<link rel="apple-touch-icon" href="images/fi_p_64px.svg">
</head>
<body id="main_body">
<header class="header">
<p>Mi Blogsito en la WEB <span>Aprendiendo Git</span></p>
</header>
<menu>
<h1>Creación de nuevo Contenido <span class="span_h">Guía rápida</span></h1>
<div class="section_content">
<p>Veamos, en esta página vamos a hacer experimentos raros con HTML, CSS, JavaScript y Git. Cada sección estará divida por un <b><h2></b>, y cada subsección por un <b><h3></b>. Mientras que el contenido estará dividido por una caja <b><div></b> llamada <b>section_content</b>. Todo ello estará en menús desplegables para navegar más fácil. Se arrancará el código de la siguiente manera:</p>
<span class="container_code">
<pre><code
><details>
<summary><h2>Título de la sección</h2></summary>
<div class="section_content">
<!-- Descripción de la sección -->
</div>
<details>
<summary><h3>Título de la subsección</h3></summary>
<div class="section_content">
<!-- Contenido de la subsección -->
</div>
<details>
</details></code></pre>
</span>
<p>Teniendo eso en Mente... ¡ARRANQUEMOS!</p>
</div>
<!-- Inicio del código de la actividad -->
<details open>
<summary><h2>Git y Github</h2></summary>
<div class="section_content">
<p>Sección de entrenamiento para usar Git y GitHub con una terminal.</p>
<p>El contenido de aprendizaje se encuentra en <a href="https://platzi.com/" target="_blank">Platzi</a>, en la siguiente liga: <a href="https://platzi.com/cursos/git-github/" target="_blank">https://platzi.com/cursos/git-github/</a></p>
</div>
<!-- Tabline -->
<details>
<summary><h3>Creación de repositorios, confirmaciones y <i>Push</i> <span class="span_h">Uso básico de Git</span></h3></summary>
<div class="section_content">
<h4>Crear un repositorio nuevo.</h4>
<p>Para ello debemos inicializar nuestra terminal de <i>linux</i> o <i>git bash</i>. Después de haber instalado Git (en caso de <i>linux</i>) se indica el siguiente comando dentro del directorio que queremos convertir en repositorio:</p>
<span class="container_code">
<pre><code class="linux_code properties"
>git init</code></pre>
</span>
<h4>Lanzamiento de los primeros cambios</h4>
<p>Para lanzar el contenido de nuestro directorio, primero debemos decirle a <i>git</i> que el archivo existe. Para ello ejecutamos el siguiente comando (incluido el punto):</p>
<span class="container_code">
<pre><code class="linux_code properties"
>git add .</code></pre>
</span>
<p>Con esto le estamos diciendo que busque el directorio actual completo. Por último, guardamos los cambios en la rama maestra (llamada <i>master</i>). Esto lo hacemos con un <i>commit</i>, de la siguiente manera:</p>
<span class="container_code">
<pre><code class="linux_code properties"
>git commit -m "Primer lanzamiento del sitio"</code></pre>
</span>
<p>El atributo <i>-m</i> indica que le vamos a asignar un mensaje al <i>commit</i>, y el texto dentro de las comillas es el mensaje en sí mismo.</p>
<p>Recordemos que un <i>commit</i> es una declaración de cambios de nuestro proyecto en el repositorio. Con él se genera un <i>hash</i> de siete dígitos que lo identifica. Entonces podemos decir que cada <i>commit</i> es una versión nueva de nuestro proyecto.</p>
<p>Estos dos comandos se pueden unir en uno sólo siempre y cuando no se hayan creado nuevos archivos en el repositorio. Esto se hace de la siguiente manera:</p>
<span class="container_code">
<pre><code class="linux_code properties"
>git commit -am "Primer lanzamiento del sitio"</code></pre>
</span>
<h4>Lanzamiento del repositorio local al repositorio remoto</h4>
<p>Una vez que tenemos nuestros cambios listos y los <i>commits</i> hechos. Es necesario enviarlo al servidor de un sistema de control de versiones como <b>github</b>, <b>gitlab</b> o <b>bitbucket</b> para tenerlos en la nube y poder trabajar con otras peronas.</p>
<p>Para enviarlo al servidor indicamos el siguiete comando en nuestra terminal:</p>
<span class="container_code">
<pre><code class="linux_code properties"
>git push -u origin master</code></pre>
</span>
<p>el parametro <i>-u origin</i> le indica a la terminal que lo envíe a <b>github</b> y se debe realizar sólo una vez. <i>Master</i> quiere decir que el contenido se almacenará en la rama principal. Después de haber hecho el primer lanzamiento, con escribir <b><i>"git push"</i></b> bastará para lanzar los cambios.</p>
</div>
</details>
<!-- Tabline -->
<details>
<summary><h3>Flujo de trabajo <span class="span_h">Git</span></h3></summary>
<div class="section_content">
<p>Cuando creas un repositorio de Git con <i>"git init"</i>. A parte de crear el repositorio, creas un área intermedia entre el espacio de trabajo (tu computadora) y el repositorio. A esta área se le conoce como <i>staging area</i>. Una forma de ilustrar esto es la siguiente:</p>
<figure>
<img class="white_border_img" src="images/workflow.jpg" alt="Imagen del flujo de trabajo" width="600px" height="auto" loading="lazy">
</figure>
</div>
</details>
<!-- Tabline -->
<details>
<summary><h3><i>Reset</i> y <i>Checkout</i> <span class="span_h">Regresar a versiones anteriores</span></h3></summary>
<div class="section_content">
<p>Ambos sirven para "volver en el tiempo". Para regresar a un punto específico en la historia de nuestro proyecto.</p>
<p><b>Reset:</b> Sirve para reiniciar el log de cambios a un <i>commit</i> en específico. Si se usa el atributo <i>--hard</i> no se puede volver a los <i>commits</i> subsecuentes.</p>
<p><b>Checkout:</b> Sirve para observar los archivos y su estado en cualquier <i>commit</i> del log de cambios. Para volver a la versión actual <span><i>(HEAD)</i></span> basta con escribir el siguiente comando:</p>
<span class="container_code">
<pre><code class="linux_code properties"
>git checkout master</code></pre>
</span>
</div>
</details>
<!-- Tabline -->
<details>
<summary><h3><i>Merge</i> <span class="span_h">Fusionar ramas</span></h3></summary>
<div class="section_content">
<p>El comando <i>merge</i> sirve para unir una rama del repositorio con otra. Lo más común es unirla a la rama maestra (<i>master</i>). Para unir dos ramas con <i>merge</i> es necesario posicionarse sobre la rama principal con el siguiente comando:</p>
<span class="container_code">
<pre><code class="linux_code properties"
>git switch master</code></pre>
</span>
<p>Es importante que recuerdes posicionarte sobre tu rama principal, porque la fusión se llevará a cabo sobre ella. En nuestro caso es <i>master</i>.</p>
<p>Una vez posicionados en una de las ramas, debemos aplicar el comando <i>merge</i> para unirlas indicando el nombre de la segunda rama. En este caso, <i>master</i>.</p>
<span class="container_code">
<pre><code class="linux_code properties"
>git merge rama_2</code></code></pre>
</span>
<p>Una forma gráfica de ver nuestra fusión es la siguiente:</p>
<figure>
<img src="./images/master_merge.svg" alt="merge en master" width="600px" height="auto" loading="lazy">
</figure>
<p>Pero, <b>¿por qué es importante posicionarme en la rama master?</b> Es cierto que te puedes posicionar con <i>switch</i> en la rama secundaria (<i>rama_2</i>) en lugar de <i>master</i>. Pero no te lo recomiendo porque ahora tu rama principal dejará de ser <i>master</i> y <i>rama_2</i> pasará a ser la principal. Puedes ver claramente como quedaría tu repositorio en la siguiente imagen.</p>
<figure>
<img src="./images/rama_2_merge.svg" alt="merge en master" width="600px" height="auto" loading="lazy">
</figure>
</div>
</details>
<!-- Tabline -->
<details>
<summary><h3><i>Pull Request</i> <span class="span_h">Solicitud de <i>merge</i> en Github</span></h3></summary>
<div class="section_content">
<p><b>Pull Request</b> es la base de la colaboración <i>open source</i>. Es una forma de pedir permiso para hacer un <i>merge</i> a una rama del repositorio. Esto es util cuando el usuario que quiere hacer el <i>merge</i>, no pertenece al equipo de desarrollo.</p>
<p>Podemos decir que es un <i>merge</i>, que se completa hasta que algún administrador del repositorio da permiso para para que se ejecute.</p>
</div>
</details>
<!-- Tabline -->
<details>
<summary><h3><i>Show</i> y <i>Diff</i> <span class="span_h">Ver cambios entre versiones</span></h3></summary>
<div class="section_content">
<p>Git es una herramienta muy poderosa. Ya que gracias a ella podemos ver los cambios entre una versión y otra (entre un <i>commit</i> y otro). Aunque también podemos ver un <i>log</i> de todos los cambios hechos desde la creación del repositorio. Para hacer eso, tenemos dos <i>keywords</i>: <i>show</i> y <i>diff</i>.</p>
<p><b>Show</b>: Sirve para ver el log de cambios desde que se inicializó el repositorio.</p>
<p><b>Diff</b>: Nos ayuda a ver los cambios efectuados entre un <i>commit</i> y otro. Para ejecutarlo es necesario contar con el <i>hash</i> de los dos <i>commits</i>, recuerda que puedes obtenerlos con <i>"git show"</i>. Para usarlo se usa la siguiente sintaxis (sin las comillas):</p>
<span class="container_code">
<pre><code class="linux_code properties">git diff 'commit_1' 'commit_2'</code></pre>
</span>
<p>Un ejemplo real es el siguiente:</p>
<span class="container_code">
<pre><code class="linux_code properties">git diff e9a7ba0 e8b373a</code></pre>
</span>
<p>Recuerda que el orden de los <i>commits</i> es muy importante. Porque si, por ejemplo, pones primero un <i>commit</i> más reciente, y después un <i>commit</i> antiguo, los cambios se mostrarán al revés. Es decir, las líneas añadidas al final aparecerán como líneas eliminadas, y viceversa.</p>
</div>
</details>
<!-- Tabline -->
<details>
<summary><h3>Archivos de Repositorio (README.md y .gitignore) <span class="spanGithub_h">Git</span></h3></summary>
<div class="section_content">
<p>Cada repositorio de Git cuenta con archivos especiales que ayudan a los colaboradores o usuarios de los proyectos entender cómo funcionan estos por dentro.</p>
<h4>README.md</h4>
<p>El archivo <i>README.md</i> explica a los usuarios cómo funciona el repositorio, y menciona de forma más detallada que la Descripción de que trata el proyecto.</p>
<p>Para inicializar un <i>README.md</i> basta con crear un archivo con ese nombre y extensión en la carpeta raíz del repositorio. Recuerda que las siglas de la extensión <i>.md</i> significan <b><i>Markdown</i></b>, y es en ese lenguaje en el que se debe escribir el <i>readme</i>. Aunque se le puede integrar HTML también.</p>
<h4>.gitignore</h4>
<p>Este archivo sirve para indicarle a Git que archivos o que tipo de archivos debe ignorar al detectar cambios. Suele usarse para omitir archivos binarios, claves, bases de datos, entre otros.</p>
<p>Un ejemplo sencillo de uso es el siguiente:</p>
<span class="container_code">
<pre><code class="properties"
># Para ignorar todos los archivos con extensión .jpg
*.jpg
# Para ignorar la carpeta de imágenes
images/
# Para evitar que se ignore una imagen dentro de la carpeta images/
!images/img.jpg</code></pre>
</span>
<p>Aquí hay algunas <a rel="noreferrer noopener" href="https://opensource.com/article/20/8/dont-ignore-gitignore" target="_blank">reglas básicas</a> que te ayudarán a configurar tu archivo <i>.gitignore</i> correctamente:</p>
<ul>
<li>Cualquier línea que comience con un hash <b>(#)</b> es un comentario.</li>
<li>El carácter <b>\</b> escapa a los caracteres especiales.</li>
<li>El carácter <b>/</b> al principio, indica el inicio de una ruta relativa a la carpeta en la que se encuentre el fichero <i>.gitignore</i>. Por ejemplo. Una línea del tipo <i>/config.php</i> ignorará el fichero <i>config.php</i> pero no ignorará <i>web/config.php.</i></li>
<li>Un asterisco <b>(*)</b> significa cualquier número de caracteres (cero o más).</li>
<li>Dos asteriscos <b>(**)</b> especifican cualquier número de subdirectorios.</li>
<li>Un signo de interrogación <b>(?)</b> reemplaza cero o un carácter.</li>
<li>Un signo de exclamación <b>(!)</b> designa la regla de inversión (es decir, incluye cualquier archivo que haya sido excluido por un patrón anterior).</li>
<li>Las líneas en blanco se ignoran, por lo que puede usarlas para agregar espacio y hacer que su archivo sea más fácil de leer.</li>
<li>El carácter <b>/</b> al final sólo se aplicará a carpetas. Por ejemplo. <i>web/</i> ignorará la carpeta <i>web/</i> pero no ignorará un fichero que se llame <i>web</i>.</li>
</ul>
<p>Otro ejemplo:</p>
<span class="container_code">
<pre><code class="properties"
># Ignora los ficheros bg-01.jpg y bg-lt.jpg
bg-??.jpg
# No ignora los ficheros bg-1.jpg y bg-001.jpg</code></pre>
</span>
<p>Este patrón ignorará los ficheros cuyos nombres empiezan por <b><i>bg-</i></b>, seguidos exactamente de dos caracteres, y luego vayan seguidos de <b><i>.jpg</i></b>. Por eso el fichero <b><i>bg-1.jpg</i></b> no se ignora, porque entre <b><i>bg-</i></b> y <b><i>.jpg</i></b> no hay dos caracteres, sólo uno. Este ejemplo ilustra que el símbolo <b>(?)</b> no indica un caracter opcional.
</p>
<h4>Archivos <i>.gitignore</i> locales frente a globales</h4>
<p>
Hay dos tipos de archivos <i>.gitignore</i>:
</p>
<ul>
<li><b>Local:</b> Ubicado en la raíz de su repositorio de Git, funciona solo en ese repositorio y debe estar comprometido con el repositorio.</li>
<li><b>Global:</b> Ubicado en la raíz de su directorio de inicio, afecta a todos los repositorios que usa en su máquina, no necesita ser confirmado.</li>
</ul>
<p>Muchos desarrolladores usan un archivo <i>.gitignore</i> local en su repositorio de proyectos, pero muy pocos usan el archivo <i>.gitignore</i> global. Las ventajas más importantes de usar un archivo global son que no necesitas hacerle <i>commit</i> (confirmarlo) para usarlo y hacer un cambio afecta a todos sus repositorios.</p>
<p>Para obtener más información sobre <i>.gitignore</i> global puedes seguir el siguiente enlace: <a rel="noreferrer noopener" href="https://sebastiandedeyne.com/setting-up-a-global-gitignore-file/" target="_blank">https://sebastiandedeyne.com/setting-up-a-global-gitignore-file/</a>.</p>
</div>
</details>
<!-- Tabline -->
<details>
<summary><h3><i>Rebase</i> <span class="span_h">Fusión Agresiva</span></h3></summary>
<div class="section_content">
<p>Este comando es muy útil para mover o combinar una secuencia de confirmaciones (<i>commits</i>) en una nueva confirmación base.</p>
<p><i>Rebase</i> sirve para reescribir el historial de una rama sobre otra. Es importante que recuerdes que usar este comando es una <b>mala práctica</b>, debido a que peudes causar cambios en el historil de la rama principal. Aunque recuerda que puedes usar este comando en repositorios locales o ramas que una se fusionarán a master de forma directa.</p>
<h4>Comparando <i>Rebase</i> con <i>Merge</i></h4>
<p>Un merge suele integrar todos los cambios de una rama en un commit que se ejecuta con el comando <i>git merge</i>. Un ejemplo de integración de cambios de una rama a otra con <i>merge</i> es la siguiente:</p>
<figure><img src="./images/rebase-merge.svg" alt="Ejemplo de merge en sección de rebase"></figure>
<p>En cambio, <i>rebase</i> fusiona los historiales de cambios de las dos ramas. El <i>log</i> de cambios se vería así:</p>
<figure><img src="./images/rebase-rebase-01.svg" alt="Ejemplo de rebase"></figure>
<hr>
<p>Este comando se debe ejecutar igual que <i>git merge</i>, es decir, sobre la rama principal. Pero antes de eso, es buena idea ejecutarlo desde la rama secundaria para establecer el commit base sobre el <span><i>HEAD</i></span> de <i>master</i>. De la siguiente manera:</p>
<pre class="container_code"><code class="linux_code properties">git checkout bug_fix</code><br><code class="linux_code properties">git rebase master</code></pre>
<p>Una forma de visualizar el cambio es la siguiente:</p>
<figure><img src="./images/rebase-rebase-02.svg" alt="Ejemplo de rebase"></figure>
<p>Ahora sí podremos ejecutar <i>git rebase</i> sin problemas sobre la rama principal:</p>
<pre class="container_code"><code class="linux_code properties">git checkout master</code><br><code class="linux_code properties">git rebase bug_fix</code></pre>
<blockquote cite="https://platzi.com/comentario/1348679/">
<h4>"No reorganices el historial público</h4>
<p>Nunca debes reorganizar las confirmaciones una vez que se hayan enviado a un repositorio público. La reorganización sustituiría las confirmaciones antiguas por las nuevas y parecería que esa parte del historial de tu proyecto se hubiera desvanecido de repente."</p>
<a rel="noopener noreferrer" href="https://platzi.com/comentario/1348679/" target="_blank">@diazpolanco13</a>
</blockquote>
</div>
</details>
<!-- Tabline -->
<details>
<summary><h3><i>Stash</i> <span class="span_h">Guardar cambios temporalmente</span></h3></summary>
<div class="section_content">
<p>El comando <i>git stash</i> almacena temporalmente (o guarda en un <i>stash</i>) los cambios que hayas efectuado en el código en el que estás trabajando para que puedas trabajar en otra cosa y, más tarde, regresar y volver a aplicar los cambios más tarde. Guardar los cambios en stashes resulta práctico si tienes que cambiar rápidamente de contexto y ponerte con otra cosa, pero estás en medio de un cambio en el código y no lo tienes todo listo para confirmar los cambios.</p>
<p>Imagina que estás en la rama <i>master</i> haciendo tu trabajo, y quieres ir a otra rama para ver algunos cambios. Una solución sería hacer <i>commit</i> a tu avance y cambiar de rama ¿cierto? Pero, qué pasa cuando los cambios no están listos para ser confirmados. Una solución es guardarlos en el <i>staging area</i> y volver a ellos cuando sea necesario</p>
<h4><i>Stashed</i></h4>
<p>El <i>stashed</i> sirve para guardar cambios que serán necesarios en otro momento, <b>es una lista de estados</b> que guarda los cambios que hemos hecho en el <i>staging area</i>, para poder cambiar de rama sin perder el trabajo que todavía no guardamos en un <i>commit</i>.</p>
<p>Una vez almacenados los cambios del <i>staging area</i>, te permite cambiar de ramas, hacer cambios en los archivos, trabajar en otras cosas sin preocupaciones y, más adelante, retomar el trabajo con los archivos que tenías guardados en ese <i>stash</i>.</p>
<h4>Guardar cambios en un <i>stash</i></h4>
<p><i>git stash</i> coge los cambios sin confirmar (tanto los que están preparados como los que no), los guarda aparte para usarlos más adelante y, acto seguido, los deshace en el código en el que estás trabajando (Regresa al último <i>commit</i>).</p>
<p>Un <i>stash</i> se crea de forma muy simple. Únicamente tienes que ejecutar el siguiente comando:</p>
<pre class="container_code"><code class="linux_code properties">git stash</code></pre>
<h4>Volver a aplicar los cambios de un <i>stash</i></h4>
<p>Para volver a aplicar los cambios almacenados en el <i>stash</i>, sólo debes ejecutar el siguiente comando:</p>
<pre class="container_code"><code># Traer los cambios del último stash y eliminarlo</code><br><code class="linux_code properties">git stash pop</code><br><br><code># Traer los cambios del último stash y mantenerlo</code><br><code class="linux_code properties">git stash apply</code></pre>
<p><i>Stash apply</i> resulta especialmente útil si quieres aplicar los mismos cambios de un stash en varias ramas.</p>
<p>De forma predeterminada, <i>git stash pop</i> volverá a aplicar el último stash creado: <i>stash@{0}</i>. Puedes elegir el stash que deseas volver a aplicar poniendo su identificador como último argumento, por ejemplo:</p>
<pre class="container_code"><code class="linux_code properties">git stash pop stash@{2}</code></pre>
<h4>Gestión de varios <i>stashes</i></h4>
<p>No tienes por qué limitarte a usar un stash a la vez. Puedes guardar tantos como necesites. Si deseas ver la lista de los <i>stashes</i> guardados sólo debes ejecutar el siguiente comando:</p>
<pre class="container_code"><code class="linux_code properties">git stash list</code></pre>
<p>A medida que avances y veas que tu flujo de trabajo con <i>git stash</i> se vuelve más complejo, notarás que es muy difícil identificar el <i>stash</i> correcto con los cambios que estás buscando. Para hacer hacer esta tarea más fácil. Se le puede añadir una etiqueta a cada <i>stash</i> que necesites crear. Eso se hace de la siguiente manera:</p>
<pre class="container_code"><code class="linux_code properties">git stash save "Estilos añadidos al sitio"</code></pre>
<h4>Eliminar <i>stashes</i></h4>
<p>Por último, para eliminar un <i>stash</i> que no necesitas sólo debes ejecutar el siguiente comando:</p>
<pre class="container_code"><code># Eliminar el útimo stash creado</code><br><code class="linux_code properties">git stash drop</code><br><br><code># Si conoces el identificador del stash en el que estás trabajando puedes especificarlo</code><br><code class="linux_code properties">git stash drop stash@{2}</code><br><br><code># Para eliminar todos los stashes</code><br><code class="linux_code properties">git stash clear</code></pre>
<h4>Crear Ramas a partir del <i>stash</i></h4>
<p>Puedes crear una nueva rama a partir de los cambios almacenados en tu <i>stash</i>. Para eso puedes usar el siguiente comando:</p>
<pre class="container_code"><code class="linux_code properties">git stash branch "nombre de la rama"</code></pre>
</div>
</details>
<!-- Tabline -->
<details>
<summary><h3><i>Clean</i> <span class="span_h">Limpiar el espacio de trabajo</span></h3></summary>
<div class="section_content">
<p>A veces creamos archivos cuando estamos realizando nuestro proyecto que realmente no forman parte de nuestro directorio de trabajo, que no se deberían agregar. Para eliminar de nuestro espacio de trabajo estos archivos, usamos el comando <i>git clean</i>.</p>
<p>Algunos ejemplos de archivos que no son parte de nuestro proyecto pueden ser <i>.logs</i>, resultados de alguna compilación o imágenes fuera de los directorios ignorados. Para ejecutar este comando usamos los siguientes comandos:</p>
<pre class="container_code"><code># Mostrar lista de los archivos que serán eliminados</code><br><code class="linux_code properties">git clean --dry-run</code><br><br><code># Borrar los archivos listados (excepto carpetas)</code><br><code class="linux_code properties">git clean -f</code></pre>
</div>
</details>
<!-- Tabline -->
<details>
<summary><h3><i>Cherry-pick</i> <span class="span_h">Git</span></h3></summary>
<div class="section_content">
<p><b>Cherry-pick</b> es un comando muy útil para traer los cambios de un <i>commit</i> con locación en otra rama del repositorio. Puedes ver de forma gráfica lo que hace este comando:</p>
<figure><img src="./images/cherry-pick.svg" alt="Representación gráfica de cherry pick"></figure>
<p>Para ejecutar este comando debes indicar el <i>commit</i> del que vas a traer los cambios. Se ejecuta de la siguiete manera:</p>
<pre class="container_code"><code class="linux_code properties">git cherry-pick 1e6176f</code></pre>
</div>
</details>
<!-- Tabline -->
<details open>
<summary><h3><i>Amend, Reset, Reflog y Grep</i> <span class="span_h">Úsese en caso de emergencia</span></h3></summary>
<div class="section_content">
<h4>Reconstruir commits con <i>Git amend</i>.</h4>
<p>Seguramente te ha pasado que publicas un <i>commit</i> que aun no estaba listo. Pero te das cuenta después de haberlo confirmado. <i>Amend</i> es un comando que justamente sirve para "remendar" los errores del último <i>commit</i> enviado. Con él puedes modificar tanto el mensaje como los archivos o cambios que involucra. Para invocarlo solo tienes que añadir los cambios con que faltaron con <i>git add .</i> y luego publicar un nuevo mensaje para ese <i>commit</i>. Eso se hace de la siguiente manera:</p>
<pre class="container_code"><code class="properties"># Para Añadir nuevos cambios.</code><br><code class="linux_code properties">git add .</code><br><br><code class="properties"># Para corregir el mensaje y guardar los cambios.</code><br><code class="linux_code properties">git amend -m "Añadidos estilos de mi website"</code></pre>
</div>
</details>
<!-- Tabline -->
</details>
<!-- Final del código de la actividad -->
</menu>
<footer>
<p>Mi Blogsito en la WEB <span>By: Jorge A. Gómez</span></p>
</footer>
<script src="./script.js"></script>
</body>
</html>