Comandos Git. config

git config

Git tiene una forma predeterminada de hacer cientos de cosas. Para muchas de estas cosas, puedes indicar a Git hacerlas por defecto de una manera diferente, o establecer tus preferencias. Esto incluye todo, desde decir a Git cuál es tu nombre a las preferencias de color específicas del terminal o qué editor utilizar. Hay varios archivos desde los que este comando lee y a los que escribe, así puedes establecer los valores a nivel global o hacia abajo para repositorios específicos.

establecer tu nombre de usuario y dirección de correo electrónico.

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

elegir el editor de texto por defecto

$ git config --global core.editor emacs

comprobar tu configuración

$ git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

También puedes comprobar qué valor que Git utilizará para una clave específica ejecutando git config <key>:

$ git config user.name
John Doe

Si no quieres teclear el nombre completo de cada comando de Git, puedes establecer fácilmente un alias para cada comando mediante git config. Aquí tienes algunos ejemplos que te pueden interesar:

$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status

Esta técnica también puede resultar útil para crear comandos que en tu opinión deberían existir. Por ejemplo, para corregir el problema de usabilidad que encontraste al quitar del área de preparación un archivo, puedes añadir tu propio alias a Git:

$ git config --global alias.unstage 'reset HEAD --'

Esto hace que los dos comandos siguientes sean equivalentes:

$ git unstage fileA
$ git reset HEAD fileA

Esto parece un poco más claro. También es frecuente añadir un comando last, de este modo:

$ git config --global alias.last 'log -1 HEAD'

De esta manera, puedes ver fácilmente cuál fue la última confirmación:

$ git last
commit 66938dae3329c7aebe598c2246a8e6af90d04646
Author: Josh Goebel <dreamer3@example.com>
Date:   Tue Aug 26 19:48:51 2008 +0800

    test for current head

    Signed-off-by: Scott Chacon <schacon@example.com>

Como puedes ver, Git simplemente sustituye el nuevo comando por lo que sea que hayas puesto en el alias. Sin embargo, quizás quieras ejecutar un comando externo, en lugar de un subcomando de Git. En ese caso, puedes comenzar el comando con un carácter !. Esto resulta útil si escribes tus propias herramientas para trabajar con un repositorio de Git. Podemos demostrarlo creando el alias git visual para ejecutar gitk:

$ git config --global alias.visual "!gitk"

Git. Eliminar, renombras archivos.

Eliminar Archivos

Para eliminar archivos de Git, debes eliminarlos de tus archivos rastreados (o mejor dicho, eliminarlos del área de preparación) y luego confirmar. Para ello existe el comando git rm, que además elimina el archivo de tu directorio de trabajo de manera que no aparezca la próxima vez como un archivo no rastreado.

Si simplemente eliminas el archivo de tu directorio de trabajo, aparecerá en la sección “Changes not staged for commit” (esto es, sin preparar) en la salida de git status:

$ rm PROJECTS.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    PROJECTS.md

no changes added to commit (use "git add" and/or "git commit -a")

Ahora, si ejecutas git rm, entonces se prepara la eliminación del archivo:

$ git rm PROJECTS.md
rm 'PROJECTS.md'
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    PROJECTS.md

Con la próxima confirmación, el archivo habrá desaparecido y no volverá a ser rastreado. Si modificaste el archivo y ya lo habías añadido al índice, tendrás que forzar su eliminación con la opción -f. Esta propiedad existe por seguridad, para prevenir que elimines accidentalmente datos que aun no han sido guardados como una instantánea y que por lo tanto no podrás recuperar luego con Git.

Otra cosa que puedas querer hacer es mantener el archivo en tu directorio de trabajo pero eliminarlo del área de preparación. En otras palabras, quisieras mantener el archivo en tu disco duro pero sin que Git lo siga rastreando. Esto puede ser particularmente útil si olvidaste añadir algo en tu archivo .gitignore y lo preparaste accidentalmente, algo como un gran archivo de trazas a un montón de archivos compilados .a. Para hacerlo, utiliza la opción --cached:

$ git rm --cached README

Al comando git rm puedes pasarle archivos, directorios y patrones glob. Lo que significa que puedes hacer cosas como

$ git rm log/\*.log

Fíjate en la barra invertida (\) antes del asterisco *. Esto es necesario porque Git hace su propia expansión de nombres de archivo, aparte de la expansión hecha por tu terminal. Este comando elimina todos los archivo que tengan la extensión .log dentro del directorio log/. O también puedes hacer algo como:

