Merge 819b14a73f into b752196266

Add method to change authors for multiple commits
Fix link in README_ja.md (#361 )
2025-06-16 12:54:01 -03:00 · 2024-05-14 14:21:38 +08:00 · 2024-05-14 13:58:41 +08:00 · 2024-03-18 10:17:15 -04:00 · 2024-02-23 10:08:06 +11:00 · 2023-09-27 10:35:07 -04:00
9 changed files with 6006 additions and 1233 deletions
--- a/README.md
+++ b/README.md
--- a/README_es.md
+++ b/README_es.md
@ -1,7 +1,7 @@
 # Reglas de vuelo para git

 🌍
-*[English](README.md) ∙ [Español](README_es.md)  ∙  [Русский](README_ru.md) ∙ [简体中文](README_zh-CN.md)∙ [한국어](README_kr.md)  ∙  [Tiếng Việt](README_vi.md) ∙ [Français](README_fr.md)*
+*[English](README.md) ∙ [Español](README_es.md)  ∙  [Русский](README_ru.md) ∙ [繁體中文](README_zh-TW.md) ∙ [简体中文](README_zh-CN.md) ∙ [한국어](README_kr.md)  ∙  [Tiếng Việt](README_vi.md) ∙ [Français](README_fr.md) ∙ [日本語](README_ja.md)*

 #### ¿Qué son "reglas de vuelo"?

@ -55,7 +55,7 @@ En aras de la claridad, todos los ejemplos de este documento usan un indicador d
    - [Crear una rama desde una confirmación](#crear-una-rama-desde-una-confirmaci%C3%B3n)
    - [Hice pull de / en la rama incorrecta](#hice-pull-de--en-la-rama-incorrecta)
    - [Quiero descartar confirmaciones locales para que mi rama sea la misma que la del servidor](#quiero-descartar-confirmaciones-locales-para-que-mi-rama-sea-la-misma-que-la-del-servidor)
-    - [Hice commit a master en lugar de una nueva rama](#hice-commit-a-master-en-lugar-de-una-nueva-rama)
+    - [Hice commit a main en lugar de una nueva rama](#hice-commit-a-main-en-lugar-de-una-nueva-rama)
    - [Quiero mantener todo el archivo de otro ref-ish](#quiero-mantener-todo-el-archivo-de-otro-ref-ish)
    - [Realicé varios commits en una sola rama que debería estar en diferentes ramas](#realic%C3%A9-varios-commits-en-una-sola-rama-que-deber%C3%ADa-estar-en-diferentes-ramas)
    - [Quiero eliminar las ramas locales que se eliminaron en sentido ascendente](#quiero-eliminar-las-ramas-locales-que-se-eliminaron-en-sentido-ascendente)
@ -142,7 +142,7 @@ $ git clone [url]
 Digamos que simplemente hiciste cambios a ciegas con `git commit -a` y no estás seguro de cuál fue el contenido real de la confirmación que acabas de realizar. Puedes mostrar el último commit en su HEAD actual con:

 ```sh
-(master)$ git show
+(main)$ git show
 ```

 o
@ -201,8 +201,7 @@ $ git push --force-with-lease [remote] [branch]
 Si no has subido tus cambios, para resetear Git al estado en el que estaba antes de realizar tu último commit (mientras mantengas tus cambios en staging):

 ```
-(my-branch*)$ git reset --soft HEAD@{1}
-
+(my-branch)$ git reset --soft HEAD^
 ```

 Esto solo funciona si no subiste tu commit. Si lo hiciste, la única cosa segura por hacer es `git revert SHAofBadCommit`. Eso creará un nuevo commit que deshace todos los cambios del anterior commit. O,  si la rama que subiste es segura ante reorganizaciones (ej. otros desarrolladores no esperan recibir cambios desde ahí), puedes usar `git push --force-with-lease`. Para más, mira [la sección de arriba](#quiero-borrar-o-remover-mi-ultimo-commit).
@ -245,13 +244,13 @@ Si estás *absolutamente* seguro que nadie está trabajando en la misma rama o q
 Si accidentalmente hiciste `git reset --hard`, puedes volver a obtener tus commits de vuelta ya que git mantiene un registro de todo durante unos días.

 ```sh
-(master)$ git reflog
+(main)$ git reflog
 ```

 Verás una lista de tus antiguos commits, y un commit para el reset. Escoge el SHA del commit al que quieres retornar y has el reset de nuevo:

 ```sh
-(master)$ git reset --hard SHA1234
+(main)$ git reset --hard SHA1234
 ```

 Y deberías estar ubicado en ese commit.
@ -361,7 +360,7 @@ Si deseas descartar todos los cambios organizados y no supervisados locale
 ```sh
 (mi-rama) $ git reset --hard
 # o
-(master) $ git checkout -f
+(main) $ git checkout -f
 ```

 Esto borrará todos los archivos que hayas organizado con `git add`:
@ -485,7 +484,7 @@ $ git checkout -b <branch> <SHA1_OF_COMMIT>
 Esta es otra oportunidad de usar `git reflog` para ver dónde apuntó el HEAD antes del mal tirón.

 ```sh
-(master) $ git reflog
+(main) $ git reflog
 ab7555f HEAD @ {0}: pull-wrong-branch: Fast-forward
 c5bc55a HEAD @ {1}: checkout: checkout message goes here
 ```
@ -515,21 +514,21 @@ Confirma que no ha enviado sus cambios al servidor.
 Una forma de reiniciar para hacer coincidir el origin (tener lo mismo que lo que está en el control remoto) es hacer esto:

 ```sh
-(master) $ git reset --hard origin / my-branch
+(my-branch) $ git reset --hard origin/my-branch
 ```

-### Hice commit a master en lugar de una nueva rama
+### Hice commit a main en lugar de una nueva rama

-Crea la nueva rama mientras permaneces en master:
+Crea la nueva rama mientras permaneces en main:

 ```sh
-(master) $ git branch my-branch
+(main) $ git branch my-branch
 ```

-Restablece la rama master al commit anterior:
+Restablece la rama main al commit anterior:

 ```sh
-(master) $ git reset --hard HEAD ^
+(main) $ git reset --hard HEAD ^
 ```

 `HEAD ^` es la abreviatura de `HEAD ^ 1`. Esto representa el primer padre de `HEAD`, del mismo modo` HEAD ^ 2` representa el segundo padre del commit (las fusiones pueden tener 2 padres).
@ -541,14 +540,14 @@ Alternativamente, si no quieres usar `HEAD ^`, averigüe a qué hash de confirma
 Por ejemplo, si el hash del commit en el que se supone que está su rama principal es `a13b85e`:

 ```sh
-(master) $ git reset --hard a13b85e
+(main) $ git reset --hard a13b85e
 HEAD is now at a13b85e
 ```

 Verifique la nueva rama para continuar trabajando:

 ```sh
-(master) $ git checkout my-branch
+(main) $ git checkout my-branch
 ```

 ### Quiero mantener todo el archivo de otro ref-ish
@ -592,7 +591,7 @@ Nota: Las soluciones de Spike están hechas para analizar o resolver el problema
 Digamos que estás en tu rama principal. Al ejecutar `git log`, verás que ha realizado dos commits:

 ```sh
-(master) $ git log
+(main) $ git log

 commit e3851e817c451cc36f2e6f3049db528415e3c114
 Author: Alex Lee <alexlee@example.com>
@ -618,14 +617,14 @@ Toma nota de nuestros hashes de confirmación para cada error (`e3851e8` para #
 Primero, restablece la rama principal al commit correcto (`a13b85e`):

 ```sh
-(master)$ git reset --hard a13b85e
+(main)$ git reset --hard a13b85e
 HEAD is now at a13b85e
 ```

 Ahora, puedes crear una nueva rama para la rama bug # 21:

 ```sh
-(master) $ git checkout -b 21
+(main) $ git checkout -b 21
 (21) $
 ```

@ -637,11 +636,11 @@ Ahora, * selecciona con precisión * el commit para el error # 21 en la parte su

 En este punto, existe la posibilidad de que haya conflictos. Consulta la sección ** Hubo conflictos ** (# conflicto de fusión) en la [sección interactiva de rebase más arriba] (# interactive-rebase) para saber cómo resolver conflictos.

-Ahora creamos una nueva rama para el error # 14, también basado en el master
+Ahora creamos una nueva rama para el error # 14, también basado en el main

 ```sh
-(21) $ git checkout master
-(master) $ git checkout -b 14
+(21) $ git checkout main
+(main) $ git checkout -b 14
 (14) $
 ```

@ -665,7 +664,7 @@ donde, 'ascendente' es el control remoto desde el que desea recuperar.
 Si empujas regularmente hacia el control remoto, deberías estar seguro la mayor parte del tiempo. Pero aún así a veces puede terminar borrando sus ramaes. Digamos que creamos una rama y creamos un nuevo archivo:

 ```sh
-(master)$ git checkout -b my-branch
+(main)$ git checkout -b my-branch
 (my-branch)$ git branch
 (my-branch)$ touch foo.txt
 (my-branch)$ ls
@ -695,31 +694,31 @@ Date:   Tue Jul 29 13:14:46 2014 -0400
    Fixes #6: Force pushing after amending commits
 ```

-Ahora estamos volviendo a "master" y "accidentalmente" eliminando nuestra rama.
+Ahora estamos volviendo a "main" y "accidentalmente" eliminando nuestra rama.

 ```sh
-(my-branch)$ git checkout master
-Switched to branch 'master'
-Your branch is up-to-date with 'origin/master'.
-(master)$ git branch -D my-branch
+(my-branch)$ git checkout main
+Switched to branch 'main'
+Your branch is up-to-date with 'origin/main'.
+(main)$ git branch -D my-branch
 Deleted branch my-branch (was 4e3cd85).
-(master)$ echo oh noes, deleted my branch!
+(main)$ echo oh noes, deleted my branch!
 oh noes, deleted my branch!
 ```

 En este punto, debe familiarizarse con 'reflog', un registrador actualizado. Almacena el historial de todas las acciones en el repositorio.

 ```
-(master)$ git reflog
-69204cd HEAD@{0}: checkout: moving from my-branch to master
+(main)$ git reflog
+69204cd HEAD@{0}: checkout: moving from my-branch to main
 4e3cd85 HEAD@{1}: commit: foo.txt added
-69204cd HEAD@{2}: checkout: moving from master to my-branch
+69204cd HEAD@{2}: checkout: moving from main to my-branch
 ```

 Como puede ver, hemos confirmado el hash de nuestra rama eliminada. Veamos si podemos restaurar nuestra rama eliminada.

 ```sh
-(master)$ git checkout -b my-branch-help
+(main)$ git checkout -b my-branch-help
 Switched to a new branch 'my-branch-help'
 (my-branch-help)$ git reset --hard 4e3cd85
 HEAD is now at 4e3cd85 foo.txt added
@ -734,25 +733,25 @@ Voila! Recuperamos nuestro archivo eliminado. `git reflog` también es útil cua
 Para eliminar una rama remota:

 ```sh
-(master) $ git push origin --delete my-branch
+(main) $ git push origin --delete my-branch
 ```

 También puedes hacer:

 ```sh
-(master) $ git push origin: my-branch
+(main) $ git push origin: my-branch
 ```

 Para eliminar una rama local:

 ```sh
-(master) $ git branch -d my-branch
+(main) $ git branch -d my-branch
 ```

 Para eliminar una rama local que * no * se ha fusionado con la rama actual o una cadena ascendente:

 ```sh
-(master) $ git branch -D my-branch
+(main) $ git branch -D my-branch
 ```

 ### Quiero eliminar varias ramas
@ -760,7 +759,7 @@ Para eliminar una rama local que * no * se ha fusionado con la rama actual o una
 Supongamos que quiere eliminar todas las ramas que comienzan con `fix /`:

 ```sh
-(master) $ git rama | grep 'fix /' | xargs git branch -d
+(main) $ git rama | grep 'fix /' | xargs git branch -d
 ```

 ### Quiero cambiar el nombre de una rama
@ -768,13 +767,13 @@ Supongamos que quiere eliminar todas las ramas que comienzan con `fix /`:
 Para cambiar el nombre de la rama actual (local):

 ```sh
-(master) $ git branch -m new-name
+(main) $ git branch -m new-name
 ```

 Para cambiar el nombre de una rama diferente (local):

 ```sh
-(master) $ git branch -m old-name new-name
+(main) $ git branch -m old-name new-name
 ```

 ### Quiero hacer checkout en una rama remota en la que alguien más está trabajando
@ -782,13 +781,13 @@ Para cambiar el nombre de una rama diferente (local):
 Primero, busca todas las ramas desde el control remoto:

 ```sh
-(master)$ git fetch --all
+(main)$ git fetch --all
 ```

 Digamos que quieres hacer checkout a `daves` desde el repositorio remoto.

 ```sh
-(master)$ git checkout --track origin/daves
+(main)$ git checkout --track origin/daves
 Branch daves set up to track remote branch daves from origin.
 Switched to a new branch 'daves'
 ```
@ -840,14 +839,14 @@ Al verificar tus ramas remotas, puedes ver en qué rama remota está rastreando
 ```sh
 $ git branch -r
  origin/HEAD -> origin/gh-pages
-  origin/master
+  origin/main
 ```

-Cambiar `origin / HEAD` para rastrear` origin / master`, puedes ejecutar este comando:
+Cambiar `origin / HEAD` para rastrear` origin / main`, puedes ejecutar este comando:

 ```sh
 $ git remote set-head origin --auto
-origin/HEAD set to master
+origin/HEAD set to main
 ```

 ## Rebasing y Merging
@ -867,20 +866,20 @@ Desafortunadamente, debes forzar el push, si deseas que esos cambios se reflejen


 ```sh
-(master)$ git checkout my-branch
-(my-branch)$ git rebase -i master
-(my-branch)$ git checkout master
-(master)$ git merge --ff-only my-branch
+(main)$ git checkout my-branch
+(my-branch)$ git rebase -i main
+(my-branch)$ git checkout main
+(main)$ git merge --ff-only my-branch
 ```

 Para obtener más información, consulte [este thread SO] (https://stackoverflow.com/questions/11058312/how-can-i-use-git-rebase-without-requiring-a-forced-push).

 ### Necesito combinar commits

-Supongamos que estás trabajando en una rama que es / se convertirá en un pull request contra master. En el caso más simple, cuando todo lo que quiere hacer es combinar todos los commits en uno solo y no le importa cometer timestamps, puedes restablecer y volver a hacer el commit. Asegúrate de que la rama principal esté actualizada y de que se hayan confirmado todos los cambios, luego:
+Supongamos que estás trabajando en una rama que es / se convertirá en un pull request contra main. En el caso más simple, cuando todo lo que quiere hacer es combinar todos los commits en uno solo y no le importa cometer timestamps, puedes restablecer y volver a hacer el commit. Asegúrate de que la rama principal esté actualizada y de que se hayan confirmado todos los cambios, luego:

 ```sh
-(my-branch)$ git reset --soft master
+(my-branch)$ git reset --soft main
 (my-branch)$ git commit -am "New awesome feature"
 ```

@ -888,13 +887,13 @@ Si deseas más control y también conservar las marcas de tiempo, debe hacer alg


 ```sh
-(my-branch)$ git rebase -i master
+(my-branch)$ git rebase -i main
 ```

 Si no estás trabajando contra otra rama tendrás que volver a establecer una base relativa a tu `HEAD`. Si quieres aplastar las últimas 2 confirmaciones, por ejemplo, tendrás que volver a calcular contra `HEAD ~ 2`. Para los últimos 3, `HEAD ~ 3`, etc.

 ```sh
-(master)$ git rebase -i HEAD~2
+(main)$ git rebase -i HEAD~2
 ```

 Después de ejecutar el comando de rebase interactivo, verás algo como esto en tu editor de texto:
@ -956,7 +955,7 @@ Newer, awesomer features
 # Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
 # rebase in progress; onto 8074d12
-# You are currently editing a commit while rebasing branch 'master' on '8074d12'.
+# You are currently editing a commit while rebasing branch 'main' on '8074d12'.
 #
 # Changes to be committed:
 #   modified:   README.md
@ -967,20 +966,20 @@ Newer, awesomer features
 Si todo tiene éxito, deberías ver algo como esto:

 ```sh
-(master)$ Successfully rebased and updated refs/heads/master.
+(main)$ Successfully rebased and updated refs/heads/main.
 ```

 #### Estrategia de merge segura
 `--no-commit` realiza el merge, pero simula que la combinación falló y no se confirma automáticamente, lo que le da al usuario la oportunidad de inspeccionar y modificar aún más el resultado de la combinación antes de realizar la tarea. `no-ff` mantiene la evidencia de que alguna vez existió una rama de características, manteniendo la historia del proyecto consistente.

 ```sh
-(master)$ git merge --no-ff --no-commit my-branch
+(main)$ git merge --no-ff --no-commit my-branch
 ```

 #### Necesito fusionar una rama en un solo commit

 ```sh
-(master)$ git merge --squash my-branch
+(main)$ git merge --squash my-branch
 ```

 #### Quiero combinar solo los commits sin haber hecho push
@ -988,7 +987,7 @@ Si todo tiene éxito, deberías ver algo como esto:
 A veces tiene varios commits en progreso que deseas combinar antes de hacer push. No deseas combinar accidentalmente ningún commit que ya haya sido pusheado porque otra persona ya haya realizado commits que les hagan referencia.

 ```sh
-(master)$ git rebase -i @{u}
+(main)$ git rebase -i @{u}
 ```

 Esto hará una base de datos interactiva que enumera solo los commits que aún no has enviado, por lo que será seguro reordenar / arreglar / aplastar cualquier elemento de la lista.
@ -1008,13 +1007,13 @@ Este comando está disponible desde la versión de Git> = 1.7.4
 Para comprobar si todos los commits de una rama se fusionan en otra, debe distinguir las cabeceras (o los commits) de esas ramas:

 ```sh
-(master)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll
+(main)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll
 ```

 Esto te dirá si hay commits en una pero no en la otra, y te dará una lista de las no compartidas entre las ramas. Otra opción es hacer esto:

 ```sh
-(master)$ git log master ^feature/120-on-scroll --no-merges
+(main)$ git log main ^feature/120-on-scroll --no-merges
 ```

 ### Posibles problemas con rebase interactivos
@ -1062,16 +1061,16 @@ Tendrás que resolver las diferencias entre el código que se agregó en tu nuev
 Si deseas conservar la versión del código de una rama, puedes usar `--us` o` --theirs`:

 ```sh
-(master*)$ git checkout --ours README.md
+(main*)$ git checkout --ours README.md
 ```

 - Cuando haces *merge*, usa `--ours` para mantener los cambios de la rama local, o` --theirs` para mantener los cambios de la otra rama.
- Cuando haces *rebase*, usa `--theirs` para mantener los cambios de la rama local, o` --ours` para mantener los cambios de la otra rama. Para obtener una explicación de este intercambio, consulte [esta nota en la documentación de Git] (https://git-scm.com/docs/git-rebase#git-rebase---merge).
+- Cuando haces *rebase*, usa `--theirs` para mantener los cambios de la rama local, o` --ours` para mantener los cambios de la otra rama. Para obtener una explicación de este intercambio, consulte [esta nota en la documentación de Git] (https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---merge).

 Si las fusiones son más complicadas, puede usar un editor visual diff:

 ```sh
-(master*)$ git mergetool -t opendiff
+(main*)$ git mergetool -t opendiff
 ```

 Después de haber resuelto todos los conflictos y probado el código, `git add` los archivos que has cambiado, y luego continúa el rebase con` git rebase --continue`
@ -1275,7 +1274,7 @@ From github.com:foo/bar
 ### Exportar un repositorio como un archivo Zip

 ```sh
-$ git archive --format zip --output /full/path/to/zipfile.zip master
+$ git archive --format zip --output /full/path/to/zipfile.zip main
 ```

 ## Seguimiento de archivos
@ -1283,20 +1282,20 @@ $ git archive --format zip --output /full/path/to/zipfile.zip master
 ### Quiero cambiar el uso de mayúsculas de un nombre de archivo, sin cambiar el contenido del archivo

 ```sh
-(master)$ git mv --force myfile MyFile
+(main)$ git mv --force myfile MyFile
 ```

 ### Quiero sobrescribir los archivos locales cuando hago un git pull

 ```sh
-(master)$ git fetch --all
-(master)$ git reset --hard origin/master
+(main)$ git fetch --all
+(main)$ git reset --hard origin/main
 ```

 ### Quiero eliminar un archivo de Git pero mantener el archivo

 ```sh
-(master)$ git rm --cached log.txt
+(main)$ git rm --cached log.txt
 ```

 ### Quiero revertir un archivo a una revisión específica
@ -1304,13 +1303,13 @@ $ git archive --format zip --output /full/path/to/zipfile.zip master
 Suponiendo que el hash del commit que deseas es c5f567:

 ```sh
-(master)$ git checkout c5f567 -- file1/to/restore file2/to/restore
+(main)$ git checkout c5f567 -- file1/to/restore file2/to/restore
 ```

 Si desea volver a los cambios realizados solo 1 commit antes de c5f567, pase el hash de confirmación como c5f567 ~ 1:

 ```sh
-(master)$ git checkout c5f567~1 -- file1/to/restore file2/to/restore
+(main)$ git checkout c5f567~1 -- file1/to/restore file2/to/restore
 ```

 ## Configuración
@ -1395,21 +1394,21 @@ Entonces, estás jodido, "reiniciaste" algo, o fusionaste la rama incorrecta, o
 Para esto está hecho `git reflog`. `reflog` realiza un seguimiento de los cambios en la punta de una rama, incluso si esa sugerencia no está referenciada por una rama o una etiqueta. Básicamente, cada vez que HEAD cambia, se agrega una nueva entrada al reflog. Esto solo funciona para los repositorios locales, lamentablemente, y solo rastrea los movimientos (no los cambios a un archivo que no fueron grabados en ninguna parte, por ejemplo).

 ```sh
-(master)$ git reflog
+(main)$ git reflog
 0a2e358 HEAD@{0}: reset: moving to HEAD~2
-0254ea7 HEAD@{1}: checkout: moving from 2.2 to master
-c10f740 HEAD@{2}: checkout: moving from master to 2.2
+0254ea7 HEAD@{1}: checkout: moving from 2.2 to main
+c10f740 HEAD@{2}: checkout: moving from main to 2.2
 ```

-El reflog anterior muestra una salida desde master a la rama 2.2 y viceversa. A partir de ahí, hay un restablecimiento completo de un commit más antiguo. La última actividad se representa en la parte superior con la etiqueta 'HEAD @ {0} `.
+El reflog anterior muestra una salida desde main a la rama 2.2 y viceversa. A partir de ahí, hay un restablecimiento completo de un commit más antiguo. La última actividad se representa en la parte superior con la etiqueta 'HEAD @ {0} `.

-Si resulta que retrocedió accidentalmente, el reflog contendrá el master de un commit apuntado a (0254ea7) antes de que accidentalmente soltara 2 commits.
+Si resulta que retrocedió accidentalmente, el reflog contendrá el main de un commit apuntado a (0254ea7) antes de que accidentalmente soltara 2 commits.

 ```sh
 $ git reset --hard 0254ea7
 ```

-Usando `git reset` es posible cambiar el master al commit que era antes. Esto proporciona una red de seguridad en caso de que la historia se haya cambiado accidentalmente.
+Usando `git reset` es posible cambiar el main al commit que era antes. Esto proporciona una red de seguridad en caso de que la historia se haya cambiado accidentalmente.

 (copiado y editado desde [Fuente] (https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog)).

--- a/README_fr.md
+++ b/README_fr.md
@ -1,7 +1,7 @@
 # Règles de vol pour Git

 🌍
-*[English](README.md) ∙ [Español](README_es.md)  ∙  [Русский](README_ru.md) ∙ [简体中文](README_zh-CN.md)∙ [한국어](README_kr.md)  ∙  [Tiếng Việt](README_vi.md) ∙ [Français](README_fr.md)*
+*[English](README.md) ∙ [Español](README_es.md)  ∙  [Русский](README_ru.md) ∙ [繁體中文](README_zh-TW.md) ∙ [简体中文](README_zh-CN.md) ∙ [한국어](README_kr.md)  ∙  [Tiếng Việt](README_vi.md) ∙ [Français](README_fr.md) ∙ [日本語](README_ja.md)*

 #### C'est quoi des "règles de vol" ?

@ -57,7 +57,7 @@ Toutes les commandes devraient fonctionner pour les versions de Git au moins sup
    - [Créer une branche à partir d'un commit](#cr%C3%A9er-une-branche-%C3%A0-partir-dun-commit)
    - [J'ai pull depuis/vers la mauvaise branche](#jai-pull-depuisvers-la-mauvaise-branche)
    - [Je veux supprimer mes commits locaux afin que ma branche soit pareille à celle sur le serveur](#je-veux-supprimer-mes-commits-locaux-afin-que-ma-branche-soit-pareille-%C3%A0-celle-sur-le-serveur)
-    - [J'ai commité sur master au lieu d'une nouvelle branche](#jai-commit%C3%A9-sur-master-au-lieu-dune-nouvelle-branche)
+    - [J'ai commité sur main au lieu d'une nouvelle branche](#jai-commit%C3%A9-sur-main-au-lieu-dune-nouvelle-branche)
    - [Je veux séparer tout un fichier d'un autre ref-ish](#je-veux-s%C3%A9parer-tout-un-fichier-dun-autre-ref-ish)
    - [J'ai fait plusieurs commits sur une même branche qui auraient dû être sur plusieurs branches](#jai-fait-plusieurs-commits-sur-une-m%C3%AAme-branche-qui-auraient-d%C3%BB-%C3%AAtre-sur-plusieurs-branches)
    - [Je veux supprimer mes branches locales qui ont été supprimée sur le dépôt distant](#je-veux-supprimer-mes-branches-locales-qui-ont-%C3%A9t%C3%A9-supprim%C3%A9e-sur-le-d%C3%A9p%C3%B4t-distant)
@ -116,7 +116,6 @@ Toutes les commandes devraient fonctionner pour les versions de Git au moins sup
    - [Je veux mettre en cache un nom d'utilisateur et mot de passe pour un dépôt](#je-veux-mettre-en-cache-un-nom-dutilisateur-et-mot-de-passe-pour-un-d%C3%A9p%C3%B4t)
    - [Je veux que Git ignore les changements de permissions et de filemode](#je-veux-que-git-ignore-les-changements-de-permissions-et-de-filemode)
    - [Je veux définir un utilisateur global](#je-veux-d%C3%A9finir-un-utilisateur-global)
-    - [Je veux ajouter une ligne de commande de coloration pour Git](#je-veux-ajouter-une-ligne-de-commande-de-coloration-pour-git)
  - [Je n'ai aucune idée de ce que j'ai mal fait](#je-nai-aucune-id%C3%A9e-de-ce-que-jai-mal-fait)
 - [Autres Ressources](#autres-ressources)
  - [Livres](#livres)
@ -160,7 +159,7 @@ $ git clone [url] nom-du-nouveau-dossier
 Imaginons que vous venez tout juste d'enregistrer des changements à l'aveugle avec {code0}git commit -a{/code0} et que vous n'êtes pas sûr·e du contenu réel du commit que vous venez d'effectuer. Vous pouvez visualiser le dernier commit sur votre HEAD actuel avec :

 ```sh
-(master)$ git show
+(main)$ git show
 ```

 Ou :
@ -175,6 +174,7 @@ Si vous voulez voir un fichier à un commit spécifique, vous pouvez aussi faire
 $ git show <commitid>:nomdufichier
 ```

+<a name="wrong-thing-in-commit-message"></a>
 ### J'ai commis une erreur dans un message de commit

 Si vous vous êtes trompé·e et que le commit n'a pas encore été poussé, vous pouvez appliquer la commande suivante afin de changer le message du commit sans affecter les changements de ce même commit :
@ -240,7 +240,7 @@ $ git push --force-with-lease [remote] [branche]
 Si vous n'avez pas poussé, pour réinitialiser Git vers l'état dans lequel il était avant que vous ne fassiez votre dernier commit (tout en gardant vos changements) :

 ```
-(ma-branche*)$ git reset --soft HEAD@{1}
+(ma-branche)$ git reset --soft HEAD^
 ```

 Cela ne marchera que si vous n'avez pas poussé. Si vous avez poussé, la seule vraie chose sécurisée à faire est `git revert SHAduMauvaisCommit`. Cela créera un nouveau commit qui annule tous les changements du commit en question. Ou, si la branche vers laquelle vous avez poussé est "rebase-safe" (en d'autres termes, les autres développeur·euse·s ne la récupéreront pas), vous pouvez juste lancer `git push --force-with-lease`. Pour plus d'informations, jetez un œil [à la section ci-dessus](#je-veux-supprimer-ou-retirer-mon-dernier-commit).
@ -257,7 +257,7 @@ $ git push --force-with-lease [remote] [branche]

 Ou faites un [rebase interactif](#interactive-rebase) et retirez les lignes correspondantes au(x) commit(s) que vous souhaitez supprimer.

-<a name="#force-push"></a>
+<a name="force-push"></a>
 ### J'ai essayé de pousser un commit modifié vers le dépôt distant, mais j'ai eu un message d'erreur

 ```sh
@ -280,7 +280,7 @@ En règle générale, **évitez de pousser de force**. Il est préférable de cr

 Si vous êtes *absolument* sûr·e que personne n'est en train de travailler sur la même branche que vous ou que vous souhaitez mettre à jour la branche de manière *inconditionnelle*, vous pouvez utiliser `--force` (`-f`), mais cela devrait être évité en général.

-<a href="undo-git-reset-hard"></a>
+<a name="undo-git-reset-hard"></a>
 ### J'ai fait un hard reset par accident, et je veux retrouver mes changements

 Si vous avez accidentellement fait un `git reset --hard`, vous pouvez normalement retrouver votre commit, car Git garde un log de tout ce que vous faites pendant quelques jours.
@ -288,18 +288,18 @@ Si vous avez accidentellement fait un `git reset --hard`, vous pouvez normalemen
 À noter : Cela n'est valide que si votre travail est sauvegardé, c'est à dire dans un commit ou un remisage. `git reset --hard` *supprimera* les modifications non commitées, donc utilisez cela avec précaution (une option plus sûre est `git reset --keep`).

 ```sh
-(master)$ git reflog
+(main)$ git reflog
 ```

 Vous verrez une liste de vos précédents commits, et un commit pour la réinitialisation. Choisissez le SHA du commit vers lequel vous souhaitez retourner, et réinitialisez à nouveau :

 ```sh
-(master)$ git reset --hard SHA1234
+(main)$ git reset --hard SHA1234
 ```

 Et cela devrait faire l'affaire.

-<a href="undo-a-commit-merge"></a>
+<a name="undo-a-commit-merge"></a>
 ### J'ai commité et poussé une fusion par accident

 Si vous avez accidentellement fusionné une branche d'une fonctionnalité avec la branche de développement principale avant qu'elle ne soit prête à être fusionnée, vous pouvez toujours annuler cette fusion. Mais il y a un piège : un commit de fusion a plus d'un parent (en général deux).
@ -313,7 +313,7 @@ où l'option `-m 1` demande de sélectionner le parent numéro 1 (la branche ver

 À noter : le numéro du parent n'est pas un identifiant de commit. Un commit de fusion ressemble plus à `Merge: 8e2ce2d 86ac2e7`. Le numéro du parent est l'index basé sur 1 du parent souhaité sur cette ligne, le premier identifiant est le numéro 1, le second le numéro 2, et ainsi de suite.

-<a href="undo-sensitive-commit-push"></a>
+<a name="undo-sensitive-commit-push"></a>
 ### J'ai commité et poussé des fichiers contenant des données sensibles par accident

 Si vous avez accidentellement poussé des fichiers contenant des données sensibles (mots de passe, clés, etc.), vous pouvez modifier le commit précédent. Gardez toutefois à l'esprit qu'une fois que vous avez poussé un commit, vous devez considérer n'importe quelle donnée qu'il contient comme étant compromise. Ces étapes peuvent supprimer les données sensibles de votre dépôt public ou de votre copie locale, mais vous ne **pouvez pas** supprimer les données sensibles des copies clonées par d'autres personnes. Si vous avez commité un mot de passe, **changez-le immédiatement**. Si vous avez commité une clé, **révoquez-la et régénérez-la immédiatement**. Modifier le commit poussé n'est pas suffisant, étant donné que n'importe qui aurait pu extraire le commit original contenant vos données sensibles pendant ce temps.
@ -346,7 +346,7 @@ Si vous avez créé d'autres commits pendant ce temps (c'est à dire que les don

 ## Indexation

-<a href="#i-need-to-add-staged-changes-to-the-previous-commit"></a>
+<a name="add-staged-changes-to-previous-commit"></a>
 ### J'ai besoin d'ajouter des modifications indexées sur le commit précédent

 ```sh
@ -377,12 +377,12 @@ $ git add -N nomdufichier.x

 Ensuite, vous devrez utiliser l'option `e` afin de choisir manuellement quelles lignes ajouter. Lancer `git diff --cached` ou `git diff --staged` vous montrera quelles lignes vous avez indexées comparées à celles qui sont toujours sauvegardées en local.

-<a href="stage-in-two-commits"></a>
+<a name="stage-in-two-commits"></a>
 ### Je veux ajouter les changements d'un fichier dans deux commits différents

 `git add` ajoutera le fichier entier à un commit. `git add -p` vous permettra de sélectionner interactivement quels changements vous souhaitez ajouter.

-<a href="unstaging-edits-and-staging-the-unstaged"></a>
+<a name="unstaging-edits-and-staging-the-unstaged"></a>
 ### Je veux indexer mes modifications indexées, et désindexer mes modifications indexées

 Cela est délicat. La meilleure chose que nous pouvons vous conseiller est que vous devriez remiser vos modifications non indexées, puis utiliser `git reset`. Après cela, utilisez `pop` pour déremiser vos modifications, puis ajoutez-les :
@ -396,14 +396,14 @@ $ git add -A

 ## Modifications non indexées

-<a href="move-unstaged-edits-to-new-branch"></a>
+<a name="move-unstaged-edits-to-new-branch"></a>
 ### Je veux déplacer mes modifications non indexées vers une nouvelle branche

 ```sh
 $ git checkout -b ma-branche
 ```

-<a href="move-unstaged-edits-to-old-branch"></a>
+<a name="move-unstaged-edits-to-old-branch"></a>
 ### Je veux déplacer mes modifications non indexées vers une branche différente existante

 ```sh
@ -412,7 +412,7 @@ $ git checkout ma-branche
 $ git stash pop
 ```

-<a href="i-want-to-discard-my-local-uncommitted-changes"></a>
+<a name="discard-local-uncommitted-changes"></a>
 ### Je veux me débarrasser de mes modifications locales non commitées (indexées et non-indexées)

 Si vous voulez vous débarrasser de toutes vos modifications locales indexées et non-indexées, vous pouvez faire ceci :
@ -420,7 +420,7 @@ Si vous voulez vous débarrasser de toutes vos modifications locales indexées e
 ```sh
 (ma-branche)$ git reset --hard
 # ou
-(master)$ git checkout -f
+(main)$ git checkout -f
 ```

 Cette commande désindexera tous les fichiers que vous avez pu indexer avec `git add` :
@ -502,7 +502,7 @@ Quand vous souhaitez vous débarrasser de toutes vos modifications locales non c
 ```sh
 $ git checkout .
 ```
-<a href="i-want-to-discard-all-my-untracked-files"></a>
+<a name="discard-all-untracked-files"></a>
 ### Je veux me débarrasser de tous mes fichiers non suivis

 Quand vous souhaitez vous débarrasser de tous vos fichiers non suivis :
@ -511,7 +511,7 @@ Quand vous souhaitez vous débarrasser de tous vos fichiers non suivis :
 $ git clean -f
 ```

-<a href="I-want-to-unstage-specific-staged-file"></a>
+<a name="unstage-specific-staged-file"></a>
 ### Je veux désindexer un fichier indexé spécifique

 Il arrive parfois que nous ayons un ou plusieurs fichiers qui ont été indexés par accident. Et ces fichiers n'ont pas été commités auparavant. Pour les désindexer :
@ -556,7 +556,7 @@ $ git checkout -b <branche> <SHA1_DU_COMMIT>
 C'est une autre occasion d'utiliser `git reflog` afin de voir où votre HEAD pointait avant le mauvais `pull` :

 ```sh
-(master)$ git reflog
+(main)$ git reflog
 ab7555f HEAD@{0}: pull origin wrong-branch: Fast-forward
 c5bc55a HEAD@{1}: checkout: checkout message goes here
 ```
@ -569,7 +569,7 @@ $ git reset --hard c5bc55a

 Et voilà.

-<a href="discard-local-commits"></a>
+<a name="discard-local-commits"></a>
 ### Je veux supprimer mes commits locaux afin que ma branche soit pareille à celle sur le serveur

 Assurez-vous que vous n'avez pas poussé vos modifications sur le serveur.
@ -577,7 +577,6 @@ Assurez-vous que vous n'avez pas poussé vos modifications sur le serveur.
 `git status` devrait vous indiquer combien de commits en avance vous êtes par rapport à origin :

 ```sh
-(my-branch)$ git status
 (ma-branche)$ git status
 # On branch ma-branche
 # Your branch is ahead of 'origin/my-branch' by 2 commits.
@ -588,41 +587,41 @@ Assurez-vous que vous n'avez pas poussé vos modifications sur le serveur.
 Une des façons de faire pour réinitialiser votre branche afin qu'elle corresponde à origin (afin d'avoir la même chose que le dépôt distant) est de lancer ceci :

 ```sh
-(master)$ git reset --hard origin/ma-branche
+(ma-branche)$ git reset --hard origin/ma-branche
 ```

 <a name="commit-wrong-branch"></a>
-### J'ai commité sur master au lieu d'une nouvelle branche
+### J'ai commité sur main au lieu d'une nouvelle branche

-Créez la nouvelle branche tout en restant sur master :
+Créez la nouvelle branche tout en restant sur main :

 ```sh
-(master)$ git branch ma-branche
+(main)$ git branch ma-branche
 ```

-Réinitialisez la branche master vers le commit précédent :
+Réinitialisez la branche main vers le commit précédent :

 ```sh
-(master)$ git reset --hard HEAD^
+(main)$ git reset --hard HEAD^
 ```

 `HEAD^` est un raccourci pour `HEAD^1`. Cela indique le premier parent de `HEAD`, de la même façon que `HEAD^2` indique le second parent du commit (des fusions peuvent avoir deux parents).

 Notez que `HEAD^2` ne signifie **pas** la même chose que `HEAD~2` (visitez [ce lien](http://www.paulboxley.com/blog/2011/06/git-caret-and-tilde) pour plus d'informations).

-Alternativement, si vous ne souhaitez pas utiliser `HEAD^`, retrouvez le hash du commit vers lequel vous souhaitez remettre votre branche master (`git log` devrait faire l'affaire). Puis réinitialisez vers ce hash. `git push` s'assurera que la modification est reflétée sur le serveur distant.
+Alternativement, si vous ne souhaitez pas utiliser `HEAD^`, retrouvez le hash du commit vers lequel vous souhaitez remettre votre branche main (`git log` devrait faire l'affaire). Puis réinitialisez vers ce hash. `git push` s'assurera que la modification est reflétée sur le serveur distant.

-Par exemple, si le hash du commit sur lequel votre branche master est supposée être est `a13b85e` :
+Par exemple, si le hash du commit sur lequel votre branche main est supposée être est `a13b85e` :

 ```sh
-(master)$ git reset --hard a13b85e
+(main)$ git reset --hard a13b85e
 HEAD is now at a13b85e
 ```

 Déplacez-vous vers la nouvelle branche pour continuer de travailler :

 ```sh
-(master)$ git checkout ma-branche
+(main)$ git checkout ma-branche
 ```

 <a name="keep-whole-file"></a>
@ -665,10 +664,10 @@ Note: Les pics de solutions servent à analyser ou résoudre un problème. Ces s
 <a name="cherry-pick"></a>
 ### J'ai fait plusieurs commits sur une même branche qui auraient dû être sur plusieurs branches

-Admettons que vous êtes sur votre branche master. En lançant `git log`, vous remarquez que vous avez fait deux commits :
+Admettons que vous êtes sur votre branche main. En lançant `git log`, vous remarquez que vous avez fait deux commits :

 ```sh
-(master)$ git log
+(main)$ git log

 commit e3851e817c451cc36f2e6f3049db528415e3c114
 Author: Alex Lee <alexlee@example.com>
@ -691,17 +690,17 @@ Date:   Tue Jul 21 01:12:48 2014 -0400

 Notons dans un coin les hashes des commits pour chaque bug (`e3851e8` pour le #21, `5ea5173` pour le #14).

-Pour commencer, réinitialisons notre branche master sur le bon commit (`a13b85e`) :
+Pour commencer, réinitialisons notre branche main sur le bon commit (`a13b85e`) :

 ```sh
-(master)$ git reset --hard a13b85e
+(main)$ git reset --hard a13b85e
 HEAD is now at a13b85e
 ```

 Maintenant, nous pouvons créer une nouvelle branche pour le bug #21 :

 ```sh
-(master)$ git checkout -b 21
+(main)$ git checkout -b 21
 (21)$
 ```

@ -713,11 +712,11 @@ Maintenant, faisons un `cherry-pick` du commit pour le bug #21 par-dessus notre

 Lors de cette étape, il est possible qu'il y ait des conflits. Regardez la section [**Il y a eu des conflits**](#merge-conflict) dans la section [faire un rebase interactif](#interactive-rebase) ci-dessus pour savoir comment résoudre ces conflits.

-Maintenant, créons une nouvelle branche pour le bug #14, aussi basée sur master :
+Maintenant, créons une nouvelle branche pour le bug #14, aussi basée sur main :

 ```sh
-(21)$ git checkout master
-(master)$ git checkout -b 14
+(21)$ git checkout main
+(main)$ git checkout -b 14
 (14)$
 ```

@ -737,13 +736,13 @@ $ git fetch -p upstream

 où `upstream` est le dépôt distant depuis lequel vous voulez mettre à jour.

-<a name='restore-a-deleted-branch'></a>
+<a name="restore-a-deleted-branch"></a>
 ### J'ai supprimé ma branche par accident

 Si vous poussez régulièrement sur la branche distante, vous devriez ne pas avoir de problème la plupart du temps. Mais il arrive parfois que vous finissez par supprimer vos branches. Admettons que nous créons une nouvelle branche avec un nouveau fichier :

 ```sh
-(master)$ git checkout -b ma-branche
+(main)$ git checkout -b ma-branche
 (ma-branceh)$ git branch
 (ma-branche)$ touch foo.txt
 (ma-branche)$ ls
@ -773,31 +772,31 @@ Date:   Tue Jul 29 13:14:46 2014 -0400
    Correction #6: Push de force après avoir édité les commits
 ```

-Maintenant, revenons sur master et supprimons notre branche "par accident" :
+Maintenant, revenons sur main et supprimons notre branche "par accident" :

 ```sh
-(ma-branche)$ git checkout master
-Switched to branch 'master'
-Your branch is up-to-date with 'origin/master'.
-(master)$ git branch -D my-branch
+(ma-branche)$ git checkout main
+Switched to branch 'main'
+Your branch is up-to-date with 'origin/main'.
+(main)$ git branch -D my-branch
 Deleted branch ma-branche (was 4e3cd85).
-(master)$ echo oh non, j'ai supprimé ma branche !
+(main)$ echo oh non, j'ai supprimé ma branche !
 oh non, j'ai supprimé ma branche !
 ```

 À cette étape, vous devriez devenir familier avec `reflog`, un logueur amélioré. Il stocke l'historique de toutes les actions dans le dépôt :

 ```
-(master)$ git reflog
-69204cd HEAD@{0}: checkout: moving from ma-branche to master
+(main)$ git reflog
+69204cd HEAD@{0}: checkout: moving from ma-branche to main
 4e3cd85 HEAD@{1}: commit: ajout de foo.txt
-69204cd HEAD@{2}: checkout: moving from master to ma-branche
+69204cd HEAD@{2}: checkout: moving from main to ma-branche
 ```

 Comme vous pouvez le remarquer, nous avons le hash du commit de notre branche supprimée. Voyons voir si nous pouvons restaurer notre branche supprimée.

 ```sh
-(master)$ git checkout -b ma-branche-help
+(main)$ git checkout -b ma-branche-help
 Switched to a new branch 'ma-branche-help'
 (ma-branche-help)$ git reset --hard 4e3cd85
 HEAD is now at 4e3cd85 ajout de foo.txt
@ -812,25 +811,25 @@ Voilà ! Nous avons récupéré notre fichier supprimé. `git reflog` est aussi
 Pour supprimer une branche distante :

 ```sh
-(master)$ git push origin --delete ma-branche
+(main)$ git push origin --delete ma-branche
 ```

 Vous pouvez aussi faire :

 ```sh
-(master)$ git push origin :ma-branche
+(main)$ git push origin :ma-branche
 ```

 Pour supprimer une branche locale :

 ```sh
-(master)$ git branch -d ma-branche
+(main)$ git branch -d ma-branche
 ```

 Pour supprimer une branche locale qui *n'a pas* été fusionnée vers la branche actuelle ou une branche distante :

 ```sh
-(master)$ git branch -D ma-branche
+(main)$ git branch -D ma-branche
 ```

 ### Je veux supprimer plusieurs branches
@ -838,7 +837,7 @@ Pour supprimer une branche locale qui *n'a pas* été fusionnée vers la branche
 Admettons que vous voulez supprimer toutes les branches qui commencent par `fix/` :

 ```sh
-(master)$ git branch | grep 'fix/' | xargs git branch -d
+(main)$ git branch | grep 'fix/' | xargs git branch -d
 ```

 ### Je veux renommer une branche
@ -846,28 +845,28 @@ Admettons que vous voulez supprimer toutes les branches qui commencent par `fix/
 Je veux renommer la branche actuelle (locale) :

 ```sh
-(master)$ git branch -m nouveau-nom
+(main)$ git branch -m nouveau-nom
 ```

 Pour renommer une autre branche (locale) :

 ```sh
-(master)$ git branch -m ancien-nom nouveau-nom
+(main)$ git branch -m ancien-nom nouveau-nom
 ```

-<a name="i-want-to-checkout-to-a-remote-branch-that-someone-else-is-working-on"></a>
+<a name="working-on-checkout-remote-branch"></a>
 ### Je veux me déplacer sur une branche distante sur laquelle quelqu'un est en train de travailler

 Pour commencer, récupérez toutes les branches depuis le dépôt distant :

 ```sh
-(master)$ git fetch --all
+(main)$ git fetch --all
 ```

 Admettons que vous souhaitez vous déplacer sur `daves` depuis le dépôt distant :

 ```sh
-(master)$ git checkout --track origin/daves
+(main)$ git checkout --track origin/daves
 Branch daves set up to track remote branch daves from origin.
 Switched to a new branch 'daves'
 ```
@ -894,7 +893,7 @@ Avec le mode `upstream` et le mode `simple` (défaut dans Git 2.0) de la configu
 $ git push
 ```

-Le comportement des autres modes de `git push` est détaillé dans la [documentation de `push.default`](https://git-scm.com/docs/git-config#git-config-pushdefault).
+Le comportement des autres modes de `git push` est détaillé dans la [documentation de `push.default`](https://git-scm.com/docs/git-config#Documentation/git-config.txt-pushdefault).

 ### Je veux configurer une branche distante en tant qu'upstream pour une branche locale

@ -912,7 +911,7 @@ Pour configurer la branche distante en tant qu'upstream pour une autre branche l
 $ git branch -u [nomduremote]/[branche] [branche-locale]
 ```

-<a name="i-want-to-set-my-HEAD-to-track-the-default-remote-branch"></a>
+<a name="head-to-track-remote-branch"></a>
 ### Je veux configurer mon HEAD pour suivre la branche distante par défaut

 En vérifiant vos branches distantes, vous pouvez voir lesquelles d'entre-elles sont suivies par HEAD. Dans certains cas, ce n'est pas la branche désirée.
@ -920,14 +919,14 @@ En vérifiant vos branches distantes, vous pouvez voir lesquelles d'entre-elles
 ```sh
 $ git branch -r
  origin/HEAD -> origin/gh-pages
-  origin/master
+  origin/main
 ```

-Pour changer cela afin que `origin/HEAD` suive `origin/master`, vous pouvez lancer cette commande :
+Pour changer cela afin que `origin/HEAD` suive `origin/main`, vous pouvez lancer cette commande :

 ```sh
 $ git remote set-head origin --auto
-origin/HEAD set to master
+origin/HEAD set to main
 ```

 ### J'ai fait des modifications sur la mauvaise branche
@ -957,10 +956,10 @@ Il se peut que vous avez fait une fusion ou un rebase sur votre branche actuelle
 Malheureusement, vous devez pousser de force si vous souhaitez que ces modifications soient répercutées sur la branche distante. C'est parce que vous avez changé l'historique. La branche distante n'acceptera pas les modifications, sauf si vous poussez de force. C'est l'une des principales raisons pour lesquelles de nombreuses personnes utilisent un flux de travail à base de fusions plutôt qu'un flux de travail à base de rebase : les grandes équipes peuvent avoir des problèmes avec les développeurs qui poussent de force. Utilisez ceci avec prudence. Une façon plus sûre d'utiliser rebase est de ne pas du tout refléter vos modifications sur la branche distante, mais plutôt de procéder de la manière suivante :

 ```sh
-(master)$ git checkout ma-branche
-(ma-branche)$ git rebase -i master
-(ma-branche)$ git checkout master
-(master)$ git merge --ff-only ma-branche
+(main)$ git checkout ma-branche
+(ma-branche)$ git rebase -i main
+(ma-branche)$ git checkout main
+(main)$ git merge --ff-only ma-branche
 ```

 Pour plus d'informations, visitez [ce thread de SO](https://stackoverflow.com/questions/11058312/how-can-i-use-git-rebase-without-requiring-a-forced-push).
@ -968,23 +967,23 @@ Pour plus d'informations, visitez [ce thread de SO](https://stackoverflow.com/qu
 <a name="interactive-rebase"></a>
 ### J'ai besoin de combiner des commits

-Admettons que vous êtes en train de travailler sur une branche qui sera ou est dans une demande de fusion vers `master`. Dans le cas le plus simple, il suffit de combiner *tous* vos commits en un seul et vous vous fichez des timestamps des commits, vous pouvez faire un reset et recommiter. Assurez-vous que la branche master est à jour et que toutes vos modifications sont commitées, puis faites :
+Admettons que vous êtes en train de travailler sur une branche qui sera ou est dans une demande de fusion vers `main`. Dans le cas le plus simple, il suffit de combiner *tous* vos commits en un seul et vous vous fichez des timestamps des commits, vous pouvez faire un reset et recommiter. Assurez-vous que la branche main est à jour et que toutes vos modifications sont commitées, puis faites :

 ```sh
-(ma-branche)$ git reset --soft master
+(ma-branche)$ git reset --soft main
 (ma-branche)$ git commit -am "Nouvelle fonctionnalité géniale"
 ```

 Si vous voulez plus de contrôle, et également conserver les timestamps, vous devez faire ce qu'on appelle un rebase interactif :

 ```sh
-(ma-branche)$ git rebase -i master
+(ma-branche)$ git rebase -i main
 ```

 Si vous ne travaillez pas par rapport à une autre branche, vous allez devoir `rebase` relativement à votre `HEAD`. Si vous voulez combiner les 2 derniers commits par exemple, vous allez devoir `rebase` par rapport à `HEAD~2`. Pour les 3 derniers, `HEAD~3`, etc.

 ```sh
-(master)$ git rebase -i HEAD~2
+(main)$ git rebase -i HEAD~2
 ```

 Après avoir lancé votre commande `rebase`, vous verrez quelque chose dans le genre dans votre éditeur de texte :
@ -1044,7 +1043,7 @@ Nouvelles fonctionnalités encore plus géniales
 # Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
 # rebase in progress; onto 8074d12
-# You are currently editing a commit while rebasing branch 'master' on '8074d12'.
+# You are currently editing a commit while rebasing branch 'main' on '8074d12'.
 #
 # Changes to be committed:
 #   modified:   README.md
@ -1055,20 +1054,20 @@ Nouvelles fonctionnalités encore plus géniales
 Si tout se passe bien, vous devriez voir quelque chose comme ceci :

 ```sh
-(master)$ Successfully rebased and updated refs/heads/master.
+(main)$ Successfully rebased and updated refs/heads/main.
 ```

 #### Stratégie de fusion sûre
 `--no-commit` fait une fusion mais prétend que la fusion a échoué et ne commit pas automatiquement, laissant la chance à l'utilisateur d'inspecter plus et de bidouiller plus les résultats de la fusion avant de commiter. `no-ff` garde une preuve qu'une branche de fonctionnalité a auparavant existé, gardant ainsi l'historique du projet consistant :

 ```sh
-(master)$ git merge --no-ff --no-commit ma-branche
+(main)$ git merge --no-ff --no-commit ma-branche
 ```

 #### J'ai besoin de fusionner deux branches en un seul commit

 ```sh
-(master)$ git merge --squash ma-branche
+(main)$ git merge --squash ma-branche
 ```

 <a name="rebase-unpushed-commits"></a>
@ -1077,7 +1076,7 @@ Si tout se passe bien, vous devriez voir quelque chose comme ceci :
 Parfois, vous avez plusieurs commits en cours que vous souhaitez combiner avant de les pousser sur l'upstream. Vous ne voulez pas combiner des commits qui ont déjà été poussés sur l'upstream par accident, car quelqu'un d'autre a peut-être déjà effectué des commits qui y font référence :

 ```sh
-(master)$ git rebase -i @{u}
+(main)$ git rebase -i @{u}
 ```

 Cela fera un rebase interactif que liste seulement les commits que vous n'avez pas poussé, afin que cela soit plus sûr de réordonner/corriger/combiner n'importe lesquels de la liste.
@ -1094,26 +1093,26 @@ Cette commande est disponible dans Git depuis les versions >= 1.7.4

 ### J'ai besoin de mettre à jour le commit parent de ma branche

-Admettons que vous avez une branche master, une branche feature-1 créée à partir de master, et une branche feature-2 créée à partir de feature-1, puis que le commit parent de feature-2 n'est plus le bon (il devrait être celui correspondant au HEAD de feature-1, étant donné que notre branche a été créée à partir de celui-ci). Vous pouvez réparer ça avec `git rebase --onto` :
+Admettons que vous avez une branche main, une branche feature-1 créée à partir de main, et une branche feature-2 créée à partir de feature-1, puis que le commit parent de feature-2 n'est plus le bon (il devrait être celui correspondant au HEAD de feature-1, étant donné que notre branche a été créée à partir de celui-ci). Vous pouvez réparer ça avec `git rebase --onto` :

 ```sh
 (feature-2)$ git rebase --onto feature-1 <le premier commit dans votre branche feature-2 que vous ne voulez pas ramene> feature-2
 ```

-Cela peut vous venir en aide dans les situations délicates où vous avez une fonctionnalité créée sur la base d'une autre fonctionnalité qui n'a pas encore été fusionnée, et qu'une correction de bug sur la branche feature-1 a besoin d'être reflétée sur votre branche feature-2.  
+Cela peut vous venir en aide dans les situations délicates où vous avez une fonctionnalité créée sur la base d'une autre fonctionnalité qui n'a pas encore été fusionnée, et qu'une correction de bug sur la branche feature-1 a besoin d'être reflétée sur votre branche feature-2.

 ### Vérifier si tous les commits d'une branche sont fusionnés

 Pour vérifier si tous les commits d'une branche sont fusionnés sur une autre branche, vous devriez comparer les HEAD (ou n'importe quel autre commit) de ces branches :

 ```sh
-(master)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll
+(main)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll
 ```

 Cela vous dira si des commits sont dans l'une mais pas dans l'autre, et vous donnera une liste de tout ce qui n'est pas commun aux deux branches. Une alternative est de faire ceci :

 ```sh
-(master)$ git log master ^feature/120-on-scroll --no-merges
+(main)$ git log main ^feature/120-on-scroll --no-merges
 ```

 ### Problèmes possibles avec les rebase interactifs
@ -1128,7 +1127,7 @@ noop

 Cela signifie que vous êtes en train de rebaser par rapport à une branche qui a un commit identique, ou qui est *en avance* par rapport à votre branche actuelle. Vous pouvez essayer :

-* de vous assurez que votre branche master est là où elle devrait être
+* de vous assurez que votre branche main est là où elle devrait être
 * de rebaser par rapport à `HEAD~2` ou plus tôt à la place

 <a name="merge-conflict"></a>
@ -1163,16 +1162,16 @@ Vous aurez besoin de résoudre les différences entre le code qui fut ajouté da
 Si vous voulez garder la version du code d'une des branches, vous pouvez utiliser `--ours` ou `--theirs` :

 ```sh
-(master*)$ git checkout --ours README.md
+(main*)$ git checkout --ours README.md
 ```

 - Quand vous *fusionnez*, utilisez `--ours` pour garder les modifications de la branche locale, ou `--theirs` pour garder les modifications de l'autre branche.
- Quand vous *rebasez*, utilisez `--theirs` pour garder les modifications de la branche locale, ou `--ours` pour garder les modifications de l'autre branche. Pour des explications concernant cet échange, consultez [cette note dans la documentation de Git](https://git-scm.com/docs/git-rebase#git-rebase---merge).
+- Quand vous *rebasez*, utilisez `--theirs` pour garder les modifications de la branche locale, ou `--ours` pour garder les modifications de l'autre branche. Pour des explications concernant cet échange, consultez [cette note dans la documentation de Git](https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---merge).

 Si les fusions sont plus complexes, vous pouvez utiliser un éditeur de diff visuel :

 ```sh
-(master*)$ git mergetool -t opendiff
+(main*)$ git mergetool -t opendiff
 ```

 Après avoir résolu tous les conflits et testé votre code, faite un `git add` sur les fichiers que vous avez modifiés, puis continuez le rebase avec `git rebase --continue` :
@ -1263,7 +1262,7 @@ Paramètres communs :

 * `--reverse` retourne les résultats dans l'ordre inverse, c'est à dire que la commande affichera le premier commit qui a fait la modification.

-<a name="i-want-to-find-by-author-committer"></a>
+<a name="find-by-committer"></a>
 ### Je veux rechercher par auteur·trice/validateur·trice

 Pour rechercher des commits par auteur·trice/validateur·trice, vous pouvez utiliser :
@ -1356,7 +1355,7 @@ $ git push <remote> :refs/tags/<nom_du_tag>
 <a name="recover-tag"></a>
 ### Récupérer un tag supprimé

-Si vous voulez récupérer un tag qui a déjà été supprimé, vous pouvez le faire en suivant ces étapes :  
+Si vous voulez récupérer un tag qui a déjà été supprimé, vous pouvez le faire en suivant ces étapes :
 Tout d'abord, vous devez retrouver le tag inaccessible en question :

 ```sh
@ -1384,7 +1383,7 @@ From github.com:foo/bar
 ### Exporter un dépôt comme fichier Zip

 ```sh
-$ git archive --format zip --output /full/path/to/zipfile.zip master
+$ git archive --format zip --output /full/path/to/zipfile.zip main
 ```
 ### Pousser une branche et un tag qui ont le même nom

@ -1410,25 +1409,25 @@ $ git push origin refs/tags/<nom-du-tag>

 ## Suivre des fichiers

-<a href="i-want-to-change-a-file-names-capitalization-without-changing-the-contents-of-the-file"></a>
+<a name="change-file-name-capitalization-without-changing-contents"></a>
 ### Je veux changer la capitalisation du nom d'un fichier, sans changer son contenu

 ```sh
-(master)$ git mv --force monFichier MonFichier
+(main)$ git mv --force monFichier MonFichier
 ```

 ### Je veux écraser des fichiers locaux en faisant un git pull

 ```sh
-(master)$ git fetch --all
-(master)$ git reset --hard origin/master
+(main)$ git fetch --all
+(main)$ git reset --hard origin/main
 ```

-<a href="remove-from-git"></a>
+<a name="remove-from-git"></a>
 ### Je veux retirer un fichier de Git mais garder le fichier

 ```sh
-(master)$ git rm --cached log.txt
+(main)$ git rm --cached log.txt
 ```

 ### Je veux rétablir un fichier à une version spécifique
@ -1436,13 +1435,13 @@ $ git push origin refs/tags/<nom-du-tag>
 Supposons que le hash du commit que vous voulez est `c5f567` :

 ```sh
-(master)$ git checkout c5f567 -- file1/to/restore file2/to/restore
+(main)$ git checkout c5f567 -- file1/to/restore file2/to/restore
 ```

 Si vous voulez rétablir les changements effectués un commit avant `c5f567`, passez le hash du commit comme étant `c5f567~1` :

 ```sh
-(master)$ git checkout c5f567~1 -- file1/to/restore file2/to/restore
+(main)$ git checkout c5f567~1 -- file1/to/restore file2/to/restore
 ```

 ### Je veux lister les changements d'un fichier spécifique entre deux commits ou branches
@ -1451,12 +1450,16 @@ Supposons que vous voulez comparer le dernier commit avec le fichier du commit `

 ```sh
 $ git diff HEAD:path_to_file/file c5f567:path_to_file/file
+# ou
+$ git diff HEAD c5f567 -- path_to_file/file
 ```

 Il en est de même pour les branches :

 ```sh
-$ git diff master:path_to_file/file staging:path_to_file/file
+$ git diff main:path_to_file/file staging:path_to_file/file
+# ou
+$ git diff main staging -- path_to_file/file
 ```

 ### Je veux que Git ignore les changements d'un fichier spécifique
@ -1564,14 +1567,6 @@ Pour configurer une adresse email qui sera associée à chaque ligne de l'histor
 git config --global user.email “[adresse-email-valide]”
 ```

-### Je veux ajouter une ligne de commande de coloration pour Git
-
-Pour configurer la colorisation de ligne de commande automatique de Git afin de faciliter la relecture :
-
-```sh
-$ git config --global color.ui auto
-```
-
 ## Je n'ai aucune idée de ce que j'ai mal fait

 Donc, vous êtes fichu - vous avez `reset` quelque chose, ou vous avez fusionné la mauvaise branche, ou vous avez poussé de force et maintenant vous ne pouvez plus trouver vos commits. Vous savez qu'à un moment donné, tout allait bien, et vous voulez revenir à un état dans lequel vous étiez avant.
@ -1579,21 +1574,21 @@ Donc, vous êtes fichu - vous avez `reset` quelque chose, ou vous avez fusionné
 C'est là qu'intervient `git reflog`. `reflog` garde trace de tous les changements du bout de la branche, même si ce dernier n'est pas référencé par une branche ou un tag. Fondamentalement, chaque fois que le HEAD change, une nouvelle entrée est ajoutée au reflog. Cela marche seulement pour les dépôts locaux, malheureusement, et ne trace que les mouvements (pas les changements d'un fichier qui n'ont été enregistrés nulle part, par exemple).

 ```sh
-(master)$ git reflog
+(main)$ git reflog
 0a2e358 HEAD@{0}: reset: moving to HEAD~2
-0254ea7 HEAD@{1}: checkout: moving from 2.2 to master
-c10f740 HEAD@{2}: checkout: moving from master to 2.2
+0254ea7 HEAD@{1}: checkout: moving from 2.2 to main
+c10f740 HEAD@{2}: checkout: moving from main to 2.2
 ```

-Le `reflog` ci-dessus indique un déplacement depuis master vers la branche 2.2 et l'inverse. À partir de là, il y a un hard `reset` vers un commit plus vieux. La dernière activité est représentée en haut et intitulée `HEAD@{0}`.
+Le `reflog` ci-dessus indique un déplacement depuis main vers la branche 2.2 et l'inverse. À partir de là, il y a un hard `reset` vers un commit plus vieux. La dernière activité est représentée en haut et intitulée `HEAD@{0}`.

-Si il s'avère que vous êtes accidentellement revenu en arrière, le reflog contiendra le commit sur lequel pointait master (0254ea7) avant que vous ne supprimiez 2 commits par accident.
+Si il s'avère que vous êtes accidentellement revenu en arrière, le reflog contiendra le commit sur lequel pointait main (0254ea7) avant que vous ne supprimiez 2 commits par accident.

 ```sh
 $ git reset --hard 0254ea7
 ```

-En utilisant `git reset`, il est ensuite possible de changer master vers le commit vers lequel il pointait. Cela vous donne de la sûreté dans le cas où l'historique a été changé par accident.
+En utilisant `git reset`, il est ensuite possible de changer main vers le commit vers lequel il pointait. Cela vous donne de la sûreté dans le cas où l'historique a été changé par accident.

 (copié et édité depuis [Source](https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog)).

--- a/README_ja.md
+++ b/README_ja.md
--- a/README_kr.md
+++ b/README_kr.md
@ -1,22 +1,22 @@
 # 깃을 위한 flight rules

 🌍
-*[English](README.md) ∙ [Español](README_es.md)  ∙  [Русский](README_ru.md) ∙ [简体中文](README_zh-CN.md)∙ [한국어](README_kr.md)  ∙  [Tiếng Việt](README_vi.md) ∙ [Français](README_fr.md)*
+*[English](README.md) ∙ [Español](README_es.md)  ∙  [Русский](README_ru.md) ∙ [繁體中文](README_zh-TW.md) ∙ [简体中文](README_zh-CN.md) ∙ [한국어](README_kr.md)  ∙  [Tiếng Việt](README_vi.md) ∙ [Français](README_fr.md) ∙ [日本語](README_ja.md)*

 #### flight rules 가 뭐야?

-뭔가 잘못 됐을 때 뭘 해야할지에 대한 우주비행사를 위한 가이드 (여기선 깃을 쓰는 개발자를 위한) 
+뭔가 잘못 됐을 때 뭘 해야할지에 대한 우주비행사를 위한 가이드 (여기선 깃을 쓰는 개발자를 위한)


 >  *Flight Rules* 는 어떤 문제 X가 발생한 이유와 그 단계의 매뉴얼에서 어렵사리 얻은 지식이에요. 기본적으로 각 시나리오의 매우 자세하고 구체적인 운영 절차랍니다. [...]

-> NASA는 수성(Mercury) 시대 때 지상팀에서 처음으로 "lessons learned" 이란 것을 모았는데 수천개의 문제의 상황들, 부서진 해치 손잡이로 인한 엔진 고장부터 컴퓨터 문제 그리고 그 해답까지, 1960년대 초부터 우리의 실수들, 재앙들, 해결책 등이  목록화 돼있어요. 
+> NASA는 수성(Mercury) 시대 때 지상팀에서 처음으로 "lessons learned" 이란 것을 모았는데 수천개의 문제의 상황들, 부서진 해치 손잡이로 인한 엔진 고장부터 컴퓨터 문제 그리고 그 해답까지, 1960년대 초부터 우리의 실수들, 재앙들, 해결책 등이  목록화 돼있어요.

 — Chris Hadfield, *인생을 위한 우주비행사의 가이드*.

 #### 이 문서의 규칙

-명확하게 하기 위해 이 문서의 모든 예제는 현재 브랜치를 표시하고 스테이지에 변경이 있는지를 나타내기 위해 커스텀 된 배시 프롬프트를 써요. 브랜치는 괄호 안에 있고, 브랜치 다음의 *는 스테이지의 변경된 것을 나타내요.  
+명확하게 하기 위해 이 문서의 모든 예제는 현재 브랜치를 표시하고 스테이지에 변경이 있는지를 나타내기 위해 커스텀 된 배시 프롬프트를 써요. 브랜치는 괄호 안에 있고, 브랜치 다음의 *는 스테이지의 변경된 것을 나타내요.

 [![Join the chat at https://gitter.im/k88hudson/git-flight-rules](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/k88hudson/git-flight-rules?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
@ -110,7 +110,6 @@
    - [레파지토리 유저명과 비밀번호를 캐시해두고 싶어](#%EB%A0%88%ED%8C%8C%EC%A7%80%ED%86%A0%EB%A6%AC-%EC%9C%A0%EC%A0%80%EB%AA%85%EA%B3%BC-%EB%B9%84%EB%B0%80%EB%B2%88%ED%98%B8%EB%A5%BC-%EC%BA%90%EC%8B%9C%ED%95%B4%EB%91%90%EA%B3%A0-%EC%8B%B6%EC%96%B4)
    - [깃이 권한과 파일모드 변경을 무시하게 만들고 싶어](#%EA%B9%83%EC%9D%B4-%EA%B6%8C%ED%95%9C%EA%B3%BC-%ED%8C%8C%EC%9D%BC%EB%AA%A8%EB%93%9C-%EB%B3%80%EA%B2%BD%EC%9D%84-%EB%AC%B4%EC%8B%9C%ED%95%98%EA%B2%8C-%EB%A7%8C%EB%93%A4%EA%B3%A0-%EC%8B%B6%EC%96%B4)
    - [글로벌 유저로 설정해두고 싶어](#%EA%B8%80%EB%A1%9C%EB%B2%8C-%EC%9C%A0%EC%A0%80%EB%A1%9C-%EC%84%A4%EC%A0%95%ED%95%B4%EB%91%90%EA%B3%A0-%EC%8B%B6%EC%96%B4)
-    - [깃에 명령어 색상을 넣고 싶어](#%EA%B9%83%EC%97%90-%EB%AA%85%EB%A0%B9%EC%96%B4-%EC%83%89%EC%83%81%EC%9D%84-%EB%84%A3%EA%B3%A0-%EC%8B%B6%EC%96%B4)
  - [뭘 잘못했는지 모르겠어](#%EB%AD%98-%EC%9E%98%EB%AA%BB%ED%96%88%EB%8A%94%EC%A7%80-%EB%AA%A8%EB%A5%B4%EA%B2%A0%EC%96%B4)
 - [다른 리소스](#%EB%8B%A4%EB%A5%B8-%EB%A6%AC%EC%86%8C%EC%8A%A4)
  - [도서](#%EB%8F%84%EC%84%9C)
@ -138,7 +137,7 @@
 $ git clone [url]
 ```

-폴더 이름이 리모트 레파지토리 이름과 같이 저장될 거에요. 
+폴더 이름이 리모트 레파지토리 이름과 같이 저장될 거에요.

 복제할 리모트 서버의 연결을 확인하세요.(대부분 인터넷 연결을 확인하란 뜻이에요)

@ -152,16 +151,15 @@ $ git clone [url] name-of-new-folder

 <a name="diff-last"></a>
 <!-- ### What did I just commit? -->
-
 ### 내가 방금 어떤 커밋을 남겼지?

 `git commit -a` 로 막 커밋을 남기고 내가 뭐라고 안에 적었더라? 한다고 하고. 최근의 커밋을 현재 HEAD에서 볼 수 있어요.

 ```sh
-(master)$ git show
+(main)$ git show
 ```

-또는 
+또는

 ```sh
 $ git log -n1 -p
@ -173,6 +171,7 @@ $ git log -n1 -p
 $ git show <commitid>:filename
 ```

+<a name="wrong-thing-in-commit-message"></a>
 ### 커밋 메세지를 잘못 썼어

 만약 메시지를 잘못 썼고 아직 푸시를 안했다면, 커밋 메시지 바꾸기를 따라해 볼 수 있어요.
@ -198,7 +197,7 @@ $ git commit --amend --only -m 'xxxxxxx'
 $ git commit --amend --no-edit --author "New Authorname <authoremail@mydomain.com>"
 ```

-대안으로는 `git config --global author.(name|email)`에서 설정을 다시 맞춘 다음  
+대안으로는 `git config --global author.(name|email)`에서 설정을 다시 맞춘 다음

 ```sh
 $ git commit --amend --reset-author --no-edit
@ -238,11 +237,11 @@ $ git push --force-with-lease [remote] [branch]
 아직 푸시 안했으면, 리셋으로 마지막 커밋 전 상태로 돌아가요. (변경점은 스테이지에 두고서)

 ```
-(my-branch*)$ git reset --soft HEAD@{1}
+(my-branch)$ git reset --soft HEAD^
 ```

-이 방법은 푸시를 안 했을 때만 동작해요. 푸시를 했으면, 안전한 방법은 `git revert SHAofBadCommit` 한가지 밖이에요. 
-이 방법은 모든 지난 커밋 변경점으로 되돌아간 새 커밋을 만들 거에요. 또는, 만약 푸시한 브랜치가 리베이스에 안전하다면 (만약 다른 사람이 풀 받지 않는다면), `git push --force-with-lease` 명령어를 쓸수 있어요. 
+이 방법은 푸시를 안 했을 때만 동작해요. 푸시를 했으면, 안전한 방법은 `git revert SHAofBadCommit` 한가지 밖이에요.
+이 방법은 모든 지난 커밋 변경점으로 되돌아간 새 커밋을 만들 거에요. 또는, 만약 푸시한 브랜치가 리베이스에 안전하다면 (만약 다른 사람이 풀 받지 않는다면), `git push --force-with-lease` 명령어를 쓸수 있어요.
 더 알고 싶다면, [이 섹션](#deleteremove-last-pushed-commit)을 참고해주세요.

 <a name="delete-any-commit"></a>
@ -257,7 +256,7 @@ $ git push --force-with-lease [remote] [branch]

 아니면 [대화형 리베이스](#interactive-rebase)를 쓰고 지우고 싶은 커밋 라인을 지워도 돼요.

-<a name="#force-push"></a>
+<a name="force-push"></a>
 ### 수정된 커밋을 푸시했는데, 에러 메세지가 떠

 ```sh
@ -279,50 +278,50 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.
 ```

 일반적으로 강제 푸시를 쓰지 마세요.
-새 커밋을 만들어서 푸시하는게 수정된 커밋을 강제로 푸시하는 것보다 훨씬 나아요. 그런 수정된 커밋은 그 브랜치나 다른 자식 브랜치를 쓰는 다른 개발자의 소스 이력과 충돌의 원인이 될거에요. 
+새 커밋을 만들어서 푸시하는게 수정된 커밋을 강제로 푸시하는 것보다 훨씬 나아요. 그런 수정된 커밋은 그 브랜치나 다른 자식 브랜치를 쓰는 다른 개발자의 소스 이력과 충돌의 원인이 될거에요.
 `--force-with-lease` 는 여전히 실패할텐데, 누군가가 같은 브랜치를 쓴다면 변경점을 덮어쓰는 푸시를 할 수도 있어요.

 절대로 아무도 같은 브랜치를 안 쓰거나, 절대로 브랜치에 업데이트를 해야할때 `--force` (`-f`) 옵션을 쓸 수 있지만 일반적으론 피하는게 좋아요.

-<a href="undo-git-reset-hard"></a>
+<a name="undo-git-reset-hard"></a>
 ### 하드 리셋을 해버렸는데 되돌리고 싶어

-만약 하드 리셋을 했다고 해도 커밋을 돌릴 순 있어요. 깃은 며칠간은 로그를 가지고 있거든요. 
+만약 하드 리셋을 했다고 해도 커밋을 돌릴 순 있어요. 깃은 며칠간은 로그를 가지고 있거든요.

 알아두기 : 이건 커밋을 남겼거나 스테이시같이 백업을 했을 때만 유효해요. `git reset --hard` 은 커밋되지 않은 수정사항을 _다 지울 거에요_, 그러니 조심해서 써야해요. (안전한 방법으론 `git reset --keep` 이 있어요)

 ```sh
-(master)$ git reflog
+(main)$ git reflog
 ```

-지난 커밋과 리셋을 위한 커밋을 볼 수 있을 거에요. 돌아가고 싶은 커밋의 SHA 코드를 골라서, 리셋을 해요:   
+지난 커밋과 리셋을 위한 커밋을 볼 수 있을 거에요. 돌아가고 싶은 커밋의 SHA 코드를 골라서, 리셋을 해요:

 ```sh
-(master)$ git reset --hard SHA1234
+(main)$ git reset --hard SHA1234
 ```

 계속 할 수 있을거에요.

-<a href="undo-a-commit-merge"></a>
+<a name="undo-a-commit-merge"></a>
 ### 머지를 실수로 커밋, 푸시해버렸어

 만약 실수로 머지할 준비가 안된 피쳐 브랜치를 메인 브랜치에 머지했어도 되돌릴 순 있어요.
 하지만 문제는 있어요: 머지 커밋은 한개 이상의 부모(보통은 두 개)를 가지게 돼요.
- 
+
 사용하려면

 ```sh
 (feature-branch)$ git revert -m 1 <commit>
 ```

-여기서 -m 1 옵션은 부모 번호 1(머지가 만들어진 브랜치)을 되돌릴 상위 항목으로 선택하라고 해요. 
+여기서 -m 1 옵션은 부모 번호 1(머지가 만들어진 브랜치)을 되돌릴 상위 항목으로 선택하라고 해요.

 알아두기 : 부모 번호는 커밋 식별자가 아니고, 오히려 머지된 커밋이 `Merge: 8e2ce2d 86ac2e7` 이라는 라인을 가지고 있어요.
 부모 번호는 이 라인에서 원하는 부모의 1 기반 인덱스이고, 첫번째 식별자는 1, 다음은 2 이렇게 이어져요.

 ## 스테이지

-<a href="#i-need-to-add-staged-changes-to-the-previous-commit"></a>
+<a name="add-staged-changes-to-previous-commit"></a>
 ### 지난 커밋에 스테이지 변경점을 추가하고 싶어

 ```sh
@ -332,7 +331,7 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.
 <a name="commit-partial-new-file"></a>
 ### 전체가 아닌 새 파일만 스테이지에 올리고 싶어

-보통은 부분적으로 파일을 스테이지하려면 이렇게 해요: 
+보통은 부분적으로 파일을 스테이지하려면 이렇게 해요:

 ```sh
 $ git add --patch filename.x
@ -346,15 +345,15 @@ $ git add -N filename.x

 그 다음 임의적으로 라인들을 골라 추가해주려면 `e`옵션이 필요할거에요. `git diff --cached`나 `git diff --staged`는 로컬에 저장된 부분과 스테이지에 있는 라인들을 비교해서 보여줄 거에요.

-<a href="stage-in-two-commits"></a>
+<a name="stage-in-two-commits"></a>
 ### 하나의 파일 변경점을 두개의 다른 커밋에 남기고 싶어

 `git add`는 전체 파일들을 커밋에 추가해요. `git add -p`는 대화형으로 추가하고픈 변경점들을 고를 수 있어요.

-<a href="unstaging-edits-and-staging-the-unstaged"></a>
+<a name="unstaging-edits-and-staging-the-unstaged"></a>
 ### 아직 스테이지에 안 올라간 변경점을 스테이지에 추가하고, 스테이지에 있는 변경점을 다시 빼고 싶어

-이건 좀 꼼수인데요, 스테이지 전인 파일들을 스테이시해서 빼두고선 리셋 할 수 있을거에요. 그 다음 스테이시를 다시 불러와 추가를 해요. 
+이건 좀 꼼수인데요, 스테이지 전인 파일들을 스테이시해서 빼두고선 리셋 할 수 있을거에요. 그 다음 스테이시를 다시 불러와 추가를 해요.

 ```sh
 $ git stash -k
@ -365,14 +364,14 @@ $ git add -A

 ## 스테이지 전의 변경점

-<a href="move-unstaged-edits-to-new-branch"></a>
+<a name="move-unstaged-edits-to-new-branch"></a>
 ### 스테이지 전의 변경점을 새 브랜치로 옮기고 싶어

 ```sh
 $ git checkout -b my-branch
 ```

-<a href="move-unstaged-edits-to-old-branch"></a>
+<a name="move-unstaged-edits-to-old-branch"></a>
 ### 스테이지전 변경점을 만들어둔 다른 브랜치로 옮기고 싶어

 ```sh
@ -381,7 +380,7 @@ $ git checkout my-branch
 $ git stash pop
 ```

-<a href="i-want-to-discard-my-local-uncommitted-changes"></a>
+<a name="discard-local-uncommitted-changes"></a>
 ### 내 로컬에 있는 커밋 안된 변경점을 다 무시하고 싶어 (스테이징 됐던 안됐던)

 만약 모든 스테이징 됐거나 안 된 변경점을 버리고 싶다면 이렇게 해요:
@ -389,10 +388,10 @@ $ git stash pop
 ```sh
 (my-branch)$ git reset --hard
 # or
-(master)$ git checkout -f
+(main)$ git checkout -f
 ```

-이 방법은 `git add`로 스테이징된 모든 파일이 빠지게 돼요. 
+이 방법은 `git add`로 스테이징된 모든 파일이 빠지게 돼요.

 ```sh
 $ git reset
@ -431,10 +430,10 @@ $ git clean -fd

 ```sh
 $ git checkout -p
-# 날리고 싶은 사항에 y를 적으세요 
+# 날리고 싶은 사항에 y를 적으세요
 ```

-또다른 전략은 `stash`을 같이 쓰는거에요. 챙겨야 하는 변경점을 스테이시 하고, 작업 중인 영역을 리셋하고, 다시 올바른 변경점으로 재적용해요.   
+또다른 전략은 `stash`을 같이 쓰는거에요. 챙겨야 하는 변경점을 스테이시 하고, 작업 중인 영역을 리셋하고, 다시 올바른 변경점으로 재적용해요.

 ```sh
 $ git stash -p
@ -473,10 +472,10 @@ $ git checkout myFirstFile mySecondFile
 $ git checkout .
 ```

-<a href="i-want-to-discard-all-my-untracked-files"></a>
+<a name="discard-all-untracked-files"></a>
 ### 트래킹 안된 파일들 다 지우고 싶어

-트래킹 안된 파일들 다 지우고 싶을 땐 
+트래킹 안된 파일들 다 지우고 싶을 땐

 ```sh
 $ git clean -f
@ -484,7 +483,7 @@ $ git clean -f

 ## 브랜치

-### 모든 브랜치 리스트를 보고 싶어 
+### 모든 브랜치 리스트를 보고 싶어

 로컬 브랜치 다 보기

@ -492,7 +491,7 @@ $ git clean -f
 $ git branch
 ```

-리모트 브랜치 다 보기  
+리모트 브랜치 다 보기

 ```sh
 $ git branch -r
@ -517,12 +516,12 @@ $ git checkout -b <branch> <SHA1_OF_COMMIT>
 이건 잘못된 풀을 받기전 HEAD가 어딜 가르키고 있었는지 볼 수 있는 `git reflog`를 써볼 수 있는 기회에요.

 ```sh
-(master)$ git reflog
+(main)$ git reflog
 ab7555f HEAD@{0}: pull origin wrong-branch: Fast-forward
 c5bc55a HEAD@{1}: checkout: checkout message goes here
 ```

-간단히 원하는 커밋으로 브랜치를 되돌릴 수 있어요: 
+간단히 원하는 커밋으로 브랜치를 되돌릴 수 있어요:

 ```sh
 $ git reset --hard c5bc55a
@ -530,12 +529,12 @@ $ git reset --hard c5bc55a

 끝!

-<a href="discard-local-commits"></a>
+<a name="discard-local-commits"></a>
 ### 로컬의 커밋을 지워서 서버에 있는 내 브랜치와 맞추고 싶어

 서버에 변경점을 푸시 안했는지부터 확인해요.

-`git status` 가 오리진보다 몇개의 커밋들이 앞서 있는지 보여줄거에요: 
+`git status` 가 오리진보다 몇개의 커밋들이 앞서 있는지 보여줄거에요:

 ```sh
 (my-branch)$ git status
@ -548,7 +547,7 @@ $ git reset --hard c5bc55a
 오리진(리모트과 같은 상태의)로 맞추는 리셋을 하는 방법 중 하나는:

 ```sh
-(master)$ git reset --hard origin/my-branch
+(my-branch)$ git reset --hard origin/my-branch
 ```

 <a name="commit-wrong-branch"></a>
@ -557,17 +556,17 @@ $ git reset --hard c5bc55a
 마스터에 있으면서 새 브랜치를 만들어요:

 ```sh
-(master)$ git branch my-branch
+(main)$ git branch my-branch
 ```

 마스터 브랜치를 기존 커밋으로 리셋해요:


 ```sh
-(master)$ git reset --hard HEAD^
+(main)$ git reset --hard HEAD^
 ```

-`HEAD^`는 `HEAD^1`의 축약인데요. `HEAD^`의 첫번째 부모를 의미하고, 비슷한 `HEAD^2`는 두번째 부모를 의미해요. (머지는 두 부모를 가질 수 있죠) 
+`HEAD^`는 `HEAD^1`의 축약인데요. `HEAD^`의 첫번째 부모를 의미하고, 비슷한 `HEAD^2`는 두번째 부모를 의미해요. (머지는 두 부모를 가질 수 있죠)

 알아두세요 `HEAD^2`는 `HEAD~2`과 같은게 아니에요. (더 자세한 정보는 [이 링크](http://www.paulboxley.com/blog/2011/06/git-caret-and-tilde)를 참고해요 )

@ -576,18 +575,18 @@ $ git reset --hard c5bc55a
 예를 들자면, 그 마스터의 커밋의 해쉬가 `a13b85e`라면:

 ```sh
-(master)$ git reset --hard a13b85e
+(main)$ git reset --hard a13b85e
 HEAD is now at a13b85e
 ```

 새 브랜치로 체크아웃 해서 계속 작업을 해요:

 ```sh
-(master)$ git checkout my-branch
+(main)$ git checkout my-branch
 ```

 <a name="keep-whole-file"></a>
-### 다른 레퍼런스 같은 곳에서 모든 파일을 유지하고 싶어 
+### 다른 레퍼런스 같은 곳에서 모든 파일을 유지하고 싶어

 수백번의 변경점을 가진 스파이크(아래 알아두기 참고) 작업을 한다고 가정해보죠. 모든 건 동작하고 있고,그 작업을 저장해두기 위해  다른 브랜치로 커밋을 해요:

@ -621,7 +620,7 @@ HEAD is now at a13b85e

 그 다음, 평소처럼 커밋해요.

-알아두기 : 스파이크 솔루션은 문제를 분석하거나 풀기위해 만들어졌어요. 이 솔루션들은 모두가 문제의 확실한 시각화를 얻고선 평가되고 제거돼요.~ [위키피디아](https://en.wikipedia.org/wiki/Extreme_programming_practices).   
+알아두기 : 스파이크 솔루션은 문제를 분석하거나 풀기위해 만들어졌어요. 이 솔루션들은 모두가 문제의 확실한 시각화를 얻고선 평가되고 제거돼요.~ [위키피디아](https://en.wikipedia.org/wiki/Extreme_programming_practices).

 <a name="cherry-pick"></a>
 ### 한 브랜치에 다른 브랜치에 남겼어야 하는 커밋을 여러개 남겼어
@ -629,7 +628,7 @@ HEAD is now at a13b85e
 마스터 브랜치에 있다고 가정하고 `git log` 해보면 커밋 두개 볼 수 있을거에요:

 ```sh
-(master)$ git log
+(main)$ git log

 commit e3851e817c451cc36f2e6f3049db528415e3c114
 Author: Alex Lee <alexlee@example.com>
@ -655,14 +654,14 @@ Date:   Tue Jul 21 01:12:48 2014 -0400
 우선, 마스터 브랜치의 정확한 커밋 (`a13b85e`)으로 리셋해요:

 ```sh
-(master)$ git reset --hard a13b85e
+(main)$ git reset --hard a13b85e
 HEAD is now at a13b85e
 ```

 그리고, 21번 버그 작업을 위한 새로운 브랜치를 만들수 있어요:

 ```sh
-(master)$ git checkout -b 21
+(main)$ git checkout -b 21
 (21)$
 ```

@ -673,17 +672,17 @@ HEAD is now at a13b85e
 ```

 이 지점에서 충돌이 있을 수도 있어요.
-어떻게 충돌을 해결할지 [대화형 리베이스 섹션](#interactive-rebase) 안에 있는 [**충돌이 있어**](#merge-conflict) 부분을 참고하세요.  
+어떻게 충돌을 해결할지 [대화형 리베이스 섹션](#interactive-rebase) 안에 있는 [**충돌이 있어**](#merge-conflict) 부분을 참고하세요.

 자 이제 14번 버그 작업을 위해 마스터로 가서 새 브랜치를 만들어요.

 ```sh
-(21)$ git checkout master
-(master)$ git checkout -b 14
+(21)$ git checkout main
+(main)$ git checkout -b 14
 (14)$
 ```

-그리고 마지막으로, 14번 버그작업을 위한 커밋을 체리픽해요. 
+그리고 마지막으로, 14번 버그작업을 위한 커밋을 체리픽해요.

 ```sh
 (14)$ git cherry-pick 5ea5173
@ -701,13 +700,13 @@ $ git fetch -p upstream

 여기서, `upstream`은 패치로 가져오려는 리모트 레파지토리에요.

-<a name='restore-a-deleted-branch'></a>
+<a name="restore-a-deleted-branch"></a>
 ### 브랜치를 지워버렸어

 주기적으로 리모트으로 푸시한다면, 대부분은 안전해야 해요. 그치만 가끔은 브랜치를 지울 수 있어요. 새 브랜치를 만들고 파일을 하나 만들었다고 해보죠:

 ```sh
-(master)$ git checkout -b my-branch
+(main)$ git checkout -b my-branch
 (my-branch)$ git branch
 (my-branch)$ touch foo.txt
 (my-branch)$ ls
@ -740,28 +739,28 @@ Date:   Tue Jul 29 13:14:46 2014 -0400
 이제 다시 마스터로 돌아가 '실수로' 브랜치를 지워보죠.

 ```sh
-(my-branch)$ git checkout master
-Switched to branch 'master'
-Your branch is up-to-date with 'origin/master'.
-(master)$ git branch -D my-branch
+(my-branch)$ git checkout main
+Switched to branch 'main'
+Your branch is up-to-date with 'origin/main'.
+(main)$ git branch -D my-branch
 Deleted branch my-branch (was 4e3cd85).
-(master)$ echo oh noes, deleted my branch!
+(main)$ echo oh noes, deleted my branch!
 oh noes, deleted my branch!
 ```

 여기에서 업그레이드된 로그 도구인 '리플로그'에 익숙해져야 해요. 리플로그는 레파지토리의 모든 행동의 이력을 다 보관해요.

 ```
-(master)$ git reflog
-69204cd HEAD@{0}: checkout: moving from my-branch to master
+(main)$ git reflog
+69204cd HEAD@{0}: checkout: moving from my-branch to main
 4e3cd85 HEAD@{1}: commit: foo.txt added
-69204cd HEAD@{2}: checkout: moving from master to my-branch
+69204cd HEAD@{2}: checkout: moving from main to my-branch
 ```

 보시다시피 지워진 브랜치의 커밋 해쉬도 볼 수 있어요. 지웠던 브랜치를 살릴 수 있는 지 한번 해보죠.

 ```sh
-(master)$ git checkout -b my-branch-help
+(main)$ git checkout -b my-branch-help
 Switched to a new branch 'my-branch-help'
 (my-branch-help)$ git reset --hard 4e3cd85
 HEAD is now at 4e3cd85 foo.txt added
@ -776,25 +775,25 @@ README.md foo.txt
 리모트 브랜치를 삭제하려면:

 ```sh
-(master)$ git push origin --delete my-branch
+(main)$ git push origin --delete my-branch
 ```

 이렇게도:

 ```sh
-(master)$ git push origin :my-branch
+(main)$ git push origin :my-branch
 ```

 로컬 브랜치를 삭제하려면:

 ```sh
-(master)$ git branch -d my-branch
+(main)$ git branch -d my-branch
 ```

 현재 브랜치나 업스트림에 머지되지 않은 로컬 브랜치를 지우려면:

 ```sh
-(master)$ git branch -D my-branch
+(main)$ git branch -D my-branch
 ```

 ### 여러개의 브랜치를 지우고 싶어
@ -802,7 +801,7 @@ README.md foo.txt
 `fix/`로 시작하는 모든 브랜치들을 지우고 싶다면:

 ```sh
-(master)$ git branch | grep 'fix/' | xargs git branch -d
+(main)$ git branch | grep 'fix/' | xargs git branch -d
 ```

 ### 브랜치 이름을 바꾸고 싶어
@ -810,28 +809,28 @@ README.md foo.txt
 현재 (로컬) 브랜치 이름을 바꾸려면:

 ```sh
-(master)$ git branch -m new-name
+(main)$ git branch -m new-name
 ```

 다른 (로컬) 브랜치 이름을 바꾸려면

 ```sh
-(master)$ git branch -m old-name new-name
+(main)$ git branch -m old-name new-name
 ```

-<a name="i-want-to-checkout-to-a-remote-branch-that-someone-else-is-working-on"></a>
+<a name="working-on-checkout-remote-branch"></a>
 ### 다른 사람이 작업중인 리모트 브랜치로 체크아웃 하고 싶어

-우선, 리모트 레파지토리에서 모든 브랜치를 패치 받아요: 
+우선, 리모트 레파지토리에서 모든 브랜치를 패치 받아요:

 ```sh
-(master)$ git fetch --all
+(main)$ git fetch --all
 ```

 리모트의 `daves`로 체크아웃 하고 싶다고 하면.

 ```sh
-(master)$ git checkout --track origin/daves
+(main)$ git checkout --track origin/daves
 Branch daves set up to track remote branch daves from origin.
 Switched to a new branch 'daves'
 ```
@ -859,7 +858,7 @@ $ git push -u <remote> HEAD
 $ git push
 ```

-`git push`의 다른 모드의 동작은 [`push.default` 문서](https://git-scm.com/docs/git-config#git-config-pushdefault)에 설명돼 있어요.
+`git push`의 다른 모드의 동작은 [`push.default` 문서](https://git-scm.com/docs/git-config#Documentation/git-config.txt-pushdefault)에 설명돼 있어요.

 ### 리모트 브랜치를 로컬 브랜치를 위한 업스트림으로 설정하고 싶어

@ -877,8 +876,7 @@ $ git branch -u [remotename]/[branch]
 $ git branch -u [remotename]/[branch] [local-branch]
 ```

-<a name="i-want-to-set-my-HEAD-to-track-the-default-remote-branch"></a>
-
+<a name="head-to-track-remote-branch"></a>
 ### HEAD를 기본 리모트 브랜치로 트래킹하도록 설정하고 싶어

 리모트 브랜치를 확인해보는 것으로, HEAD가 트래킹 중인 리모트 브랜치를 볼 수 있어요. 몇몇 경우에는, 원하던 브랜치가 아닐거에요.
@ -886,14 +884,14 @@ $ git branch -u [remotename]/[branch] [local-branch]
 ```sh
 $ git branch -r
  origin/HEAD -> origin/gh-pages
-  origin/master
+  origin/main
 ```

-`origin/HEAD`를 `origin/master`를 트래킹하는 것으로 변경하려면, 이 커맨드로 실행할 수 있어요:
+`origin/HEAD`를 `origin/main`를 트래킹하는 것으로 변경하려면, 이 커맨드로 실행할 수 있어요:

 ```sh
 $ git remote set-head origin --auto
-origin/HEAD set to master
+origin/HEAD set to main
 ```

 ### 다른 브랜치에 변경점을 잘못 남겼어
@ -925,14 +923,14 @@ origin/HEAD set to master
 리모트 브랜치는 강제 푸시 외엔 적용 해주지 않을거에요.
 많은 분들이 머지 워크플로우를 리베이스 워크플로우보다 선호하는 많이 이유 중 하나죠 - 큰 팀에선 개발자의 강제 푸시로 곤란해질 수 있어요.
 주의해서 쓰세요.
-리베이스를 그나마 안전하게 쓰는 방법은 리모트 브랜치의 모든 변경점과 똑같이 반영하는게 아니라 대신에 이렇게 해봐요:  
+리베이스를 그나마 안전하게 쓰는 방법은 리모트 브랜치의 모든 변경점과 똑같이 반영하는게 아니라 대신에 이렇게 해봐요:


 ```sh
-(master)$ git checkout my-branch
-(my-branch)$ git rebase -i master
-(my-branch)$ git checkout master
-(master)$ git merge --ff-only my-branch
+(main)$ git checkout my-branch
+(my-branch)$ git rebase -i main
+(my-branch)$ git checkout main
+(main)$ git merge --ff-only my-branch
 ```

 더 확인이 필요하다면, [이 스택오버플로우의 쓰레드](https://stackoverflow.com/questions/11058312/how-can-i-use-git-rebase-without-requiring-a-forced-push)를 참고해요.
@ -941,26 +939,26 @@ origin/HEAD set to master
 <a name="interactive-rebase"></a>
 ### 커밋끼리 합치고 싶어

-`master`에 풀 리퀘스트가 될 브랜치에서 작업하고 있다고 가정해봐요.
+`main`에 풀 리퀘스트가 될 브랜치에서 작업하고 있다고 가정해봐요.
 가장 간단한 경우는 원하는게 *모든* 커밋을 하나의 커밋으로 합치고 변경점의 시간을 신경쓰지 않아도 되는 것일 때, 리셋하고 커밋 다시하면 돼요.
 마스터 브랜치가 최신이고 모든 변경점이 커밋된 것만 확인한 다음:

 ```sh
-(my-branch)$ git reset --soft master
+(my-branch)$ git reset --soft main
 (my-branch)$ git commit -am "New awesome feature"
 ```

 좀더 조정하고, 시간기록까지 보관하고 싶다면, 대화형 리베이스가 필요할거에요.

 ```sh
-(my-branch)$ git rebase -i master
+(my-branch)$ git rebase -i main
 ```

 만약 다른 브랜치로 붙는 작업을 하는게 아니라면, `HEAD`을 기준으로 리베이스 해야해요.
 예로 마지막 2개의 커밋을 스쿼시(기존 커밋에 반영해넣는)하고 싶다면 `HEAD~2`로 리베이스 해요. 3개라면 `HEAD~3`으로 하구요.

 ```sh
-(master)$ git rebase -i HEAD~2
+(main)$ git rebase -i HEAD~2
 ```

 대화형 리베이스를 실행하면 텍스트 에디터로 이런 것들을 볼 수 있을거에요.
@ -990,11 +988,11 @@ pick e3851e8 another fix
 # Note that empty commits are commented out
 ```

-모든 `#`으로 시작하는 주석줄은 리베이스에 영향을 주진 않아요. 
+모든 `#`으로 시작하는 주석줄은 리베이스에 영향을 주진 않아요.

 다음으로 `pick` 부분을 다른 명령어로 바꾸거나, 해당하는 라인을 지워서 커밋을 지울 수도 있어요.

-예를 들자면 **오래된 (첫번째) 커밋만 두고 두번째 오래된 커밋과 나머지를 다 합치고 싶을때**, 첫번째와 두번째 커밋 제외한 나머지 커맨드들을 `f`로 바꿔야 할거에요:  
+예를 들자면 **오래된 (첫번째) 커밋만 두고 두번째 오래된 커밋과 나머지를 다 합치고 싶을때**, 첫번째와 두번째 커밋 제외한 나머지 커맨드들을 `f`로 바꿔야 할거에요:

 ```vim
 pick a9c8a1d Some refactoring
@ -1020,7 +1018,7 @@ Newer, awesomer features
 # Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
 # rebase in progress; onto 8074d12
-# You are currently editing a commit while rebasing branch 'master' on '8074d12'.
+# You are currently editing a commit while rebasing branch 'main' on '8074d12'.
 #
 # Changes to be committed:
 #   modified:   README.md
@ -1030,7 +1028,7 @@ Newer, awesomer features
 전부 다 성공하면, 이런 메세지를 볼거에요:

 ```sh
-(master)$ Successfully rebased and updated refs/heads/master.
+(main)$ Successfully rebased and updated refs/heads/main.
 ```

 #### 안전한 머지 전략
@ -1040,13 +1038,13 @@ Newer, awesomer features


 ```sh
-(master)$ git merge --no-ff --no-commit my-branch
+(main)$ git merge --no-ff --no-commit my-branch
 ```

-#### 브랜치를 커밋 하나로 머지해야해 
+#### 브랜치를 커밋 하나로 머지해야해

 ```sh
-(master)$ git merge --squash my-branch
+(main)$ git merge --squash my-branch
 ```

 <a name="rebase-unpushed-commits"></a>
@ -1056,10 +1054,10 @@ Newer, awesomer features
 다른 누군가가 벌써 참고해서 커밋을 만들고 있을테니 이미 푸시된 커밋을 잘못 합치길 바라진 않을거에요.

 ```sh
-(master)$ git rebase -i @{u}
+(main)$ git rebase -i @{u}
 ```

-이 명령은 아직 푸시하지 않은 커밋만으로 대화형 리베이스를 실행해요. 그러니 목록 내에 있는 어떤 커밋이든 재정렬/수정/합치기 안전해요. 
+이 명령은 아직 푸시하지 않은 커밋만으로 대화형 리베이스를 실행해요. 그러니 목록 내에 있는 어떤 커밋이든 재정렬/수정/합치기 안전해요.

 #### 머지를 중단해야해

@ -1076,13 +1074,13 @@ Newer, awesomer features
 브랜치 내 모든 커밋이 다른 브랜치로 머지됐는지 확인하려면, 그 브랜치들 HEAD (또는 특정 커밋)를 비교해야해요:

 ```sh
-(master)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll
+(main)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll
 ```

 이 명령은 어디에는 있고 다른덴 없는 커밋이 있나를 알려줄거에요 그리고 브랜치들 사이에 공유되지 않은게 목록을 보여줄 거구요. 다른 옵션은 이렇게:

 ```sh
-(master)$ git log master ^feature/120-on-scroll --no-merges
+(main)$ git log main ^feature/120-on-scroll --no-merges
 ```

 ### 대화형 리베이스로 발생가능한 이슈
@ -1102,12 +1100,11 @@ noop
 * 대신해서 `HEAD~2` 또는 더 기존 항목을 리베이스

 <a name="merge-conflict"></a>
-
 #### 충돌이 있어

 리베이스를 똑바로 끝내지 못했다면, 충돌을 해결해야 할거에요.

-어떤 파일이 충돌났는지 `git status`를 먼저 실행해봐요: 
+어떤 파일이 충돌났는지 `git status`를 먼저 실행해봐요:

 ```sh
 (my-branch)$ git status
@ -1134,16 +1131,16 @@ Changes not staged for commit:
 어느 한쪽 브랜치의 코드를 남기고 싶다면, `--ours` 또는 `--theirs`를 쓰면 돼요:

 ```sh
-(master*)$ git checkout --ours README.md
+(main*)$ git checkout --ours README.md
 ```

 - *머지*할때, `--ours`를 쓰면 로컬 브랜치의 변경점 유지하고, `--theirs` 는 다른 브랜치의 변경점를 유지해요.
- *리베이스*할 땐, `--theirs`가 로컬 브랜치의 변경점을 유지하고 `--ours`는 다른 브랜치의 변경점을 유지해요. 이런 차이에 관한 설명은 Git 정식 문서 중 [이 문서](https://git-scm.com/docs/git-rebase#git-rebase---merge)를 보세요. 
+- *리베이스*할 땐, `--theirs`가 로컬 브랜치의 변경점을 유지하고 `--ours`는 다른 브랜치의 변경점을 유지해요. 이런 차이에 관한 설명은 Git 정식 문서 중 [이 문서](https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---merge)를 보세요.

 만약 머지가 더 복잡하면, 비주얼 디프 에디터를 쓸 수도 있어요:

 ```sh
-(master*)$ git mergetool -t opendiff
+(main*)$ git mergetool -t opendiff
 ```

 코드의 충돌을 해결하고 테스트가 해결되고 나면, 바뀐 파일 내용을 `git add` 해주고, `git rebase --continue`로 리베이스를 이어서 해요.
@ -1155,7 +1152,7 @@ Changes not staged for commit:

 만약 모든 충돌을 개선한 내용이 커밋 전과 동일한 트리 구조를 가진다면, 대신에 `git rebase --skip`를 해야 해요.

-리베이스 중 멈추고 싶은 어떤 시점이거나 원래 상태의 브랜치로 돌아가고 싶다면, 이렇게 할 수 있어요:  
+리베이스 중 멈추고 싶은 어떤 시점이거나 원래 상태의 브랜치로 돌아가고 싶다면, 이렇게 할 수 있어요:

 ```sh
 (my-branch)$ git rebase --abort
@ -1200,7 +1197,7 @@ $ git stash save <message>
 ```

 <a name="stash-apply-specific"></a>
-### 특정 스테이시 목록에서 가져와 적용하기 
+### 특정 스테이시 목록에서 가져와 적용하기

 메세지 작성된 스테이시 리스트 먼저 확인하세요

@ -1235,7 +1232,7 @@ $ git log -S "string to find"

 * `--reverse` 반대의 순서로 출력해요, 변경점의 첫번째 커밋이 보일꺼란 거죠.

-<a name="i-want-to-find-by-author-committer"></a>
+<a name="find-by-committer"></a>
 ### 작성자나 커미터를 찾고 싶어

 작성자나 커미터의 모든 커밋을 찾으려면 이렇게 쓸 수 있어요:
@ -1263,7 +1260,7 @@ $ git log -- <path to file>
 $ git log -- **/*.js
 ```

-와일드 카드를 쓸 때, 커밋된 파일의 목록을 볼 수 있는 `--name-status`로 확인하는게 유용할거에요: 
+와일드 카드를 쓸 때, 커밋된 파일의 목록을 볼 수 있는 `--name-status`로 확인하는게 유용할거에요:

 ```sh
 $ git log --name-status -- **/*.js
@ -1280,7 +1277,6 @@ $ git tag --contains <commitid>
 ## 서브모듈

 <a name="clone-submodules"></a>
-
 ### 모든 서브모듈을 클론하기

 ```sh
@ -1315,7 +1311,7 @@ $ rm -rf .git/modules/submodulename
 $ git rev-list -n 1 HEAD -- filename
 ```

-그런 다음 그 파일을 체크아웃해요 
+그런 다음 그 파일을 체크아웃해요

 ```
 git checkout deletingcommitid^ -- filename
@ -1362,31 +1358,31 @@ From github.com:foo/bar
 ### Zip파일로 레파지토리 추출하기

 ```sh
-$ git archive --format zip --output /full/path/to/zipfile.zip master
+$ git archive --format zip --output /full/path/to/zipfile.zip main
 ```

 ## 파일 추적하기

-<a href="i-want-to-change-a-file-names-capitalization-without-changing-the-contents-of-the-file"></a>
+<a name="change-file-name-capitalization-without-changing-contents"></a>

 ### 파일 내용엔 변경이 없이 파일 이름을 앞글자만 대문자로 바꾸고 싶어

 ```sh
-(master)$ git mv --force myfile MyFile
+(main)$ git mv --force myfile MyFile
 ```

 ### 깃 풀 받을때 로컬 파일을 덮어씌우고 싶어

 ```sh
-(master)$ git fetch --all
-(master)$ git reset --hard origin/master
+(main)$ git fetch --all
+(main)$ git reset --hard origin/main
 ```

-<a href="remove-from-git"></a>
+<a name="remove-from-git"></a>
 ### 파일을 로컬에는 보관하고 깃에서 지우고 싶어

 ```sh
-(master)$ git rm --cached log.txt
+(main)$ git rm --cached log.txt
 ```

 ### 특정한 버전대로 파일을 복구하고 싶어
@ -1394,13 +1390,13 @@ $ git archive --format zip --output /full/path/to/zipfile.zip master
 복구하고 싶은 해시가 c5f567 이라고 가정하면:

 ```sh
-(master)$ git checkout c5f567 -- file1/to/restore file2/to/restore
+(main)$ git checkout c5f567 -- file1/to/restore file2/to/restore
 ```

 c5f567 한 단계전으로 복구하고 싶다면, c5f567~1로 적어줘요:

 ```sh
-(master)$ git checkout c5f567~1 -- file1/to/restore file2/to/restore
+(main)$ git checkout c5f567~1 -- file1/to/restore file2/to/restore
 ```

 ### 커밋과 브랜치 간의 특정 파일 변경 이력이 필요해
@ -1410,19 +1406,23 @@ c5f567 한 단계전으로 복구하고 싶다면, c5f567~1로 적어줘요:

 ```sh
 $ git diff HEAD:path_to_file/file c5f567:path_to_file/file
+# 아니면 짧게:
+$ git diff HEAD c5f567 -- path_to_file/file
 ```

 브랜치도 같은 방법으로:

 ```sh
-$ git diff master:path_to_file/file staging:path_to_file/file
+$ git diff main:path_to_file/file staging:path_to_file/file
+# 아니면 짧게:
+$ git diff main staging -- path_to_file/file
 ```

 ## 설정

 ### 깃 명령어 몇 개를 앨리어스 등록하고 싶어

-맥OS나 리눅스에는, 깃 설정 파일이 ```~/.gitconfig``` 에 있어요. 단축용으로 (몇개는 평소 쓰는 용도로) 앨리어스 몇개를 아래와 같이 계속 추가해오고 있어요. 
+맥OS나 리눅스에는, 깃 설정 파일이 ```~/.gitconfig``` 에 있어요. 단축용으로 (몇개는 평소 쓰는 용도로) 앨리어스 몇개를 아래와 같이 계속 추가해오고 있어요.

 ```vim
 [alias]
@ -1449,7 +1449,7 @@ $ git diff master:path_to_file/file staging:path_to_file/file

 ### 레파지토리에 빈 디렉토리를 추가하고 싶어

-못해요! 깃은 지원하지 않거든요, 근데 꼼수가 있어요. 디렉토리에에 .gitignore 파일을 아래 내용으로 만들어요:  
+못해요! 깃은 지원하지 않거든요, 근데 꼼수가 있어요. 디렉토리에에 .gitignore 파일을 아래 내용으로 만들어요:

 ```
 # Ignore everything in this directory
@ -1483,13 +1483,13 @@ $ git config --global credential.helper 'cache --timeout=3600'
 # Set the cache to timeout after 1 hour (setting is in seconds)
 ```

-### 깃이 권한과 파일모드 변경을 무시하게 만들고 싶어   
+### 깃이 권한과 파일모드 변경을 무시하게 만들고 싶어

 ```sh
 $ git config core.fileMode false
 ```

-이 것을 로그인된 유저의 기본 행위로 설정으로 해두려면, 이렇게 써요: 
+이 것을 로그인된 유저의 기본 행위로 설정으로 해두려면, 이렇게 써요:

 ```sh
 $ git config --global core.fileMode false
@ -1497,7 +1497,7 @@ $ git config --global core.fileMode false

 ### 글로벌 유저로 설정해두고 싶어

-모든 로컬 레파지토리에 사용되는 유저 정보를 설정하려면, 그리고 버전 이력을 리뷰할때 알아보기 쉬운 이름으로 설정하려면: 
+모든 로컬 레파지토리에 사용되는 유저 정보를 설정하려면, 그리고 버전 이력을 리뷰할때 알아보기 쉬운 이름으로 설정하려면:

 ```sh
 $ git config --global user.name “[firstname lastname]”
@ -1509,26 +1509,18 @@ $ git config --global user.name “[firstname lastname]”
 git config --global user.email “[valid-email]”
 ```

-### 깃에 명령어 색상을 넣고 싶어
-
-손 쉬운 리뷰를 위한 깃 명령줄 자동 색상을 설정 하려면:
-
-```sh
-$ git config --global color.ui auto
-```
-
 ## 뭘 잘못했는지 모르겠어

 음, 망했군요. 뭔가를 `reset` 했거나, 다른 브랜치로 머지했거나, 지금은 찾질 못하는 커밋으로 강제 푸시를 해버렸군요.
 알다시피, 어떤 시점에선, 잘 하고 있었고 거기로 돌아가고 싶겠죠.
-이게 바로 `git reflog`의 존재이유에요.  `reflog` 는 브랜치 끝의 어떤 변경점이든 브랜치나 태그에 의해 참조되지 않더라도 다 보관해요.       
+이게 바로 `git reflog`의 존재이유에요.  `reflog` 는 브랜치 끝의 어떤 변경점이든 브랜치나 태그에 의해 참조되지 않더라도 다 보관해요.
 기본적으로, HEAD가 변경되는 모든 경우, 리플로그에 새로운 입력이 추가돼요. 아쉽게도 이 기능은 로컬 레파지토리에서만 동작해고, 오직 움직임만을 트래킹해요 (예를 들자면 어디에도 기록되지 않았던 파일의 변경은 아니에요)

 ```sh
-(master)$ git reflog
+(main)$ git reflog
 0a2e358 HEAD@{0}: reset: moving to HEAD~2
-0254ea7 HEAD@{1}: checkout: moving from 2.2 to master
-c10f740 HEAD@{2}: checkout: moving from master to 2.2
+0254ea7 HEAD@{1}: checkout: moving from 2.2 to main
+c10f740 HEAD@{2}: checkout: moving from main to 2.2
 ```

 이 리플로그는 마스터에서 2.2 브랜치로 체크아웃하고 되돌린 것을 보여주네요.
@ -1542,7 +1534,7 @@ $ git reset --hard 0254ea7
 ```

 `git reset`을 쓰는 것으로 마스터를 이전 커밋으로 되돌릴 수 있어요.
-이력이 실수로 변경됐을 때의 안정망을 제공할거에요.  
+이력이 실수로 변경됐을 때의 안정망을 제공할거에요.

 ([여기](https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog)에서 복제해와 수정했어요).

@ -1581,7 +1573,7 @@ $ git reset --hard 0254ea7
 * [Sourcetree](https://www.sourcetreeapp.com/) - 아름답고 무료인 깃 GUI 안에서 단순함과 강력함이 만났어 Windows and Mac
 * [Tower](https://www.git-tower.com/) - 그래픽 Git 클라이언트 OS X (유료)
 * [tig](https://jonas.github.io/tig/) - 깃을 위한 터민러 텍스트 모드 인터페이스
-* [Magit](https://magit.vc/) - Emacs 패키지를 위해 구현된 깃 인터페이스 
+* [Magit](https://magit.vc/) - Emacs 패키지를 위해 구현된 깃 인터페이스
 * [GitExtensions](https://github.com/gitextensions/gitextensions) - 쉘 확장, 비주얼 스투디오 2010-2015 플러그인 그리고 독자적인 깃 레파지토리 도구
 * [Fork](https://git-fork.com/) - 빠르고 친숙한 깃 클라이언트 Mac (베타)
 * [gmaster](https://gmaster.io/) - 3-way 머지, 리팩터 분석기, 시멘틱 diff와 머지 기능의 윈도 전용 깃 클라이언트 (베타)
--- a/README_ru.md
+++ b/README_ru.md
--- a/README_vi.md
+++ b/README_vi.md
--- a/README_zh-CN.md
+++ b/README_zh-CN.md
@ -1,7 +1,7 @@
 # Git飞行规则(Flight Rules)

 🌍
-*[English](README.md) ∙ [Español](README_es.md)  ∙  [Русский](README_ru.md) ∙ [简体中文](README_zh-CN.md)∙ [한국어](README_kr.md)  ∙  [Tiếng Việt](README_vi.md) ∙ [Français](README_fr.md)*
+*[English](README.md) ∙ [Español](README_es.md)  ∙  [Русский](README_ru.md) ∙ [繁體中文](README_zh-TW.md) ∙ [简体中文](README_zh-CN.md) ∙ [한국어](README_kr.md)  ∙  [Tiếng Việt](README_vi.md) ∙ [Français](README_fr.md) ∙ [日本語](README_ja.md)*

 #### 前言

@ -32,7 +32,7 @@
    - [我的提交信息(commit message)写错了](#%E6%88%91%E7%9A%84%E6%8F%90%E4%BA%A4%E4%BF%A1%E6%81%AFcommit-message%E5%86%99%E9%94%99%E4%BA%86)
    - [我提交(commit)里的用户名和邮箱不对](#%E6%88%91%E6%8F%90%E4%BA%A4commit%E9%87%8C%E7%9A%84%E7%94%A8%E6%88%B7%E5%90%8D%E5%92%8C%E9%82%AE%E7%AE%B1%E4%B8%8D%E5%AF%B9)
    - [我想从一个提交(commit)里移除一个文件](#%E6%88%91%E6%83%B3%E4%BB%8E%E4%B8%80%E4%B8%AA%E6%8F%90%E4%BA%A4commit%E9%87%8C%E7%A7%BB%E9%99%A4%E4%B8%80%E4%B8%AA%E6%96%87%E4%BB%B6)
-    - [我想删除我的的最后一次提交(commit)](#%E6%88%91%E6%83%B3%E5%88%A0%E9%99%A4%E6%88%91%E7%9A%84%E7%9A%84%E6%9C%80%E5%90%8E%E4%B8%80%E6%AC%A1%E6%8F%90%E4%BA%A4commit)
+    - [我想删除我的最后一次提交(commit)](#%E6%88%91%E6%83%B3%E5%88%A0%E9%99%A4%E6%88%91%E7%9A%84%E7%9A%84%E6%9C%80%E5%90%8E%E4%B8%80%E6%AC%A1%E6%8F%90%E4%BA%A4commit)
    - [删除任意提交(commit)](#%E5%88%A0%E9%99%A4%E4%BB%BB%E6%84%8F%E6%8F%90%E4%BA%A4commit)
    - [我尝试推一个修正后的提交(amended commit)到远程，但是报错：](#%E6%88%91%E5%B0%9D%E8%AF%95%E6%8E%A8%E4%B8%80%E4%B8%AA%E4%BF%AE%E6%AD%A3%E5%90%8E%E7%9A%84%E6%8F%90%E4%BA%A4amended-commit%E5%88%B0%E8%BF%9C%E7%A8%8B%E4%BD%86%E6%98%AF%E6%8A%A5%E9%94%99)
    - [我意外的做了一次硬重置(hard reset)，我想找回我的内容](#%E6%88%91%E6%84%8F%E5%A4%96%E7%9A%84%E5%81%9A%E4%BA%86%E4%B8%80%E6%AC%A1%E7%A1%AC%E9%87%8D%E7%BD%AEhard-reset%E6%88%91%E6%83%B3%E6%89%BE%E5%9B%9E%E6%88%91%E7%9A%84%E5%86%85%E5%AE%B9)
@ -49,7 +49,7 @@
  - [分支(Branches)](#%E5%88%86%E6%94%AFbranches)
    - [我从错误的分支拉取了内容，或把内容拉取到了错误的分支](#%E6%88%91%E4%BB%8E%E9%94%99%E8%AF%AF%E7%9A%84%E5%88%86%E6%94%AF%E6%8B%89%E5%8F%96%E4%BA%86%E5%86%85%E5%AE%B9%E6%88%96%E6%8A%8A%E5%86%85%E5%AE%B9%E6%8B%89%E5%8F%96%E5%88%B0%E4%BA%86%E9%94%99%E8%AF%AF%E7%9A%84%E5%88%86%E6%94%AF)
    - [我想扔掉本地的提交(commit)，以便我的分支与远程的保持一致](#%E6%88%91%E6%83%B3%E6%89%94%E6%8E%89%E6%9C%AC%E5%9C%B0%E7%9A%84%E6%8F%90%E4%BA%A4commit%E4%BB%A5%E4%BE%BF%E6%88%91%E7%9A%84%E5%88%86%E6%94%AF%E4%B8%8E%E8%BF%9C%E7%A8%8B%E7%9A%84%E4%BF%9D%E6%8C%81%E4%B8%80%E8%87%B4)
-    - [我需要提交到一个新分支，但错误的提交到了master](#%E6%88%91%E9%9C%80%E8%A6%81%E6%8F%90%E4%BA%A4%E5%88%B0%E4%B8%80%E4%B8%AA%E6%96%B0%E5%88%86%E6%94%AF%E4%BD%86%E9%94%99%E8%AF%AF%E7%9A%84%E6%8F%90%E4%BA%A4%E5%88%B0%E4%BA%86master)
+    - [我需要提交到一个新分支，但错误的提交到了main](#%E6%88%91%E9%9C%80%E8%A6%81%E6%8F%90%E4%BA%A4%E5%88%B0%E4%B8%80%E4%B8%AA%E6%96%B0%E5%88%86%E6%94%AF%E4%BD%86%E9%94%99%E8%AF%AF%E7%9A%84%E6%8F%90%E4%BA%A4%E5%88%B0%E4%BA%86main)
    - [我想保留来自另外一个ref-ish的整个文件](#%E6%88%91%E6%83%B3%E4%BF%9D%E7%95%99%E6%9D%A5%E8%87%AA%E5%8F%A6%E5%A4%96%E4%B8%80%E4%B8%AAref-ish%E7%9A%84%E6%95%B4%E4%B8%AA%E6%96%87%E4%BB%B6)
    - [我把几个提交(commit)提交到了同一个分支，而这些提交应该分布在不同的分支里](#%E6%88%91%E6%8A%8A%E5%87%A0%E4%B8%AA%E6%8F%90%E4%BA%A4commit%E6%8F%90%E4%BA%A4%E5%88%B0%E4%BA%86%E5%90%8C%E4%B8%80%E4%B8%AA%E5%88%86%E6%94%AF%E8%80%8C%E8%BF%99%E4%BA%9B%E6%8F%90%E4%BA%A4%E5%BA%94%E8%AF%A5%E5%88%86%E5%B8%83%E5%9C%A8%E4%B8%8D%E5%90%8C%E7%9A%84%E5%88%86%E6%94%AF%E9%87%8C)
    - [我想删除上游(upstream)分支被删除了的本地分支](#%E6%88%91%E6%83%B3%E5%88%A0%E9%99%A4%E4%B8%8A%E6%B8%B8upstream%E5%88%86%E6%94%AF%E8%A2%AB%E5%88%A0%E9%99%A4%E4%BA%86%E7%9A%84%E6%9C%AC%E5%9C%B0%E5%88%86%E6%94%AF)
@ -101,7 +101,7 @@
 如果你用 `git commit -a` 提交了一次变化(changes)，而你又不确定到底这次提交了哪些内容。 你就可以用下面的命令显示当前`HEAD`上的最近一次的提交(commit):

 ```sh
-(master)$ git show
+(main)$ git show
 ```

 或者
@ -110,7 +110,7 @@
 $ git log -n1 -p
 ```

-<a name="#i-wrote-the-wrong-thing-in-a-commit-message"></a>
+<a name="wrong-thing-in-commit-message"></a>
 ### 我的提交信息(commit message)写错了

 如果你的提交信息(commit message)写错了且这次提交(commit)还没有推(push), 你可以通过下面的方法来修改提交信息(commit message):
@ -137,7 +137,7 @@ $ git commit --amend --author "New Authorname <authoremail@mydomain.com>"

 如果你需要修改所有历史, 参考 'git filter-branch'的指南页.

-<a href="#i-want-to-remove-a-file-from-a-commit"></a>
+<a name="remove-file-from-commit"></a>
 ### 我想从一个提交(commit)里移除一个文件

 通过下面的方法，从一个提交(commit)里移除一个文件:
@ -163,8 +163,7 @@ $ git push -f [remote] [branch]
 如果你还没有推到远程, 把Git重置(reset)到你最后一次提交前的状态就可以了(同时保存暂存的变化):

 ```
-(my-branch*)$ git reset --soft HEAD@{1}
-
+(my-branch)$ git reset --soft HEAD^
 ```

 这只能在没有推送之前有用. 如果你已经推了, 唯一安全能做的是 `git revert SHAofBadCommit`， 那会创建一个新的提交(commit)用于撤消前一个提交的所有变化(changes)； 或者, 如果你推的这个分支是rebase-safe的 (例如： 其它开发者不会从这个分支拉), 只需要使用 `git push -f`； 更多, 请参考 [the above section](#deleteremove-last-pushed-commit)。
@ -181,7 +180,7 @@ $ git push -f [remote] [branch]

 或者做一个 [交互式rebase](#interactive-rebase) 删除那些你想要删除的提交(commit)里所对应的行。

-<a name="#force-push"></a>
+<a name="force-push"></a>
 ### 我尝试推一个修正后的提交(amended commit)到远程，但是报错：

 ```sh
@ -202,26 +201,26 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.

 一般来说, **要避免强推**. 最好是创建和推(push)一个新的提交(commit)，而不是强推一个修正后的提交。后者会使那些与该分支或该分支的子分支工作的开发者，在源历史中产生冲突。

-<a href="undo-git-reset-hard"></a>
+<a name="undo-git-reset-hard"></a>
 ### 我意外的做了一次硬重置(hard reset)，我想找回我的内容

 如果你意外的做了 `git reset --hard`, 你通常能找回你的提交(commit), 因为Git对每件事都会有日志，且都会保存几天。

 ```sh
-(master)$ git reflog
+(main)$ git reflog
 ```

 你将会看到一个你过去提交(commit)的列表, 和一个重置的提交。 选择你想要回到的提交(commit)的SHA，再重置一次:

 ```sh
-(master)$ git reset --hard SHA1234
+(main)$ git reset --hard SHA1234
 ```

 这样就完成了。

 ## 暂存(Staging)

-<a href="#i-need-to-add-staged-changes-to-the-previous-commit"></a>
+<a name="add-staged-changes-to-previous-commit"></a>
 ### 我需要把暂存的内容添加到上一次的提交(commit)

 ```sh
@ -246,12 +245,12 @@ $ git add -N filename.x

 然后, 你需要用 `e` 选项来手动选择需要添加的行，执行 `git diff --cached` 将会显示哪些行暂存了哪些行只是保存在本地了。

-<a href="stage-in-two-commits"></a>
+<a name="stage-in-two-commits"></a>
 ### 我想把在一个文件里的变化(changes)加到两个提交(commit)里

 `git add` 会把整个文件加入到一个提交. `git add -p` 允许交互式的选择你想要提交的部分.

-<a href="unstaging-edits-and-staging-the-unstaged"></a>
+<a name="unstaging-edits-and-staging-the-unstaged"></a>
 ### 我想把暂存的内容变成未暂存，把未暂存的内容暂存起来

 多数情况下，你应该将所有的内容变为未暂存，然后再选择你想要的内容进行commit。
@ -270,14 +269,14 @@ $ git stash pop --index 0

 ## 未暂存(Unstaged)的内容

-<a href="move-unstaged-edits-to-new-branch"></a>
+<a name="move-unstaged-edits-to-new-branch"></a>
 ### 我想把未暂存的内容移动到一个新分支

 ```sh
 $ git checkout -b my-branch
 ```

-<a href="move-unstaged-edits-to-old-branch"></a>
+<a name="move-unstaged-edits-to-old-branch"></a>
 ### 我想把未暂存的内容移动到另一个已存在的分支

 ```sh
@ -286,7 +285,7 @@ $ git checkout my-branch
 $ git stash pop
 ```

-<a href="i-want-to-discard-my-local-uncommitted-changes"></a>
+<a name="discard-local-uncommitted-changes"></a>
 ### 我想丢弃本地未提交的变化(uncommitted changes)

 如果你只是想重置源(origin)和你本地(local)之间的一些提交(commit)，你可以：
@ -299,7 +298,7 @@ $ git stash pop
 # four commits
 (my-branch)$ git reset --hard HEAD~4
 # or
-(master)$ git checkout -f
+(main)$ git checkout -f
 ```

 重置某个特殊的文件, 你可以用文件名做为参数:
@ -308,7 +307,7 @@ $ git stash pop
 $ git reset filename
 ```

-<a href="i-want-to-discard-specific-unstaged-changes"></a>
+<a name="discard-specific-unstaged-changes"></a>
 ### 我想丢弃某些未暂存的内容

 如果你想丢弃工作拷贝中的一部分内容，而不是全部。
@ -345,7 +344,7 @@ $ git stash drop
 这是另外一种使用 `git reflog` 情况，找到在这次错误拉(pull) 之前HEAD的指向。

 ```sh
-(master)$ git reflog
+(main)$ git reflog
 ab7555f HEAD@{0}: pull origin wrong-branch: Fast-forward
 c5bc55a HEAD@{1}: checkout: checkout message goes here
 ```
@ -358,7 +357,7 @@ $ git reset --hard c5bc55a

 完成。

-<a href="discard-local-commits"></a>
+<a name="discard-local-commits"></a>
 ### 我想扔掉本地的提交(commit)，以便我的分支与远程的保持一致

 先确认你没有推(push)你的内容到远程。
@ -376,39 +375,39 @@ $ git reset --hard c5bc55a
 一种方法是:

 ```sh
-(master)$ git reset --hard origin/my-branch
+(my-branch)$ git reset --hard origin/my-branch
 ```

 <a name="commit-wrong-branch"></a>
-### 我需要提交到一个新分支，但错误的提交到了master
+### 我需要提交到一个新分支，但错误的提交到了main

-在master下创建一个新分支，不切换到新分支,仍在master下:
+在main下创建一个新分支，不切换到新分支,仍在main下:

 ```sh
-(master)$ git branch my-branch
+(main)$ git branch my-branch
 ```

-把master分支重置到前一个提交:
+把main分支重置到前一个提交:

 ```sh
-(master)$ git reset --hard HEAD^
+(main)$ git reset --hard HEAD^
 ```

 `HEAD^` 是 `HEAD^1` 的简写，你可以通过指定要设置的`HEAD`来进一步重置。

 或者, 如果你不想使用 `HEAD^`, 找到你想重置到的提交(commit)的hash(`git log` 能够完成)， 然后重置到这个hash。 使用`git push` 同步内容到远程。

-例如, master分支想重置到的提交的hash为`a13b85e`:
+例如, main分支想重置到的提交的hash为`a13b85e`:

 ```sh
-(master)$ git reset --hard a13b85e
+(main)$ git reset --hard a13b85e
 HEAD is now at a13b85e
 ```

 签出(checkout)刚才新建的分支继续工作:

 ```sh
-(master)$ git checkout my-branch
+(main)$ git checkout my-branch
 ```

 <a name="keep-whole-file"></a>
@ -451,10 +450,10 @@ Note: Spike solutions are made to analyze or solve the problem. These solutions
 <a name="cherry-pick"></a>
 ### 我把几个提交(commit)提交到了同一个分支，而这些提交应该分布在不同的分支里

-假设你有一个`master`分支， 执行`git log`, 你看到你做过两次提交:
+假设你有一个`main`分支， 执行`git log`, 你看到你做过两次提交:

 ```sh
-(master)$ git log
+(main)$ git log

 commit e3851e817c451cc36f2e6f3049db528415e3c114
 Author: Alex Lee <alexlee@example.com>
@ -477,17 +476,17 @@ Date:   Tue Jul 21 01:12:48 2014 -0400

 让我们用提交hash(commit hash)标记bug (`e3851e8` for #21, `5ea5173` for #14).

-首先, 我们把`master`分支重置到正确的提交(`a13b85e`):
+首先, 我们把`main`分支重置到正确的提交(`a13b85e`):

 ```sh
-(master)$ git reset --hard a13b85e
+(main)$ git reset --hard a13b85e
 HEAD is now at a13b85e
 ```

 现在, 我们对 bug #21 创建一个新的分支:

 ```sh
-(master)$ git checkout -b 21
+(main)$ git checkout -b 21
 (21)$
 ```

@ -499,11 +498,11 @@ HEAD is now at a13b85e

 这时候, 这里可能会产生冲突， 参见[交互式 rebasing 章](#interactive-rebase) [**冲突节**](#merge-conflict) 解决冲突.

-再者， 我们为bug #14 创建一个新的分支, 也基于`master`分支
+再者， 我们为bug #14 创建一个新的分支, 也基于`main`分支

 ```sh
-(21)$ git checkout master
-(master)$ git checkout -b 14
+(21)$ git checkout main
+(main)$ git checkout -b 14
 (14)$
 ```

@ -521,13 +520,13 @@ HEAD is now at a13b85e
 $ git fetch -p
 ```

-<a name='restore-a-deleted-branch'></a>
+<a name="restore-a-deleted-branch"></a>
 ### 我不小心删除了我的分支

 如果你定期推送到远程, 多数情况下应该是安全的，但有些时候还是可能删除了还没有推到远程的分支。 让我们先创建一个分支和一个新的文件:

 ```sh
-(master)$ git checkout -b my-branch
+(main)$ git checkout -b my-branch
 (my-branch)$ git branch
 (my-branch)$ touch foo.txt
 (my-branch)$ ls
@ -557,31 +556,31 @@ Date:   Tue Jul 29 13:14:46 2014 -0400
    Fixes #6: Force pushing after amending commits
 ```

-现在我们切回到主(master)分支，‘不小心的’删除`my-branch`分支
+现在我们切回到主(main)分支，‘不小心的’删除`my-branch`分支

 ```sh
-(my-branch)$ git checkout master
-Switched to branch 'master'
-Your branch is up-to-date with 'origin/master'.
-(master)$ git branch -D my-branch
+(my-branch)$ git checkout main
+Switched to branch 'main'
+Your branch is up-to-date with 'origin/main'.
+(main)$ git branch -D my-branch
 Deleted branch my-branch (was 4e3cd85).
-(master)$ echo oh noes, deleted my branch!
+(main)$ echo oh noes, deleted my branch!
 oh noes, deleted my branch!
 ```

 在这时候你应该想起了`reflog`, 一个升级版的日志，它存储了仓库(repo)里面所有动作的历史。

 ```
-(master)$ git reflog
-69204cd HEAD@{0}: checkout: moving from my-branch to master
+(main)$ git reflog
+69204cd HEAD@{0}: checkout: moving from my-branch to main
 4e3cd85 HEAD@{1}: commit: foo.txt added
-69204cd HEAD@{2}: checkout: moving from master to my-branch
+69204cd HEAD@{2}: checkout: moving from main to my-branch
 ```

 正如你所见，我们有一个来自删除分支的提交hash(commit hash)，接下来看看是否能恢复删除了的分支。

 ```sh
-(master)$ git checkout -b my-branch-help
+(main)$ git checkout -b my-branch-help
 Switched to a new branch 'my-branch-help'
 (my-branch-help)$ git reset --hard 4e3cd85
 HEAD is now at 4e3cd85 foo.txt added
@ -591,40 +590,40 @@ README.md foo.txt

 看! 我们把删除的文件找回来了。 Git的 `reflog` 在rebasing出错的时候也是同样有用的。

-<a name="i-want-to-delete-a-branch"></a>
+<a name="delete-branch"></a>
 ### 我想删除一个分支

 删除一个远程分支:

 ```sh
-(master)$ git push origin --delete my-branch
+(main)$ git push origin --delete my-branch
 ```

 你也可以:

 ```sh
-(master)$ git push origin :my-branch
+(main)$ git push origin :my-branch
 ```

 删除一个本地分支:

 ```sh
-(master)$ git branch -D my-branch
+(main)$ git branch -D my-branch
 ```

-<a name="i-want-to-checkout-to-a-remote-branch-that-someone-else-is-working-on"></a>
+<a name="working-on-checkout-remote-branch"></a>
 ### 我想从别人正在工作的远程分支签出(checkout)一个分支

 首先, 从远程拉取(fetch) 所有分支:

 ```sh
-(master)$ git fetch --all
+(main)$ git fetch --all
 ```

 假设你想要从远程的`daves`分支签出到本地的`daves`

 ```sh
-(master)$ git checkout --track origin/daves
+(main)$ git checkout --track origin/daves
 Branch daves set up to track remote branch daves from origin.
 Switched to a new branch 'daves'
 ```
@ -650,10 +649,10 @@ Switched to a new branch 'daves'
 不幸的是，如果你想把这些变化(changes)反应到远程分支上，你就必须得强推(force push)。 是因你快进(Fast forward)了提交，改变了Git历史, 远程分支不会接受变化(changes)，除非强推(force push)。这就是许多人使用 merge 工作流, 而不是 rebasing 工作流的主要原因之一， 开发者的强推(force push)会使大的团队陷入麻烦。使用时需要注意，一种安全使用 rebase 的方法是，不要把你的变化(changes)反映到远程分支上, 而是按下面的做:

 ```sh
-(master)$ git checkout my-branch
-(my-branch)$ git rebase -i master
-(my-branch)$ git checkout master
-(master)$ git merge --ff-only my-branch
+(main)$ git checkout my-branch
+(my-branch)$ git rebase -i main
+(my-branch)$ git checkout main
+(main)$ git merge --ff-only my-branch
 ```

 更多, 参见 [this SO thread](http://stackoverflow.com/questions/11058312/how-can-i-use-git-rebase-without-requiring-a-forced-push).
@ -661,23 +660,23 @@ Switched to a new branch 'daves'
 <a name="interactive-rebase"></a>
 ### 我需要组合(combine)几个提交(commit)

-假设你的工作分支将会做对于 `master` 的pull-request。 一般情况下你不关心提交(commit)的时间戳，只想组合 *所有* 提交(commit) 到一个单独的里面, 然后重置(reset)重提交(recommit)。 确保主(master)分支是最新的和你的变化都已经提交了, 然后:
+假设你的工作分支将会做对于 `main` 的pull-request。 一般情况下你不关心提交(commit)的时间戳，只想组合 *所有* 提交(commit) 到一个单独的里面, 然后重置(reset)重提交(recommit)。 确保主(main)分支是最新的和你的变化都已经提交了, 然后:

 ```sh
-(my-branch)$ git reset --soft master
+(my-branch)$ git reset --soft main
 (my-branch)$ git commit -am "New awesome feature"
 ```

 如果你想要更多的控制, 想要保留时间戳, 你需要做交互式rebase (interactive rebase):

 ```sh
-(my-branch)$ git rebase -i master
+(my-branch)$ git rebase -i main
 ```

 如果没有相对的其它分支， 你将不得不相对自己的`HEAD` 进行 rebase。 例如：你想组合最近的两次提交(commit), 你将相对于`HEAD~2` 进行rebase， 组合最近3次提交(commit), 相对于`HEAD~3`, 等等。

 ```sh
-(master)$ git rebase -i HEAD~2
+(main)$ git rebase -i HEAD~2
 ```

 在你执行了交互式 rebase的命令(interactive rebase command)后, 你将在你的编辑器里看到类似下面的内容:
@ -737,7 +736,7 @@ Newer, awesomer features
 # Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
 # rebase in progress; onto 8074d12
-# You are currently editing a commit while rebasing branch 'master' on '8074d12'.
+# You are currently editing a commit while rebasing branch 'main' on '8074d12'.
 #
 # Changes to be committed:
 #	modified:   README.md
@ -748,20 +747,20 @@ Newer, awesomer features
 如果成功了, 你应该看到类似下面的内容:

 ```sh
-(master)$ Successfully rebased and updated refs/heads/master.
+(main)$ Successfully rebased and updated refs/heads/main.
 ```

 #### 安全合并(merging)策略
 `--no-commit` 执行合并(merge)但不自动提交, 给用户在做提交前检查和修改的机会。 `no-ff` 会为特性分支(feature branch)的存在过留下证据, 保持项目历史一致。

 ```sh
-(master)$ git merge --no-ff --no-commit my-branch
+(main)$ git merge --no-ff --no-commit my-branch
 ```

 #### 我需要将一个分支合并成一个提交(commit)

 ```sh
-(master)$ git merge --squash my-branch
+(main)$ git merge --squash my-branch
 ```

 <a name="rebase-unpushed-commits"></a>
@ -770,7 +769,7 @@ Newer, awesomer features
 有时候，在将数据推向上游之前，你有几个正在进行的工作提交(commit)。这时候不希望把已经推(push)过的组合进来，因为其他人可能已经有提交(commit)引用它们了。

 ```sh
-(master)$ git rebase -i @{u}
+(main)$ git rebase -i @{u}
 ```

 这会产生一次交互式的rebase(interactive rebase), 只会列出没有推(push)的提交(commit)， 在这个列表时进行reorder/fix/squash 都是安全的。
@ -781,13 +780,13 @@ Newer, awesomer features
 检查一个分支上的所有提交(commit)是否都已经合并(merge)到了其它分支, 你应该在这些分支的head(或任何 commits)之间做一次diff:

 ```sh
-(master)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll
+(main)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll
 ```

 这会告诉你在一个分支里有而另一个分支没有的所有提交(commit), 和分支之间不共享的提交(commit)的列表。 另一个做法可以是:

 ```sh
-(master)$ git log master ^feature/120-on-scroll --no-merges
+(main)$ git log main ^feature/120-on-scroll --no-merges
 ```

 ### 交互式rebase(interactive rebase)可能出现的问题
@ -802,7 +801,7 @@ noop

 这意味着你rebase的分支和当前分支在同一个提交(commit)上, 或者 *领先(ahead)* 当前分支。 你可以尝试:

-* 检查确保主(master)分支没有问题
+* 检查确保主(main)分支没有问题
 * rebase  `HEAD~2` 或者更早

 <a name="merge-conflict"></a>
@ -837,7 +836,7 @@ Changes not staged for commit:
 有时候这些合并非常复杂，你应该使用可视化的差异编辑器(visual diff editor):

 ```sh
-(master*)$ git mergetool -t opendiff
+(main*)$ git mergetool -t opendiff
 ```

 在你解决完所有冲突和测试过后, `git add` 变化了的(changed)文件, 然后用`git rebase --continue` 继续rebase。
@ -921,7 +920,7 @@ $ git stash apply "stash@{n}"
 $ git stash apply "stash@{2.hours.ago}"
 ```

-<a href="stage-and-keep-unstaged"></a>
+<a name="stage-and-keep-unstaged"></a>
 ### 暂存时保留未暂存的内容

 你需要手动create一个`stash commit`， 然后使用`git stash store`。
@ -981,18 +980,18 @@ $ git update-ref refs/tags/<tag_name> <hash>

 ## 跟踪文件(Tracking Files)

-<a href="i-want-to-change-a-file-names-capitalization-without-changing-the-contents-of-the-file"></a>
+<a name="change-file-name-capitalization-without-changing-contents"></a>
 ### 我只想改变一个文件名字的大小写，而不修改内容

 ```sh
-(master)$ git mv --force myfile MyFile
+(main)$ git mv --force myfile MyFile
 ```

-<a href="remove-from-git"></a>
+<a name="remove-from-git"></a>
 ### 我想从Git删除一个文件，但保留该文件

 ```sh
-(master)$ git rm --cached log.txt
+(main)$ git rm --cached log.txt
 ```

 ## 配置(Configuration)
@ -1040,7 +1039,7 @@ $ git config --global credential.helper 'cache --timeout=3600'
 # Set the cache to timeout after 1 hour (setting is in seconds)
 ```

-<a href="#ive-no-idea-what-i-did-wrong"></a>
+<a name="ive-no-idea-what-i-did-wrong"></a>
 ## 我不知道我做错了些什么

 你把事情搞砸了：你 `重置(reset)` 了一些东西, 或者你合并了错误的分支, 亦或你强推了后找不到你自己的提交(commit)了。有些时候, 你一直都做得很好, 但你想回到以前的某个状态。
@ -1048,21 +1047,21 @@ $ git config --global credential.helper 'cache --timeout=3600'
 这就是 `git reflog` 的目的， `reflog` 记录对分支顶端(the tip of a branch)的任何改变, 即使那个顶端没有被任何分支或标签引用。基本上, 每次HEAD的改变, 一条新的记录就会增加到`reflog`。遗憾的是，这只对本地分支起作用，且它只跟踪动作 (例如，不会跟踪一个没有被记录的文件的任何改变)。

 ```sh
-(master)$ git reflog
+(main)$ git reflog
 0a2e358 HEAD@{0}: reset: moving to HEAD~2
-0254ea7 HEAD@{1}: checkout: moving from 2.2 to master
-c10f740 HEAD@{2}: checkout: moving from master to 2.2
+0254ea7 HEAD@{1}: checkout: moving from 2.2 to main
+c10f740 HEAD@{2}: checkout: moving from main to 2.2
 ```

-上面的reflog展示了从master分支签出(checkout)到2.2 分支，然后再签回。 那里，还有一个硬重置(hard reset)到一个较旧的提交。最新的动作出现在最上面以 `HEAD@{0}`标识.
+上面的reflog展示了从main分支签出(checkout)到2.2 分支，然后再签回。 那里，还有一个硬重置(hard reset)到一个较旧的提交。最新的动作出现在最上面以 `HEAD@{0}`标识.

-如果事实证明你不小心回移(move back)了提交(commit), reflog 会包含你不小心回移前master上指向的提交(0254ea7)。
+如果事实证明你不小心回移(move back)了提交(commit), reflog 会包含你不小心回移前main上指向的提交(0254ea7)。

 ```sh
 $ git reset --hard 0254ea7
 ```

-然后使用git reset就可以把master改回到之前的commit，这提供了一个在历史被意外更改情况下的安全网。
+然后使用git reset就可以把main改回到之前的commit，这提供了一个在历史被意外更改情况下的安全网。

 ([摘自](https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog)).

--- a/README_zh-TW.md
+++ b/README_zh-TW.md
Author	SHA1	Message	Date
Lumynous	ceae7a9f9d	Merge `819b14a73f` into `b752196266`	2024-05-14 14:21:38 +08:00
lumynou5	819b14a73f	Add method to change authors for multiple commits	2024-05-14 13:58:41 +08:00
kkitadate	b752196266	Fix link in README_ja.md (#361 )	2024-03-18 10:17:15 -04:00
Richard Littauer	1037756725	Adding Git cartoons by Allison Horst. (#360 ) Adding https://allisonhorst.com/git-github. Also, alphabetized section.	2024-02-23 10:08:06 +11:00
Lumynous	e1fd8abce8	Improve (remove) "Unstaged Edits" (#358 )	2023-09-27 10:35:07 -04:00
h8nor	02cee38025	Fixed typos for internal and external links (#357 ) * Update anchor link to `push.default` documentation * Update anchor link to `rebase --merge` documentation * Fix link typos	2023-07-21 13:41:29 -04:00
Emmanuel Arias	c3df156871	Clarify the use of --amend (#354 ) Co-authored-by: Richard Littauer <richard.littauer@gmail.com>	2023-06-28 11:56:19 +02:00
Lumynous	0b1f7bcdaf	Improve zh-TW (#352 )	2023-06-28 11:51:46 +02:00
Zhizhen He	aefc20702d	fix: typo in README.md (#343 )	2023-02-01 02:18:00 +00:00
apastan	8413701f30	Update info how to reset local branch to remote-tracking branch (#344 )	2023-02-01 02:17:42 +00:00
apastan	3ff35c8642	Update reflog shortname with an ancestry reference (#345 )	2023-02-01 02:17:10 +00:00
apastan	18c656604b	Edits: changes in specific file between commits/branches (#346 )	2023-02-01 02:16:27 +00:00
Luminous-Coder	c34b49ff5a	Correct punctuations and improve readability for zh-TW (#347 )	2023-02-01 02:16:12 +00:00
ericfeunekes	3d101f5456	added I want to move a change from one commit to another (#342 ) Co-authored-by: Eric Feunekes <eric.feunekes@pwc.com>	2022-12-06 23:59:15 +00:00
RuiSiang	a8897df82d	Add traditional Chinese with terminology changes (#341 )	2022-12-06 23:58:46 +00:00
舜岳	04507b8fc3	fix: README_zh-CN (#339 )	2022-11-28 21:53:27 +00:00
Jared Culp	5f1db99e49	Fix "gim" typo (#331 )	2021-09-22 16:37:55 -04:00
Steve-V	65bd59262f	Title of Chris Hadfield's book is incorrect (#319 ) It is actually "An Astronaut's Guide to Life on Earth" https://www.worldcat.org/title/astronauts-guide-to-life-on-earth/oclc/872711307	2021-07-04 13:13:22 -04:00
Viet Than	7caa59575b	Update Vietnamese translations (#318 )	2021-06-25 12:29:37 -04:00
Thi Minh Nhut	eb36083cbd	Fix Spelling Vietnamese (#315 )	2021-05-17 10:10:52 -04:00
Rui Bastos	5816815453	New rule: split a branch into two (#314 )	2021-03-18 08:42:18 -04:00
Richard Littauer	9e1faad0e9	chore: Update ToC	2021-02-25 09:16:54 -05:00
Bastian Venthur	ef15b6cd8b	Removed hint configure color.ui auto: (#311 ) color.ui defaults to "auto" since git version 1.8.4 from August 2013 (https://github.com/git/git/releases/tag/v1.8.4) so it is probably not needed to set this option anymore.	2021-01-26 12:47:47 -05:00
Shota Ray Imaki	fa148da698	Replace master with main (issue/#308) (#309 )	2020-12-01 09:44:45 -05:00
CEUK	82f0b3994d	add patch workflow to sharing code section (#307 )	2020-11-28 16:15:14 -05:00
Richard Littauer	cfca81c274	Adding 日本語 to all of the lists	2020-04-30 17:01:35 -04:00
Shota Imaki	3a855c6e37	Run doctoc	2020-02-27 23:15:42 +09:00
SI	6b0d0090f5	Elaborate Introduction	2020-02-27 23:06:44 +09:00
Shota Imaki	421e7e9c75	Unify spacing	2020-02-27 22:59:27 +09:00
Shota Imaki	178b145f41	Avoid colon in sentences	2020-02-27 22:57:38 +09:00
Shota Imaki	ceb2109a3f	Translate comment	2020-02-27 22:56:47 +09:00
Shota Imaki	e0c6fa128e	Unify wording; 次のコマンド -> 次	2020-02-27 22:56:11 +09:00
Shota Imaki	c87aaf142f	Unify wording; 編集内容 -> 編集	2020-02-27 22:54:27 +09:00
Shota Imaki	cc284a63a3	Unify wording; ステージング -> ステージ	2020-02-27 22:51:49 +09:00
Shota Imaki	a555e4295e	Specify wording; 任意の -> 特定の/全ての	2020-02-27 22:49:30 +09:00
Shota Imaki	d927b41906	Unify wording; 既に -> すでに	2020-02-27 22:45:15 +09:00
Shota Imaki	4935207bd7	Unify wording; 編集内容 -> 編集	2020-02-27 22:43:50 +09:00
SI	25397ac3f2	Elaborate # Other Resources	2020-02-27 22:22:15 +09:00
SI	3868e6ccf6	Elaborate ## I've no idea what I did wrong	2020-02-27 22:18:16 +09:00
SI	ba331a523b	Elaborate ## Configuration	2020-02-27 22:14:20 +09:00
SI	718e24db95	Elaborate ## Debugging with Git	2020-02-27 22:11:36 +09:00
SI	94b47ea011	Elaborate ## Tracking Files	2020-02-27 22:08:09 +09:00
SI	5f5a60b242	Elaborate ## Miscellaneous Objects	2020-02-27 22:05:23 +09:00
SI	f2734d6361	Elaborate ## Submodules	2020-02-27 22:02:48 +09:00
SI	37f9a744ef	Elaborate ## Finding	2020-02-27 22:01:32 +09:00
SI	cd9bfd055a	Elaborate ## Stash	2020-02-27 21:57:28 +09:00
SI	6fdf31d5b4	Elaborate ## Rebasing and Merging	2020-02-27 21:53:30 +09:00
SI	b3d43db200	Elaborate ## Branches	2020-02-24 19:36:17 +09:00
SI	b98b984070	Elaborate ## Unstaged Edits	2020-02-24 19:02:56 +09:00
SI	59307fd087	Elaborate ## Staging	2020-02-24 18:55:52 +09:00
SI	ec45354d85	Elaborate ## Editing Commits	2020-02-24 18:50:49 +09:00
SI	7d9dd08625	Elaborate ## Repositories	2020-02-24 18:12:18 +09:00
SI	964d02f7f6	Translate Introduction	2020-02-23 11:47:15 +09:00
SI	3aa4c6d9a6	Translate # Other Resources	2020-02-22 20:28:09 +09:00
SI	85c967e090	Translate ## Git Shortcuts	2020-02-22 19:53:18 +09:00
SI	f370468b5e	Translate ## I've no idea what I did wrong	2020-02-22 19:41:53 +09:00
SI	3f3e2cde29	Translate ## Configuration	2020-02-22 18:48:48 +09:00
SI	40726c96f7	Translate ## Debugging with Git	2020-02-20 22:12:26 +09:00
SI	0e0971809f	Translate ## Tracking Files	2020-02-20 21:55:36 +09:00
SI	e09b1cac83	Translate ## Miscellaneous Objects	2020-02-20 21:37:19 +09:00
SI	675c08afd9	Translate ## Submodules	2020-02-20 21:17:40 +09:00
SI	96c427d51d	Translate ## Finding	2020-02-17 22:00:30 +09:00
SI	c20458cbff	Translate ## Stash	2020-02-17 21:22:39 +09:00
SI	b01317d586	Translate ## Rebasing and Merging	2020-02-16 10:57:43 +09:00
SI	e6d3f8a659	Translate ## Branches	2020-02-15 11:02:54 +09:00
SI	1d52880553	Translate ## Unstaged Edits	2020-02-14 22:04:42 +09:00
SI	c593b5ede3	Translate ## Staging	2020-02-14 21:35:05 +09:00
SI	5d1814a388	Translate ## Editing Commits	2020-02-13 23:52:53 +09:00
SI	a9acfde034	Elaborate ## Repositories	2020-02-13 19:29:45 +09:00
SI	73f711331e	Translate ##Repositories	2020-02-13 14:04:44 +09:00
Shota Imaki	79584f5e20	initialize ja	2020-02-13 12:13:04 +09:00
kpoznyakov	4afbb4e710	fix typo in 'скомпромЕтированныМ' (#292 ) https://ru.wiktionary.org/wiki/%D1%81%D0%BA%D0%BE%D0%BC%D0%BF%D1%80%D0%BE%D0%BC%D0%B5%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C	2020-01-17 10:02:24 -05:00
Abhishek Kumar	76308321b0	add note on updating remote branch name (#290 ) * add note on updating remote branch name * Style edits.	2019-11-11 07:50:37 -05:00
KarthikSiddarth	bce2f0dd27	Note/git add u (#287 ) * add note about 'git add -u ' * run doctoc * add note about copying folder * add space b/w -- and folder name also mention, this can be done for files * add 'file' in the title * add node on using pathspec * run doctoc * fix small errors * run doctoc * remove 'my-branch' text	2019-10-30 08:38:19 -04:00
KarthikSiddarth	f0b433773f	add note about copying folder (#289 ) * add note about copying folder * add space b/w -- and folder name also mention, this can be done for files * add 'file' in the title	2019-10-20 13:38:02 +02:00
Artem Buslov	e0ff2c06b9	update Russian translation (#286 )	2019-10-15 11:24:03 +00:00