ℹ️ Skipped - page is already crawled
| Filter | Status | Condition | Details |
|---|---|---|---|
| HTTP status | PASS | download_http_code = 200 | HTTP 200 |
| Age cutoff | PASS | download_stamp > now() - 6 MONTH | 0 months ago |
| History drop | PASS | isNull(history_drop_reason) | No drop reason |
| Spam/ban | PASS | fh_dont_index != 1 AND ml_spam_score = 0 | ml_spam_score=0 |
| Canonical | PASS | meta_canonical IS NULL OR = '' OR = src_unparsed | Not set |
| Property | Value |
|---|---|
| URL | https://git-scm.com/book/es/v2/Fundamentos-de-Git-Guardando-cambios-en-el-Repositorio |
| Last Crawled | 2026-04-11 21:19:50 (16 hours ago) |
| First Indexed | 2015-03-10 03:20:27 (11 years ago) |
| HTTP Status Code | 200 |
| Meta Title | Git - Guardando cambios en el Repositorio |
| Meta Description | null |
| Meta Canonical | null |
| Boilerpipe Text | 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á 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.
Figura 8. 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 archivos 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 de momento.
[ch03-git-branching]
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.
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 aún 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 archivos en conflicto por combinación como resueltos. Es más útil que lo veas como un comando para “añadir este contenido a la próxima confirmación” más 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 status
.
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
Estado 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 estado 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.
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 compilació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 terminen con una tilde (
~
), la cual es usada 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
#
.
Emplear patrones glob estándar que se aplicarán recursivamente a todo el directorio del repositorio local.
Los patrones pueden comenzar en barra (
/
) para evitar recursividad.
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 especie de expresión regular simplificada usada por los terminales.
Un asterisco (
*
) corresponde a cero o más caracteres;
[abc]
corresponde a cualquier caracter dentro de los corchetes (en este caso a, b o c); el signo de interrogación (
?
) corresponde a un caracter cualquiera; y los corchetes sobre caracteres separados por un guión (
[0-9]
) corresponde a cualquier caracter 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 línea 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 no este: doc/server/arch.txt
doc/*.txt
# ignora todos los archivos .txt del directorio doc/
doc/**/*.txt
Sugerencia
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.
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 ya 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).
+# test line
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
Nota
Git Diff como Herramienta Externa
A lo largo del libro, continuaremos usando el comando
git diff
de distintas maneras. Existe otra forma de ver estas diferencias si prefieres utilizar una interfaz gráfica u otro programa externo. Si ejecutas
git difftool
en vez de
git diff
, podrás ver los cambios con programas de este tipo como Araxis, emerge, vimdiff y más. Ejecuta
git difftool --tool-help
para ver qué tienes disponible en tu sistema.
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 listo 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
[ch01-introduction]
).
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 de 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.
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 estado, 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. |
| Markdown | [](https://git-scm.com/) \--local-branching-on-the-cheap
- [About](https://git-scm.com/about)
- [Trademark](https://git-scm.com/about/trademark)
- [Learn](https://git-scm.com/learn)
- [Book](https://git-scm.com/book)
- [Cheat Sheet](https://git-scm.com/cheat-sheet)
- [Videos](https://git-scm.com/videos)
- [External Links](https://git-scm.com/doc/ext)
- [Tools](https://git-scm.com/tools)
- [Command Line](https://git-scm.com/tools/command-line)
- [GUIs](https://git-scm.com/tools/guis)
- [Hosting](https://git-scm.com/tools/hosting)
- [Reference](https://git-scm.com/docs)
- [Install](https://git-scm.com/install/linux)
- [Community](https://git-scm.com/community)
***
This book is available in [English](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository).
Full translation available in
| |
|---|
| [azərbaycan dili](https://git-scm.com/book/az/v2/Git%E2%80%99in-%C6%8Fsaslar%C4%B1-Depoda-D%C9%99yi%C5%9Fiklikl%C9%99rin-Qeyd-Edilm%C9%99si), |
| [български език](https://git-scm.com/book/bg/v2/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%B8-%D0%BD%D0%B0-Git-%D0%97%D0%B0%D0%BF%D0%B8%D1%81-%D0%BD%D0%B0-%D0%BF%D1%80%D0%BE%D0%BC%D0%B5%D0%BD%D0%B8-%D0%B2-%D1%85%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B5%D1%82%D0%BE), |
| [Deutsch](https://git-scm.com/book/de/v2/Git-Grundlagen-%C3%84nderungen-nachverfolgen-und-im-Repository-speichern), |
| [Español](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Guardando-cambios-en-el-Repositorio), |
| [فارسی](https://git-scm.com/book/fa/v2/%D9%85%D9%82%D8%AF%D9%85%D8%A7%D8%AA-%DA%AF%DB%8C%D8%AA-git-basics-chapter-%D8%AB%D8%A8%D8%AA-%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1%D8%A7%D8%AA-%D8%AF%D8%B1-%D9%85%D8%AE%D8%B2%D9%86-Recording-Changes-to-the-Repository), |
| [Français](https://git-scm.com/book/fr/v2/Les-bases-de-Git-Enregistrer-des-modifications-dans-le-d%C3%A9p%C3%B4t), |
| [Ελληνικά](https://git-scm.com/book/gr/v2/%CE%A4%CE%B1-%CE%B8%CE%B5%CE%BC%CE%B5%CE%BB%CE%B9%CF%8E%CE%B4%CE%B7-%CF%83%CF%84%CE%BF%CE%B9%CF%87%CE%B5%CE%AF%CE%B1-%CF%84%CE%BF%CF%85-Git-%CE%9A%CE%B1%CF%84%CE%B1%CE%B3%CF%81%CE%B1%CF%86%CE%AE-%CE%B1%CE%BB%CE%BB%CE%B1%CE%B3%CF%8E%CE%BD-%CF%83%CF%84%CE%BF-%CE%B1%CF%80%CE%BF%CE%B8%CE%B5%CF%84%CE%AE%CF%81%CE%B9%CE%BF), |
| [日本語](https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E5%9F%BA%E6%9C%AC-%E5%A4%89%E6%9B%B4%E5%86%85%E5%AE%B9%E3%81%AE%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E3%81%B8%E3%81%AE%E8%A8%98%E9%8C%B2), |
| [한국어](https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EC%88%98%EC%A0%95%ED%95%98%EA%B3%A0-%EC%A0%80%EC%9E%A5%EC%86%8C%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0), |
| [Nederlands](https://git-scm.com/book/nl/v2/Git-Basics-Wijzigingen-aan-de-repository-vastleggen), |
| [Русский](https://git-scm.com/book/ru/v2/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git-%D0%97%D0%B0%D0%BF%D0%B8%D1%81%D1%8C-%D0%B8%D0%B7%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D0%B9-%D0%B2-%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D0%B9), |
| [Slovenščina](https://git-scm.com/book/sl/v2/Osnove-Git-Snemanje-sprememb-v-repozitorij), |
| [Српски](https://git-scm.com/book/sr/v2/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%B5-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%B0-%D0%93%D0%B8%D1%82-%D0%A1%D0%BD%D0%B8%D0%BC%D0%B0%D1%9A%D0%B5-%D0%BF%D1%80%D0%BE%D0%BC%D0%B5%D0%BD%D0%B0-%D0%BD%D0%B0%D0%B4-%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%98%D1%83%D0%BC%D0%BE%D0%BC), |
| [Svenska](https://git-scm.com/book/sv/v2/Grunderna-i-Git-Spara-%C3%A4ndringar-i-kodf%C3%B6rr%C3%A5det), |
| [Tagalog](https://git-scm.com/book/tl/v2/Mga-Pangunahing-Kaalaman-sa-Git-Pagtatala-ng-mga-Pagbabago-sa-Repositoryo), |
| [Türkçe](https://git-scm.com/book/tr/v2/Git-Temelleri-De%C4%9Fi%C5%9Fikliklerin-Repoya-Kaydedilmesi). |
| [Українська](https://git-scm.com/book/uk/v2/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%B8-Git-%D0%97%D0%B0%D0%BF%D0%B8%D1%81-%D0%B7%D0%BC%D1%96%D0%BD-%D0%B4%D0%BE-%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D1%96%D1%8F), |
| [简体中文](https://git-scm.com/book/zh/v2/Git-%E5%9F%BA%E7%A1%80-%E8%AE%B0%E5%BD%95%E6%AF%8F%E6%AC%A1%E6%9B%B4%E6%96%B0%E5%88%B0%E4%BB%93%E5%BA%93), |
Partial translations available in
| |
|---|
| [Čeština](https://git-scm.com/book/cs/v2/Z%C3%A1klady-pr%C3%A1ce-se-syst%C3%A9mem-Git-Nahr%C3%A1v%C3%A1n%C3%AD-zm%C4%9Bn-do-repozit%C3%A1%C5%99e), |
| [Македонски](https://git-scm.com/book/mk/v2/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%B8%D1%82%D0%B5-%D0%BD%D0%B0-Git-%D0%A1%D0%BD%D0%B8%D0%BC%D0%B0%D1%9A%D0%B5-%D0%BD%D0%B0-%D0%BF%D1%80%D0%BE%D0%BC%D0%B5%D0%BD%D0%B8-%D0%B2%D0%BE-%D1%81%D0%BA%D0%BB%D0%B0%D0%B4%D0%B8%D1%88%D1%82%D0%B5%D1%82%D0%BE), |
| [Polski](https://git-scm.com/book/pl/v2/Podstawy-Gita-Rejestrowanie-zmian-w-repozytorium), |
| [Português (Brasil)](https://git-scm.com/book/pt-br/v2/Fundamentos-de-Git-Gravando-Altera%C3%A7%C3%B5es-em-Seu-Reposit%C3%B3rio), |
| [Ўзбекча](https://git-scm.com/book/uz/v2/Git-%D0%B0%D1%81%D0%BE%D1%81%D0%BB%D0%B0%D1%80%D0%B8-%D0%8E%D0%B7%D0%B3%D0%B0%D1%80%D0%B8%D1%88%D0%BB%D0%B0%D1%80%D0%BD%D0%B8-%D0%BE%D0%BC%D0%B1%D0%BE%D1%80%D0%B3%D0%B0-%D1%91%D0%B7%D0%B8%D1%88), |
| [繁體中文](https://git-scm.com/book/zh-tw/v2/Git-%E5%9F%BA%E7%A4%8E-%E7%B4%80%E9%8C%84%E8%AE%8A%E6%9B%B4%E5%88%B0%E7%89%88%E6%9C%AC%E5%BA%AB%E4%B8%AD), |
Translations started for
| |
|---|
| [Беларуская](https://git-scm.com/book/be/v2/Git-Basics-Recording-Changes-to-the-Repository), |
| [Indonesian](https://git-scm.com/book/id/v2/Git-Basics-Recording-Changes-to-the-Repository), |
| [Italiano](https://git-scm.com/book/it/v2/Git-Basics-Recording-Changes-to-the-Repository), |
| [Bahasa Melayu](https://git-scm.com/book/ms/v2/Git-Basics-Recording-Changes-to-the-Repository), |
| [Português (Portugal)](https://git-scm.com/book/pt-pt/v2/No%C3%A7%C3%B5es-B%C3%A1sicas-do-Git-Recording-Changes-to-the-Repository). |
***
The source of this book is [hosted on GitHub.](https://github.com/progit/progit2-es)
Patches, suggestions and comments are welcome.
[Chapters ▾](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Guardando-cambios-en-el-Repositorio)
1. ## 1\. [Inicio - Sobre el Control de Versiones](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Acerca-del-Control-de-Versiones)
1. 1\.1 [Acerca del Control de Versiones](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Acerca-del-Control-de-Versiones)
2. 1\.2 [Una breve historia de Git](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Una-breve-historia-de-Git)
3. 1\.3 [Fundamentos de Git](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Fundamentos-de-Git)
4. 1\.4 [La Línea de Comandos](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-La-L%C3%ADnea-de-Comandos)
5. 1\.5 [Instalación de Git](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Instalaci%C3%B3n-de-Git)
6. 1\.6 [Configurando Git por primera vez](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Configurando-Git-por-primera-vez)
7. 1\.7 [¿Cómo obtener ayuda?](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-%C2%BFC%C3%B3mo-obtener-ayuda%3F)
8. 1\.8 [Resumen](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Resumen)
2. ## 2\. [Fundamentos de Git](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Obteniendo-un-repositorio-Git)
1. 2\.1 [Obteniendo un repositorio Git](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Obteniendo-un-repositorio-Git)
2. 2\.2 [Guardando cambios en el Repositorio](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Guardando-cambios-en-el-Repositorio)
3. 2\.3 [Ver el Historial de Confirmaciones](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Ver-el-Historial-de-Confirmaciones)
4. 2\.4 [Deshacer Cosas](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Deshacer-Cosas)
5. 2\.5 [Trabajar con Remotos](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Trabajar-con-Remotos)
6. 2\.6 [Etiquetado](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Etiquetado)
7. 2\.7 [Alias de Git](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Alias-de-Git)
8. 2\.8 [Resumen](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Resumen)
3. ## 3\. [Ramificaciones en Git](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama%3F)
1. 3\.1 [¿Qué es una rama?](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama%3F)
2. 3\.2 [Procedimientos Básicos para Ramificar y Fusionar](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Procedimientos-B%C3%A1sicos-para-Ramificar-y-Fusionar)
3. 3\.3 [Gestión de Ramas](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Gesti%C3%B3n-de-Ramas)
4. 3\.4 [Flujos de Trabajo Ramificados](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Flujos-de-Trabajo-Ramificados)
5. 3\.5 [Ramas Remotas](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Ramas-Remotas)
6. 3\.6 [Reorganizar el Trabajo Realizado](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Reorganizar-el-Trabajo-Realizado)
7. 3\.7 [Recapitulación](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Recapitulaci%C3%B3n)
4. ## 4\. [Git en el Servidor](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Los-Protocolos)
1. 4\.1 [Los Protocolos](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Los-Protocolos)
2. 4\.2 [Configurando Git en un servidor](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Configurando-Git-en-un-servidor)
3. 4\.3 [Generando tu clave pública SSH](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Generando-tu-clave-p%C3%BAblica-SSH)
4. 4\.4 [Configurando el servidor](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Configurando-el-servidor)
5. 4\.5 [El demonio Git](https://git-scm.com/book/es/v2/Git-en-el-Servidor-El-demonio-Git)
6. 4\.6 [HTTP Inteligente](https://git-scm.com/book/es/v2/Git-en-el-Servidor-HTTP-Inteligente)
7. 4\.7 [GitWeb](https://git-scm.com/book/es/v2/Git-en-el-Servidor-GitWeb)
8. 4\.8 [GitLab](https://git-scm.com/book/es/v2/Git-en-el-Servidor-GitLab)
9. 4\.9 [Git en un alojamiento externo](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Git-en-un-alojamiento-externo)
10. 4\.10 [Resumen](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Resumen)
5. ## 5\. [Git en entornos distribuidos](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Flujos-de-trabajo-distribuidos)
1. 5\.1 [Flujos de trabajo distribuidos](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Flujos-de-trabajo-distribuidos)
2. 5\.2 [Contribuyendo a un Proyecto](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Contribuyendo-a-un-Proyecto)
3. 5\.3 [Manteniendo un proyecto](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Manteniendo-un-proyecto)
4. 5\.4 [Resumen](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Resumen)
1. ## 6\. [GitHub](https://git-scm.com/book/es/v2/GitHub-Creaci%C3%B3n-y-configuraci%C3%B3n-de-la-cuenta)
1. 6\.1 [Creación y configuración de la cuenta](https://git-scm.com/book/es/v2/GitHub-Creaci%C3%B3n-y-configuraci%C3%B3n-de-la-cuenta)
2. 6\.2 [Participando en Proyectos](https://git-scm.com/book/es/v2/GitHub-Participando-en-Proyectos)
3. 6\.3 [Mantenimiento de un proyecto](https://git-scm.com/book/es/v2/GitHub-Mantenimiento-de-un-proyecto)
4. 6\.4 [Gestión de una organización](https://git-scm.com/book/es/v2/GitHub-Gesti%C3%B3n-de-una-organizaci%C3%B3n)
5. 6\.5 [Scripting en GitHub](https://git-scm.com/book/es/v2/GitHub-Scripting-en-GitHub)
6. 6\.6 [Resumen](https://git-scm.com/book/es/v2/GitHub-Resumen)
2. ## 7\. [Herramientas de Git](https://git-scm.com/book/es/v2/Herramientas-de-Git-Revisi%C3%B3n-por-selecci%C3%B3n)
1. 7\.1 [Revisión por selección](https://git-scm.com/book/es/v2/Herramientas-de-Git-Revisi%C3%B3n-por-selecci%C3%B3n)
2. 7\.2 [Organización interactiva](https://git-scm.com/book/es/v2/Herramientas-de-Git-Organizaci%C3%B3n-interactiva)
3. 7\.3 [Guardado rápido y Limpieza](https://git-scm.com/book/es/v2/Herramientas-de-Git-Guardado-r%C3%A1pido-y-Limpieza)
4. 7\.4 [Firmando tu trabajo](https://git-scm.com/book/es/v2/Herramientas-de-Git-Firmando-tu-trabajo)
5. 7\.5 [Buscando](https://git-scm.com/book/es/v2/Herramientas-de-Git-Buscando)
6. 7\.6 [Reescribiendo la Historia](https://git-scm.com/book/es/v2/Herramientas-de-Git-Reescribiendo-la-Historia)
7. 7\.7 [Reiniciar Desmitificado](https://git-scm.com/book/es/v2/Herramientas-de-Git-Reiniciar-Desmitificado)
8. 7\.8 [Fusión Avanzada](https://git-scm.com/book/es/v2/Herramientas-de-Git-Fusi%C3%B3n-Avanzada)
9. 7\.9 [Rerere](https://git-scm.com/book/es/v2/Herramientas-de-Git-Rerere)
10. 7\.10 [Haciendo debug con Git](https://git-scm.com/book/es/v2/Herramientas-de-Git-Haciendo-debug-con-Git)
11. 7\.11 [Submódulos](https://git-scm.com/book/es/v2/Herramientas-de-Git-Subm%C3%B3dulos)
12. 7\.12 [Agrupaciones](https://git-scm.com/book/es/v2/Herramientas-de-Git-Agrupaciones)
13. 7\.13 [Replace](https://git-scm.com/book/es/v2/Herramientas-de-Git-Replace)
14. 7\.14 [Almacenamiento de credenciales](https://git-scm.com/book/es/v2/Herramientas-de-Git-Almacenamiento-de-credenciales)
15. 7\.15 [Resumen](https://git-scm.com/book/es/v2/Herramientas-de-Git-Resumen)
3. ## 8\. [Personalización de Git](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Configuraci%C3%B3n-de-Git)
1. 8\.1 [Configuración de Git](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Configuraci%C3%B3n-de-Git)
2. 8\.2 [Git Attributes](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Git-Attributes)
3. 8\.3 [Puntos de enganche en Git](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Puntos-de-enganche-en-Git)
4. 8\.4 [Un ejemplo de implantación de una determinada política en Git](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Un-ejemplo-de-implantaci%C3%B3n-de-una-determinada-pol%C3%ADtica-en-Git)
5. 8\.5 [Recapitulación](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Recapitulaci%C3%B3n)
4. ## 9\. [Git y Otros Sistemas](https://git-scm.com/book/es/v2/Git-y-Otros-Sistemas-Git-como-Cliente)
1. 9\.1 [Git como Cliente](https://git-scm.com/book/es/v2/Git-y-Otros-Sistemas-Git-como-Cliente)
2. 9\.2 [Migración a Git](https://git-scm.com/book/es/v2/Git-y-Otros-Sistemas-Migraci%C3%B3n-a-Git)
3. 9\.3 [Resumen](https://git-scm.com/book/es/v2/Git-y-Otros-Sistemas-Resumen)
5. ## 10\. [Los entresijos internos de Git](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Fontaner%C3%ADa-y-porcelana)
1. 10\.1 [Fontanería y porcelana](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Fontaner%C3%ADa-y-porcelana)
2. 10\.2 [Los objetos Git](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Los-objetos-Git)
3. 10\.3 [Referencias Git](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Referencias-Git)
4. 10\.4 [Archivos empaquetadores](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Archivos-empaquetadores)
5. 10\.5 [Las especificaciones para hacer referencia a… (refspec)](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Las-especificaciones-para-hacer-referencia-a%E2%80%A6%E2%80%8B-refspec)
6. 10\.6 [Protocolos de transferencia](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Protocolos-de-transferencia)
7. 10\.7 [Mantenimiento y recuperación de datos](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Mantenimiento-y-recuperaci%C3%B3n-de-datos)
8. 10\.8 [Variables de entorno](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Variables-de-entorno)
9. 10\.9 [Recapitulación](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Recapitulaci%C3%B3n)
1. ## A1. [Apéndice A: Git en otros entornos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Interfaces-gr%C3%A1ficas)
1. A1.1 [Interfaces gráficas](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Interfaces-gr%C3%A1ficas)
2. A1.2 [Git en Visual Studio](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Visual-Studio)
3. A1.3 [Git en Eclipse](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Eclipse)
4. A1.4 [Git con Bash](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-con-Bash)
5. A1.5 [Git en Zsh](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Zsh)
6. A1.6 [Git en Powershell](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Powershell)
7. A1.7 [Resumen](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Resumen)
2. ## A2. [Apéndice B: Integrando Git en tus Aplicaciones](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-Git-mediante-L%C3%ADnea-de-Comandos)
1. A2.1 [Git mediante Línea de Comandos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-Git-mediante-L%C3%ADnea-de-Comandos)
2. A2.2 [Libgit2](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-Libgit2)
3. A2.3 [JGit](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-JGit)
3. ## A3. [Apéndice C: Comandos de Git](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Configuraci%C3%B3n)
1. A3.1 [Configuración](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Configuraci%C3%B3n)
2. A3.2 [Obtener y Crear Proyectos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Obtener-y-Crear-Proyectos)
3. A3.3 [Seguimiento Básico](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Seguimiento-B%C3%A1sico)
4. A3.4 [Ramificar y Fusionar](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Ramificar-y-Fusionar)
5. A3.5 [Compartir y Actualizar Proyectos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Compartir-y-Actualizar-Proyectos)
6. A3.6 [Inspección y Comparación](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Inspecci%C3%B3n-y-Comparaci%C3%B3n)
7. A3.7 [Depuración](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Depuraci%C3%B3n)
8. A3.8 [Parcheo](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Parcheo)
9. A3.9 [Correo Electrónico](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Correo-Electr%C3%B3nico)
10. A3.10 [Sistemas Externos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Sistemas-Externos)
11. A3.11 [Administración](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Administraci%C3%B3n)
12. A3.12 [Comandos de Fontanería](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Comandos-de-Fontaner%C3%ADa)
2nd Edition
# 2\.2 Fundamentos de Git - Guardando cambios en el Repositorio
## 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á 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.
Figura 8. 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 archivos 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 de momento. [\[ch03-git-branching\]](https://git-scm.com/book/es/v2/ch00/ch03-git-branching) 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.
### 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 aún 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 archivos en conflicto por combinación como resueltos. Es más útil que lo veas como un comando para “añadir este contenido a la próxima confirmación” más 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 status`. 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
```
### Estado 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 estado 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.
### 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 compilació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 terminen con una tilde (`~`), la cual es usada 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 `#`.
- Emplear patrones glob estándar que se aplicarán recursivamente a todo el directorio del repositorio local.
- Los patrones pueden comenzar en barra (`/`) para evitar recursividad.
- 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 especie de expresión regular simplificada usada por los terminales. Un asterisco (`*`) corresponde a cero o más caracteres; `[abc]` corresponde a cualquier caracter dentro de los corchetes (en este caso a, b o c); el signo de interrogación (`?`) corresponde a un caracter cualquiera; y los corchetes sobre caracteres separados por un guión (`[0-9]`) corresponde a cualquier caracter 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 línea 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 no este: doc/server/arch.txt
doc/*.txt
# ignora todos los archivos .txt del directorio doc/
doc/**/*.txt
```
| | |
|---|---|
| Sugerencia | 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. |
### 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 ya 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).
+# test line
```
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
```
| | |
|---|---|
| Nota | Git Diff como Herramienta Externa A lo largo del libro, continuaremos usando el comando `git diff` de distintas maneras. Existe otra forma de ver estas diferencias si prefieres utilizar una interfaz gráfica u otro programa externo. Si ejecutas `git difftool` en vez de `git diff`, podrás ver los cambios con programas de este tipo como Araxis, emerge, vimdiff y más. Ejecuta `git difftool --tool-help` para ver qué tienes disponible en tu sistema. |
### 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 listo 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 [\[ch01-introduction\]](https://git-scm.com/book/es/v2/ch00/ch01-introduction)).
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 de 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.
### 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 estado, 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.
[prev](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Obteniendo-un-repositorio-Git) \| [next](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Ver-el-Historial-de-Confirmaciones)
[About this site](https://git-scm.com/site)
Patches, suggestions, and comments are welcome.
Git is a member of [Software Freedom Conservancy](https://git-scm.com/sfc) |
| Readable Markdown | 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á 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.
Figura 8. 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 archivos 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 de momento. [\[ch03-git-branching\]](https://git-scm.com/book/es/v2/ch00/ch03-git-branching) 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.
### 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 aún 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 archivos en conflicto por combinación como resueltos. Es más útil que lo veas como un comando para “añadir este contenido a la próxima confirmación” más 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 status`. 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
```
### Estado 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 estado 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.
### 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 compilació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 terminen con una tilde (`~`), la cual es usada 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 `#`.
- Emplear patrones glob estándar que se aplicarán recursivamente a todo el directorio del repositorio local.
- Los patrones pueden comenzar en barra (`/`) para evitar recursividad.
- 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 especie de expresión regular simplificada usada por los terminales. Un asterisco (`*`) corresponde a cero o más caracteres; `[abc]` corresponde a cualquier caracter dentro de los corchetes (en este caso a, b o c); el signo de interrogación (`?`) corresponde a un caracter cualquiera; y los corchetes sobre caracteres separados por un guión (`[0-9]`) corresponde a cualquier caracter 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 línea 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 no este: doc/server/arch.txt
doc/*.txt
# ignora todos los archivos .txt del directorio doc/
doc/**/*.txt
```
| | |
|---|---|
| Sugerencia | 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. |
### 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 ya 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).
+# test line
```
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
```
| | |
|---|---|
| Nota | Git Diff como Herramienta Externa A lo largo del libro, continuaremos usando el comando `git diff` de distintas maneras. Existe otra forma de ver estas diferencias si prefieres utilizar una interfaz gráfica u otro programa externo. Si ejecutas `git difftool` en vez de `git diff`, podrás ver los cambios con programas de este tipo como Araxis, emerge, vimdiff y más. Ejecuta `git difftool --tool-help` para ver qué tienes disponible en tu sistema. |
### 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 listo 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 [\[ch01-introduction\]](https://git-scm.com/book/es/v2/ch00/ch01-introduction)).
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 de 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.
### 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 estado, 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. |
| Shard | 54 (laksa) |
| Root Hash | 7104038400628677254 |
| Unparsed URL | com,git-scm!/book/es/v2/Fundamentos-de-Git-Guardando-cambios-en-el-Repositorio s443 |