$ git rm \*~

Este comando elimina todos los archivos que acaben con ~.

Cambiar el Nombre de los Archivos

Al contrario que muchos sistemas VCS, Git no rastrea explícitamente los cambios de nombre en archivos. Si renombras un archivo en Git, no se guardará ningún metadato que indique que renombraste el archivo. Sin embargo, Git es bastante listo como para detectar estos cambios luego que los has hecho - más adelante, veremos cómo se detecta el cambio de nombre.

Por esto, resulta confuso que Git tenga un comando mv. Si quieres renombrar un archivo en Git, puedes ejecutar algo como

$ git mv file_from file_to

y funcionará bien. De hecho, si ejecutas algo como eso y ves el estatus, verás que Git lo considera como un renombramiento de archivo:

$ git mv README.md README
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Sin embargo, eso es equivalente a ejecutar algo como esto:

$ mv README.md README
$ git rm README.md
$ git add README

 Git se da cuenta que es un renombramiento implícito, así que no importa si renombras el archivo de esa manera o a través del comando mv. La única diferencia real es que mv es un solo comando en vez de tres - existe por conveniencia. De hecho, puedes usar la herramienta que quieras para renombrar un archivo y luego realizar el proceso rm/add antes de confirmar.

fuente: https://git-scm.com/book/es/

Git. Deshacer cosas

En cualquier momento puede que quieras deshacer algo. Aquí repasaremos algunas herramientas básicas usadas para deshacer cambios que hayas hecho. Ten cuidado, a veces no es posible recuperar algo luego que lo has deshecho. Esta es una de las pocas áreas en las que Git puede perder parte de tu trabajo si cometes un error.

Uno de las acciones más comunes a deshacer es cuando confirmas un cambio antes de tiempo y olvidas agregar algún archivo, o te equivocas en el mensaje de confirmación. Si quieres rehacer la confirmación, puedes reconfirmar con la opción --amend:

$ git commit --amend

Este comando utiliza tu área de preparación para la confirmación. Si no has hecho cambios desde tu última confirmación (por ejemplo, ejecutas este comando justo después de tu confirmación anterior), entonces la instantánea lucirá exactamente igual, y lo único que cambiarás será el mensaje de confirmación.

Se lanzará el mismo editor de confirmación, pero verás que ya incluye el mensaje de tu confirmación anterior. Puedes editar el mensaje como siempre y se sobreescribirá tu confirmación anterior.

Por ejemplo, si confirmas y luego te das cuenta que olvidaste preparar los cambios de un archivo que querías incluir en esta confirmación, puedes hacer lo siguiente:

$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend

Al final terminarás con una sola confirmación - la segunda confirmación reemplaza el resultado de la primera.

Deshacer un Archivo Preparado

 

Las siguientes dos secciones demuestran cómo lidiar con los cambios de tu área de preparación y tú directorio de trabajo. Afortunadamente, el comando que usas para determinar el estado de esas dos áreas también te recuerda cómo deshacer los cambios en ellas. Por ejemplo, supongamos que has cambiado dos archivos y que quieres confirmarlos como dos cambios separados, pero accidentalmente has escrito git add * y has preparado ambos. ¿Cómo puedes sacar del área de preparación uno de ellos? El comando git status te recuerda cómo:

$ git add .
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README
    modified:   CONTRIBUTING.md

Justo debajo del texto “Changes to be committed” (“Cambios a ser confirmados”, en inglés), verás que dice que uses git reset HEAD <file>... para deshacer la preparación. Por lo tanto, usemos el consejo para deshacer la preparación del archivo CONTRIBUTING.md:

$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

El comando es un poco raro, pero funciona. El archivo CONTRIBUTING.md esta modificado y, nuevamente, no preparado.

A pesar de que git reset puede ser un comando peligroso si lo llamas con --hard, en este caso el archivo que está en tu directorio de trabajo no se toca. Ejecutar git reset sin opciones no es peligroso - solo toca el área de preparación.

Por ahora lo único que necesitas saber sobre el comando git reset es esta invocación mágica. Entraremos en mucho más detalle sobre qué hace reset y como dominarlo para que haga cosas realmente interesantes en Reiniciar Desmitificado.

Deshacer un Archivo Modificado

 

