blogPost.html

<!DOCTYPE html>
<html lang="en">
<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">
    <title>Document</title>
    <link rel="stylesheet" href="css/styles.css" />
</head>
<body>
    <div id="cabecera">
        Hyperblog
        <span id="tagline">Tu blog de confianza</span>
        </div>
    <div id="container">
   
        <div id="post">
          <h1>¿Que es el staging y los repositorios?</h1>
          <p>
            Para iniciar un repositorio, o sea, activar el sistema de control de versiones de GIt en el proyecto, solo debes  ejecutar el comando git init.
Este comando se encargará de dos cosas: primero , crear una carpeta .git, donde se guardará todas la base de datos con cambios atómicos de nuestro proyecto; y segundo, creará un área conocida como Staging, que guardará temporalmente nuestros archivos ( cuando ejecutemos el comando add ) y nos permitirá, más adelante, guardar  estos cambios en el repositorio ( con el comando commit).

Ciclo de vida o estados de los archivos en Git:
Cuando trabajamos con git nuestros archivos pueden vivir y moverse entre 4 estados diferentes (cuando trabajamos con repositorios remotos pueden ser más estados):

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

. Archivos Staged: son archivos en Staging. Viven dentro de GIt y  son los que han sido  añadidos por el comando git add, aunque no se han consolidado sus cambios. GIt sabe de la existencia de estos cambios, pero no han sido guardados definitivamente en el repositorio porque falta ejecutar el comando commit.

. Archivos Unstaged: son  como archivos en tracked pero Unstaged. Son archivos que viven en Git pero  no se les ha aplicado el comando git add ni el git commit. Git tiene un registro de estos archivos, pero no están actualizados, solo están guardadas sus últimas versiones  en el disco duro.

 . Archivos Untracked: son archivos que no viven dentro de GIt, solo en el disco duro. No se les ha aplicado git add, así que Git no tiene registro de us existencia. Solo hay un caso muy raro donde los archivos tienen dos estados al mismo tiempo: staged y untracked. Esto pasa cuando guardas cambios con el comando git add, y antes de hacer el commit haces nuevos cambios que no estan en el Staging porque  no has aplicado git add.
</p>
<h1> COMANDO PARA MOVER ARCHIVOS ENTRE LOS ESTADOS DE GIT:</h1>

<p>
 . git status: nos permite ver el estado de todos nuestros archivos y carpetas.
 . git add: nos ayuda a mover archivos del Untracked o Unstaged al estado Staged. Podemos usar git nombre-del-archivo-o-carpeta para añadir archivos y carpetas individuales o git add -A para mover todos los archivos de nuestro proyecto ( tanto los Untracked como los Unstaged).
 . git reset HEAD:  nos ayuda a traer archivos del estado Staged para devolverlos a su estado anterior. Si estaban los archivos en Unstaged, vuelven allí. Asi tambien como si estaban en Untracked.
 .git commit: nos ayuda a llevar archivos del estado Unstaged al estado Tracked.Este es el estado donde los archivos han sido guardados o actualizados en el repositorio. Git nos pedirá que dejemos un mensaje para recordar los cambios realizados y con el argumento -m escribirlo. (git commit -m).
 . git rm: este comando necesita alguno de los siguientes argumento para poder ejecutarse correctamente:
 .- git rm --cached: Lleva los archivos que le indiquemos al estado Untracked.
 .- git rm --force: Elimina los archivos de Git  y del disco duro. Git guarda el registro de la existencia de  los archivos, por lo que podremos recuperarlos si es necesario usando comandos más avanzados.

</p>
<h1>VOLVER EN EL TIEMPO EN NUESTRO REPOSITORIO UTILIZANDO RESET Y CHECKOUT</h1>
<p>
El comando git checkout + ID del commit nos permite viajar en el tiempo. Podremos volver a cualquier versión anterior de un archivo específico o incluso del proyecto entero. Esta es la forma de crear ramas y movernos entre ellas.
 
 Usando el comando git reset volvemos en el tiempo y borramos los cambios que hicimos después de este commit.
 Hay dos formas de usar gti reset: con el argumento --hard, borrando toda la información que tengamos en el área de staging ( y perdiendo todo para siempre). O, un poco más seguro, con el argumento --soft, que mantiene allí los archivos del área de staging para que podamos aplicar nuestros últimos cambios pero desde un commit anterior.
 Git reset y git rm son comandos con utilidades muy diferentes, pero aún así se confunden muy fácilmente.

<h2>GIT RM</h2>

<p>
  Este comando nos ayuda a eliminar archivos de GIt sin eliminar su historial del sistema de versiones. Esto quiere decir que si necesitamos recuperar el archivo solo debemos "viajar en el tiempo" y recuperar el último commit antes de borrar el archivo en cuestión.

  Recuerda que git rm no puede usarse así no má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:
<ul>
   <li>git rm --cached: 
      Elimina los archivos de nuestro repositorio local y el área de staging, pero los mantiene en nuestro disco duro. Básicamente le dice a GIT que deje de trackear el historial de cambios de estos archivos, por lo que pasarán a un estado untracked.</li> 
   <li>. 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).> </li>
   
  </ul>
</p>
  <h2>GIT RESET</h2>  
  <p>
   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 si la posibilidad de volver al futuro. Borramos la historia y la debemos sobreescribir. No hay vuelta a atrás.

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

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

    . git reset --soft: Borramos todo el historial y los registros de Git pero guardamos los cambios que tengamos en staging, así podemos aplicar las últimas actualizaciónes a un nuevo commit.

    . git reset --hard: Borra todo. Todo todito, absolutamente todo. Toda la información de los commit y del área de staging se borra del historioal.

    ¡Pero hay algo más!

    . git reset HEAD: este es el comando para sacar archivos del área de stagin. 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.
  </p>
<h1>¿PORQUE ES IMPORTANTE ESTO?</h1>
 <p>  
     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.

     ¡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 eliminacion del archivo como su última actualización. Recuerda que en este caso no buscábamos eliminar un archivo, solo dejarlo como estaba y actualizado después, no en este commit.

     En cambio si usamos git reset HEAD, lo único que harémos será move estos cambios de Staging a Unstaged. Seguiremos teniendo los últimos cambios en el archivo, el repositorio mantendrá el archivo ( no con sus últimos cambios pero si con los últimos en los que hicimos commit) y no habremos perdido nada.

     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.

     

          </p>
        </div>
        <div id="footer">
          Marca registada . 
        </div>
      </div>
 
  </body>
</html>