¿Qué tal si te das cuenta que no quieres mantener los cambios del archivo CONTRIBUTING.md? ¿Cómo puedes restaurarlo fácilmente - volver al estado en el que estaba en la última confirmación (o cuando estaba recién clonado, o como sea que haya llegado a tu directorio de trabajo)? Afortunadamente, git status también te dice cómo hacerlo. En la salida anterior, el área no preparada lucía así:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

 Allí se te indica explícitamente como descartar los cambios que has hecho. Hagamos lo que nos dice:

$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Ahora puedes ver que los cambios se han revertido.

Es importante entender que git checkout -- [archivo] es un comando peligroso. Cualquier cambio que le hayas hecho a ese archivo desaparecerá - acabas de sobreescribirlo con otro archivo. Nunca utilices este comando a menos que estés absolutamente seguro de que ya no quieres el archivo.

Recuerda, todo lo que esté confirmado en Git puede recuperarse. Incluso commits que estuvieron en ramas que han sido eliminadas o commits que fueron sobreescritos con --amend pueden recuperarse (véase Recuperación de datos para recuperación de datos). Sin embargo, es posible que no vuelvas a ver jamás cualquier cosa que pierdas y que nunca haya sido confirmada.

Git. Confirmar cambios

Confirmar tus Cambios

 

Ahora que tu área de preparación está como quieres, puedes confirmar tus cambios. Recuerda que cualquier cosa que no esté preparada - cualquier archivo que hayas creado o modificado y que no hayas agregado con git add desde su edición - no será confirmado. Se mantendrán como archivos modificados en tu disco. En este caso, digamos que la última vez que ejecutaste git status verificaste que todo estaba preparado y que estás listos para confirmar tus cambios. La forma más sencilla de confirmar es escribiendo git commit:

$ git commit

Al hacerlo, arrancará el editor de tu preferencia. (El editor se establece a través de la variable de ambiente $EDITOR de tu terminal - usualmente es vim o emacs, aunque puedes configurarlo con el editor que quieras usando el comando git config --global core.editor tal como viste en Inicio - Sobre el Control de Versiones).

El editor mostrará el siguiente texto (este ejemplo corresponde a una pantalla de Vim):
 

 

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# new file:   README
# modified:   CONTRIBUTING.md
#
~
~
~
".git/COMMIT_EDITMSG" 9L, 283C

 

Puedes ver que el mensaje de confirmación por defecto contiene la última salida del comando git status comentada y una línea vacía encima de ella. Puedes eliminar estos comentarios y escribir tu mensaje de confirmación, o puedes dejarlos allí para ayudarte a recordar qué estás confirmando. (Para obtener una forma más explícita de recordar qué has modificado, puedes pasar la opción -v a git commit. Al hacerlo se incluirá en el editor el diff de tus cambios para que veas exactamente qué cambios estás confirmando.) Cuando sales del editor, Git crea tu confirmación con tu mensaje (eliminando el texto comentado y el diff).

Otra alternativa es escribir el mensaje de confirmación directamente en el comando commit utilizando la opción -m:
 

$ git commit -m "Story 182: Fix benchmarks for speed"
[master 463dc4f] Story 182: Fix benchmarks for speed
 2 files changed, 2 insertions(+)
 create mode 100644 README

 

¡Has creado tu primera confirmación (o commit)! Puedes ver que la confirmación te devuelve una salida descriptiva: indica cuál rama has confirmado (master), que checksum SHA-1 tiene el commit (463dc4f), cuántos archivos han cambiado y estadísticas sobre las líneas añadidas y eliminadas en el commit.

Recuerda que la confirmación guarda una instantánea de tu área de preparación. Todo lo que no hayas preparado sigue allí modificado; puedes hacer una nueva confirmación para añadirlo a tu historial. Cada vez que realizas un commit, guardas una instantánea de tu proyecto la cual puedes usar para comparar o volver a ella luego.

Saltar el Área de Preparación

 

A pesar de que puede resultar muy útil para ajustar los commits tal como quieres, el área de preparación es a veces un paso más complejo a lo que necesitas para tu flujo de trabajo. Si quieres saltarte el área de preparación, Git te ofrece un atajo sencillo. Añadiendo la opción -a al comando git commit harás que Git prepare automáticamente todos los archivos rastreados antes de confirmarlos, ahorrándote el paso de git add:

 

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -a -m 'added new benchmarks'
[master 83e38c7] added new benchmarks
 1 file changed, 5 insertions(+), 0 deletions(-)

 

Fíjate que en este caso no fue necesario ejecutar git add sobre el archivo CONTRIBUTING.md antes de confirmar.

 

Git. diff

Ver los Cambios Preparados y No Preparados

Si el comando git status es muy impreciso para ti - quieres ver exactamente que ha cambiado, no solo cuáles archivos lo han hecho - puedes usar el comando git diff. Hablaremos sobre git diff más adelante, pero lo usarás probablemente para responder estas dos preguntas: ¿Qué has cambiado pero aun no has preparado? y ¿Qué has preparado y está listo para confirmar? A pesar de que git status responde a estas preguntas de forma muy general listando el nombre de los archivos, git diff te muestra las líneas exactas que fueron añadidas y eliminadas, es decir, el parche.

Supongamos que editas y preparas el archivo README de nuevo y luego editas CONTRIBUTING.md pero no lo preparas. Si ejecutas el comando git status, verás algo como esto:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Para ver qué has cambiado pero aun no has preparado, escribe git diff sin más parámetros:

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
 Please include a nice description of your changes when you submit your PR;
 if we have to read the whole diff to figure out why you're contributing
 in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if you patch 

is
+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR
 that highlights your work in progress (and note in the PR title that it's

Este comando compara lo que tienes en tu directorio de trabajo con lo que está en el área de preparación. El resultado te indica los cambios que has hecho pero que aun no has preparado.

Si quieres ver lo que has preparado y será incluido en la próxima confirmación, puedes usar git diff --staged. Este comando compara tus cambios preparados con la última instantánea confirmada.
 

$ git diff --staged
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+My Project

Es importante resaltar que al llamar a git diff sin parámetros no verás los cambios desde tu última confirmación - solo verás los cambios que aun no están preparados. Esto puede ser confuso porque si preparas todos tus cambios, git diff no te devolverá ninguna salida.

Pasemos a otro ejemplo, si preparas el archivo CONTRIBUTING.md y luego lo editas, puedes usar git diff para ver los cambios en el archivo que están preparados y los cambios que no lo están. Si nuestro ambiente es como este:

$ git add CONTRIBUTING.md
$ echo 'test line' >> CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Puedes usar git diff para ver qué está sin preparar

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 643e24f..87f08c8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -119,3 +119,4 @@ at the
 ## Starter Projects

 See our [projects list](https://github.com/libgit2/libgit2/blob/development/

PROJECTS.md).

y git diff --cached para ver que has preparado hasta ahora (--staged y --cached son sinónimos):

$ git diff --cached
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
 Please include a nice description of your changes when you submit your PR;
 if we have to read the whole diff to figure out why you're contributing
 in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if you patch is
+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR
 that highlights your work in progress (and note in the PR title that it's

fuente: https://git-scm.com/book/es

Git. Ignorar archivos

A veces, tendrás algún tipo de archivo que no quieres que Git añada automáticamente o más aun, que ni siquiera quieras que aparezca como no rastreado. Este suele ser el caso de archivos generados automáticamente como trazas o archivos creados por tu sistema de construcción. En estos casos, puedes crear un archivo llamado .gitignore que liste patrones a considerar. Este es un ejemplo de un archivo .gitignore:

$ cat .gitignore
*.[oa]
*~

La primera línea le indica a Git que ignore cualquier archivo que termine en “.o” o “.a” - archivos de objeto o librerías que pueden ser producto de compilar tu código. La segunda línea le indica a Git que ignore todos los archivos que termine con una tilde (~), lo cual es usado por varios editores de texto como Emacs para marcar archivos temporales. También puedes incluir cosas como trazas, temporales, o pid directamente; documentación generada automáticamente; etc. Crear un archivo .gitignore antes de comenzar a trabajar es generalmente una buena idea pues así evitas confirmar accidentalmente archivos que en realidad no quieres incluir en tu repositorio Git.

Las reglas sobre los patrones que puedes incluir en el archivo .gitignore son las siguientes:

• Ignorar las líneas en blanco y aquellas que comiencen con #.
  
• Aceptar patrones glob estándar.
  
• Los patrones pueden terminar en barra (/) para especificar un directorio.
  
• Los patrones pueden negarse si se añade al principio el signo de exclamación (!).
  

Los patrones glob son una especia de expresión regular simplificada usada por los terminales. Un asterisco (*) corresponde a cero o más caracteres; [abc] corresponde a cualquier carácter dentro de los corchetes (en este caso a, b o c); el signo de interrogación (?) corresponde a un carácter cualquier; y los corchetes sobre caracteres separados por un guión ([0-9]) corresponde a cualquier carácter entre ellos (en este caso del 0 al 9). También puedes usar dos asteriscos para indicar directorios anidados; a/**/z coincide con a/z, a/b/z, a/b/c/z, etc.

Aquí puedes ver otro ejemplo de un archivo .gitignore:

# ignora los archivos terminados en .a
*.a

# pero no lib.a, aun cuando había ignorado los archivos terminados en 

 .a en la linea anterior

 !lib.a

# ignora unicamente el archivo TODO de la raiz, no subdir/TODO
/TODO

# ignora todos los archivos del directorio build/
build/

# ignora doc/notes.txt, pero este no doc/server/arch.txt
doc/*.txt

# ignora todos los archivos .txt el directorio doc/
doc/**/*.txt

GitHub mantiene una extensa lista de archivos .gitignore adecuados a docenas de proyectos y lenguajes en https://github.com/github/gitignore en caso de que quieras tener un punto de partida para tu proyecto.

 fuente: https://git-scm.com/book/es

Git. Preparar archivos

Rastrear Archivos Nuevos

Para comenzar a rastrear un archivo debes usar el comando git add. Para comenzar a rastrear el archivo README, puedes ejecutar lo siguiente:

$ git add README

Ahora si vuelves a ver el estado del proyecto, verás que el archivo README está siendo rastreado y está preparado para ser confirmado:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Puedes ver que está siendo rastreado porque aparece luego del encabezado “Cambios a ser confirmados” (“Changes to be committed” en inglés). Si confirmas en este punto, se guardará en el historial la versión del archivo correspondiente al instante en que ejecutaste git add. Anteriormente cuando ejecutaste git init, ejecutaste luego git add (files) - lo cual inició el rastreo de archivos en tu directorio. El comando git add puede recibir tanto una ruta de archivo como de un directorio; si es de un directorio, el comando añade recursivamente los archivos que están dentro de él.

Preparar Archivos Modificados

Vamos a cambiar un archivo que esté rastreado. Si cambias el archivo rastreado llamado “CONTRIBUTING.md” y luego ejecutas el comando git status, verás algo parecido a esto:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

El archivo “CONTRIBUTING.md” aparece en una sección llamada “Changes not staged for commit” (“Cambios no preparado para confirmar” en inglés) - lo que significa que existe un archivo rastreado que ha sido modificado en el directorio de trabajo pero que aun no está preparado. Para prepararlo, ejecutas el comando git add. git add es un comando que cumple varios propósitos - lo usas para empezar a rastrear archivos nuevos, preparar archivos, y hacer otras cosas como marcar como resuelto archivos en conflicto por combinación. Es más útil que lo veas como un comando para “añadir este contenido a la próxima confirmación” mas que para “añadir este archivo al proyecto”. Ejecutemos git add para preparar el archivo “CONTRIBUTING.md” y luego ejecutemos git status:

$ git add CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

 Ambos archivos están preparados y formarán parte de tu próxima confirmación. En este momento, supongamos que recuerdas que debes hacer un pequeño cambio en CONTRIBUTING.md antes de confirmarlo. Abres de nuevo el archivo, lo cambias y ahora estás listos para confirmar. Sin embargo, ejecutemos git status una vez más:

$ vim CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

¡¿Pero qué…​?! Ahora CONTRIBUTING.md aparece como preparado y como no preparado. ¿Cómo es posible? Resulta que Git prepara un archivo de acuerdo al estado que tenía cuando ejecutas el comando git add. Si confirmas ahora, se confirmará la versión de CONTRIBUTING.md que tenías la última vez que ejecutaste git add y no la versión que ves ahora en tu directorio de trabajo al ejecutar git commit. Si modificas un archivo luego de ejecutar git add, deberás ejecutar git add de nuevo para preparar la última versión del archivo:

$ git add CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Estatus Abreviado

Si bien es cierto que la salida de git status es bastante explícita, también es verdad que es muy extensa. Git ofrece una opción para obtener un estatus abreviado, de manera que puedas ver tus cambios de una forma más compacta. Si ejecutas git status -s o git status --short obtendrás una salida mucho más simplificada.

$ git status -s
 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

Los archivos nuevos que no están rastreados tienen un ?? a su lado, los archivos que están preparados tienen una A y los modificados una M. El estado aparece en dos columnas - la columna de la izquierda indica el estado preparado y la columna de la derecha indica el estado sin preparar. Por ejemplo, en esa salida, el archivo README está modificado en el directorio de trabajo pero no está preparado, mientras que lib/simplegit.rb está modificado y preparado. El archivo Rakefile fue modificado, preparado y modificado otra vez por lo que existen cambios preparados y sin preparar.

fuente: https://git-scm.com/book/es

Git. Primeros pasos

Inicializando un repositorio en un directorio existente

Si estás empezando a seguir un proyecto existente en Git, debes ir al directorio del proyecto y usar el siguiente comando:

$ git init

Esto crea un subdirectorio nuevo llamado .git, el cual contiene todos los archivos necesarios del repositorio – un esqueleto de un repositorio de Git. Todavía no hay nada en tu proyecto que esté bajo seguimiento. Puedes revisar Los entresijos internos de Git para obtener más información acerca de los archivos presentes en el directorio .git que acaba de ser creado.

Si deseas empezar a controlar versiones de archivos existentes (a diferencia de un directorio vacío), probablemente deberías comenzar el seguimiento de esos archivos y hacer una confirmación inicial. Puedes conseguirlo con unos pocos comandos git add para especificar qué archivos quieres controlar, seguidos de un git commit para confirmar los cambios:

$ git add *.c
$ git add LICENSE
$ git commit -m 'initial project version'

Si deseas obtener una copia de un repositorio Git existente — por ejemplo, un proyecto en el que te gustaría contribuir — el comando que necesitas es git clone. Si estás familizarizado con otros sistemas de control de versiones como Subversion, verás que el comando es "clone" en vez de "checkout". Es una distinción importante, ya que Git recibe una copia de casi todos los datos que tiene el servidor. Cada versión de cada archivo de la historia del proyecto es descargada por defecto cuando ejecutas git clone. De hecho, si el disco de tu servidor se corrompe, puedes usar cualquiera de los clones en cualquiera de los clientes para devolver al servidor al estado en el que estaba cuando fue clonado (puede que pierdas algunos hooks del lado del servidor y demás, pero toda la información acerca de las versiones estará ahí) — véase Configurando Git en un servidor para más detalles.

Puedes clonar un repositorio con git clone [url]. Por ejemplo, si quieres clonar la librería de Git llamada libgit2 puedes hacer algo así:

$ git clone https://github.com/libgit2/libgit2

Esto crea un directorio llamado libgit2, inicializa un directorio .git en su interior, descarga toda la información de ese repositorio y saca una copia de trabajo de la última versión. Si te metes en el directorio libgit2, verás que están los archivos del proyecto listos para ser utilizados. Si quieres clonar el repositorio a un directorio con otro nombre que no sea libgit2, puedes especificarlo con la siguiente opción de línea de comandos:

$ git clone https://github.com/libgit2/libgit2 mylibgit

Ese comando hace lo mismo que el anterior, pero el directorio de destino se llamará mylibgit.

Git te permite usar distintos protocolos de transferencia. El ejemplo anterior usa el protocolo https://, pero también puedes utilizar git:// o usuario@servidor:ruta/del/repositorio.git que utiliza el protocolo de transferencia SSH. En Configurando Git en un servidor se explicarán todas las opciones disponibles a la hora de configurar el acceso a tu repositorio de Git, y las ventajas e inconvenientes de cada una.

Guardando cambios en el Repositorio

Ya tienes un repositorio Git y un checkout o copia de trabajo de los archivos de dicho proyecto. El siguiente paso es realizar algunos cambios y confirmar instantáneas de esos cambios en el repositorio cada vez que el proyecto alcance un estado que quieras conservar.

Recuerda que cada archivo de tu repositorio puede tener dos estados: rastreados y sin rastrear. Los archivos rastreados (tracked files en inglés) son todos aquellos archivos que estaban en la última instantánea del proyecto; pueden ser archivos sin modificar, modificados o preparados. Los archivos sin rastrear son todos los demás - cualquier otro archivo en tu directorio de trabajo que no estaba en tu última instantánea y que no están en el área de preparación (staging area). Cuando clonas por primera vez un repositorio, todos tus archivos estarán rastreados y sin modificar pues acabas de sacarlos y aun no han sido editados.

Mientras editas archivos, Git los ve como modificados, pues han sido cambiados desde su último commit. Luego preparas estos archivos modificados y finalmente confirmas todos los cambios preparados, y repites el ciclo.

El ciclo de vida del estado de tus archivos.

Revisando el Estado de tus Archivos

La herramienta principal para determinar qué archivos están en qué estado es el comando git status. Si ejecutas este comando inmediatamente después de clonar un repositorio, deberías ver algo como esto:

$ git status
On branch master
nothing to commit, working directory clean

Esto significa que tienes un directorio de trabajo limpio - en otras palabras, que no hay archivos rastreados y modificados. Además, Git no encuentra ningún archivo sin rastrear, de lo contrario aparecerían listados aquí. Finalmente, el comando te indica en cuál rama estás y te informa que no ha variado con respecto a la misma rama en el servidor. Por ahora, la rama siempre será “master”, que es la rama por defecto; no le prestaremos atención ahora. Ramificaciones en Git tratará en detalle las ramas y las referencias.

Supongamos que añades un nuevo archivo a tu proyecto, un simple README. Si el archivo no existía antes, y ejecutas git status, verás el archivo sin rastrear de la siguiente manera:

$ echo 'My Project' > README
$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    README

nothing added to commit but untracked files present (use "git add" to track)

Puedes ver que el archivo README está sin rastrear porque aparece debajo del encabezado “Untracked files” (“Archivos no rastreados” en inglés) en la salida. Sin rastrear significa que Git ve archivos que no tenías en el commit anterior. Git no los incluirá en tu próximo commit a menos que se lo indiques explícitamente. Se comporta así para evitar incluir accidentalmente archivos binarios o cualquier otro archivo que no quieras incluir. Como tú sí quieres incluir README, debes comenzar a rastrearlo.

fuente: https://git-scm.com/book/es/

Nivel de prioridad del selector

Cálculo de la especificidad de un selector

El nivel de prioridad del selector se decide en el Punto de combinación de selectores.

•     atributo style = a

•     número de atributos de ID en el selector = b

•     número de otros atributos y pseudo-clases en el selector = c

•     número de nombres de elementos y pseudo-elementos en el selector = d

Por ejemplo, si es una combinación de los siguientes selectores:

[index.html]

<body>
  <article>
    <p>This is <span id="red">paragraph</span>.</p>
  </article>
</body>

[style.css]

article p span{
   color: blue;
 }
 #red{
   color: red;
 }

"article p span" son "a = 0, b = 0, c = 0, d = 3 (0003)".
"#red" es "a = 0, b = 1, c = 0, d = 0 (0100)".

En este caso, el párrafo se convierte en un caracter rojo. Porque "#red (0100)" es más grande que "article p span (0003)".


Ver también 6.4.3 Calculating a selector's specificity

Ejemplo

[index.html]

<body>
<div id="wrapper">
  <header id="top">
    <h1>W3C cafe</h1>
    <div id="hright">
      <nav>
        <ul id="gnavi">
          <li>menu</li>
          <li>location</li>
          <li>about us</li>
          <li>recruit</li>
        </ul>
      </nav>
    </div>
  </header>
</div>
</body>

[style.css] 

#wrapper header div nav #gnavi{
  list-style-type: none;
}
#top #hright #gnavi{
  list-style-type: square;
}

 

En este caso, los marcadores de la lista se cambian a "square". Porque "#top #hright #gnavi (a = 0, b = 3, c = 0, d = 0)" es más grande que "#wrapper header div nav #gnavi (a = 0, b = 2, c = 0, d = 3) ". 

Fuente: https://www.w3.org/community/webed/wiki/CSS/Training/Priority_level_of_selector

Herencia CSS

Herencia

Algunos valores son heredados por los elementos secundarios de un elemento en el árbol del documento:

 

Ejemplo

La propiedad 'font-size' para el elemento h1 tendrá el valor calculado '13pt' (130% multiplicado por 10pt, el valor del padre). Dado que el valor calculado de 'font-size' es heredado, el elemento em también tendrá el valor calculado '13pt'.

[style.css]

body { font-size: 10pt }
 h1 { font-size: 130% }

[index.html]

<body>
  <h1>A <em>large</em> heading</h1>
</body>

Ver también  6.2 Inheritance.

Fuente: https://www.w3.org/community/webed/wiki/CSS/Training/Inheritance

Cajas flotantes CSS

float

La propiedad float especifica si un cuadro debe flotar a la izquierda, a la derecha o no.

[Sintaxis]

float: left | right | none

• left: el elemento genera un cuadro de bloque que se flota hacia la izquierda. El contenido fluye en el lado derecho de la caja, comenzando en la parte superior.

• right: similar a 'left', excepto que la caja está flotando a la derecha, y el contenido fluye en el lado izquierdo de la caja, comenzando en la parte superior.

• none: el cuadro no está flotando.

 Ejemplo

[style.css]

p{
  width: 100px;
  height: 100px;
  float: left;
}
p#red{
  background-color: red;
}
p#blue{
  background-color: blue;
}

[index.html]

<p id="red">This is a paragraph</p>
<p id="blue">This is a paragraph</p>

 

clear

Esta propiedad indica qué lados de la(s) caja(s) de un elemento pueden no estar adyacentes a una caja flotante anterior.

[Sintaxis] 

clear: left | right | both | none

Ejemplo

[style.css]

p{
  width: 100px;
  height: 100px;
  float: left;
}
p#red{
  background-color: red;
}
p#blue{
  background-color: blue;
}
p#green{
  background-color: green;
  clear: left;
}

[index.html]  

<p id="red">This is a paragraph</p>
<p id="blue">This is a paragraph</p>
<p id="green">This is a paragraph</p>

 

Ver también  9.5 Floats. 

Reto

[style.css]

nav{
  float: left;
  width: 200px;
  margin-top: 30px;
}
footer{ 
  height: 50px;
  clear: both;
  text-align: center;
  background-color: #999999;
}
#main{
  float: left;
  width: 400px;
  padding-left: 30px;
  margin-top: 30px;
}
aside{
  float: right;
  width: 250px;
  margin-top: 30px;
}
#main2{
  float: left;
  margin-top: 30px;
  margin-bottom: 20px;
  padding-left: 30px;
  width: 600px;
}

 

 Fuente: https://www.w3.org/community/webed/wiki/CSS/Training/floating

Bordes CSS

border-style

Las propiedades de estilo de borde especifican el estilo de línea del borde de un cuadro.

[Sintaxis]

border-style: none | hidden | dotted | dashed | solid | double | groove 

              | ridge | inset | outset

 

Ejemplo

[style.css]

p{
  width: 300px;
  height: 100px;
}
p#dot{ border-style: dotted; }
p#sol{ border-style: solid; }

[index.html]  

<p id="dot">This is a paragraph(dotted)</p>
<p id="sol">This is a paragraph(solid)</p>

 

border-color

Las propiedades de border-color especifican el color del borde de una caja.

[Sintaxis]

border-color: <color> | transparent

- color : Especifica un valor de color:

• color keywords
• color values

Ejemplo

[style.css]

p{
  width: 300px;
  height: 100px;
  border-style: solid;
  border-color: red;
}

[index.html] 

<p>This is a paragraph</p>

 

border-width

Las propiedades de border-width especifican el ancho del área de borde.

[Sintaxis]

border-width: thin | medium | thick | <length>

Ejemplo

[style.css]

p#thin{ border-width: thin; }
p#med{ border-width: medium; }
p#thick{ border-width: thick; }

[index.html] 

<p id="thin">This is a paragraph(thin)</p>
<p id="med">This is a paragraph(medium)</p>
<p id="thick">This is a paragraph(thick)</p>

 

Ver también  8.5 Border properties. 

Reto

1. Estilos de la navegación lateral por el borde.

[style.css]

nav ul li{
  font-size: 1.5em;
  padding-left: 10px;
  margin-bottom: 7px;
  border-left-width: 5px;
  border-left-color: #990066;
  border-left-style: solid;
}

2. Estilos los encabezados de noticias.

[style.css]

#main header{
  padding-left: 10px;
  margin-bottom: 10px;
  border-top-width: 1px;
  border-top-color: #A6A6A6;
  border-top-style: dashed;
  border-bottom-width: 1px;
  border-bottom-color: #A6A6A6;
  border-bottom-style: dashed;
}

 

3. Estilos de la tabla de la página de solicitud de reclutamiento (recruit.html).

[style.css]

#main2 table{
  border-top-width: 1px;
  border-top-color: #A6A6A6;
  border-top-style: solid;
  border-left-width: 1px;
  border-left-color: #A6A6A6;
  border-left-style: solid;
  margin: 0px;
  padding: 0px;
  border-collapse: collapse;
}
#main2 th, #main2 td{
  border-right-width: 1px;
  border-right-color: #A6A6A6;
  border-right-style: solid;
  border-bottom-width: 1px;
  border-bottom-color: #A6A6A6;
  border-bottom-style: solid;
  margin: 0px;
  padding: 5px 10px;
}
#main2 th{
  width: 150px;
}
#main2 td{
  width: 410px;
}

 

 Fuente: /www.w3.org/