Fix links for zh-TW

Sync "Other Resources" with en for zh-TW
Sync "Git Shortcuts" with en for zh-TW
2025-06-16 12:54:01 -03:00 · 2023-06-25 15:00:06 +08:00 · 2023-06-25 14:55:44 +08:00 · 2023-06-25 14:32:28 +08:00 · 2023-06-24 11:34:34 +08:00 · 2023-06-24 11:06:05 +08:00
9 changed files with 5839 additions and 1073 deletions
--- a/README.md
+++ b/README.md
@ -1,7 +1,7 @@
 # Flight rules for 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)*

 #### What are "flight rules"?

@ -11,7 +11,7 @@ A guide for astronauts (now, programmers using Git) about what to do when things

 > NASA has been capturing our missteps, disasters and solutions since the early 1960s, when Mercury-era ground teams first started gathering "lessons learned" into a compendium that now lists thousands of problematic situations, from engine failure to busted hatch handles to computer glitches, and their solutions.

-&mdash; Chris Hadfield, *An Astronaut's Guide to Life*.
+&mdash; Chris Hadfield, *An Astronaut's Guide to Life on Earth*.

 #### Conventions for this document

@ -30,12 +30,14 @@ All commands should work for at least git version 2.13.0. See the [git website](
    - [I set the wrong remote repository](#i-set-the-wrong-remote-repository)
    - [I want to add code to someone else's repository](#i-want-to-add-code-to-someone-elses-repository)
      - [Suggesting code via pull requests](#suggesting-code-via-pull-requests)
+      - [Suggesting code via patches](#suggesting-code-via-patches)
      - [I need to update my fork with latest updates from the original repository](#i-need-to-update-my-fork-with-latest-updates-from-the-original-repository)
  - [Editing Commits](#editing-commits)
    - [What did I just commit?](#what-did-i-just-commit)
    - [I wrote the wrong thing in a commit message](#i-wrote-the-wrong-thing-in-a-commit-message)
    - [I committed with the wrong name and email configured](#i-committed-with-the-wrong-name-and-email-configured)
    - [I want to remove a file from the previous commit](#i-want-to-remove-a-file-from-the-previous-commit)
+    - [I want to move a change from one commit to another](#i-want-to-move-a-change-from-one-commit-to-another)
    - [I want to delete or remove my last commit](#i-want-to-delete-or-remove-my-last-commit)
    - [Delete/remove arbitrary commit](#deleteremove-arbitrary-commit)
    - [I tried to push my amended commit to a remote, but I got an error message](#i-tried-to-push-my-amended-commit-to-a-remote-but-i-got-an-error-message)
@ -48,6 +50,8 @@ All commands should work for at least git version 2.13.0. See the [git website](
      - [Final Step: Pushing your changed repo history](#final-step-pushing-your-changed-repo-history)
    - [I need to change the content of a commit which is not my last](#i-need-to-change-the-content-of-a-commit-which-is-not-my-last)
  - [Staging](#staging)
+    - [I want to stage all tracked files and leave untracked files](#i-want-to-stage-all-tracked-files-and-leave-untracked-files)
+      - [To stage part of tracked files](#to-stage-part-of-tracked-files)
    - [I need to add staged changes to the previous commit](#i-need-to-add-staged-changes-to-the-previous-commit)
    - [I want to stage part of a new file, but not the whole file](#i-want-to-stage-part-of-a-new-file-but-not-the-whole-file)
    - [I want to add changes in one file to two different commits](#i-want-to-add-changes-in-one-file-to-two-different-commits)
@ -67,7 +71,7 @@ All commands should work for at least git version 2.13.0. See the [git website](
    - [Create a branch from a commit](#create-a-branch-from-a-commit)
    - [I pulled from/into the wrong branch](#i-pulled-frominto-the-wrong-branch)
    - [I want to discard local commits so my branch is the same as one on the server](#i-want-to-discard-local-commits-so-my-branch-is-the-same-as-one-on-the-server)
-    - [I committed to master instead of a new branch](#i-committed-to-master-instead-of-a-new-branch)
+    - [I committed to main instead of a new branch](#i-committed-to-main-instead-of-a-new-branch)
    - [I want to keep the whole file from another ref-ish](#i-want-to-keep-the-whole-file-from-another-ref-ish)
    - [I made several commits on a single branch that should be on different branches](#i-made-several-commits-on-a-single-branch-that-should-be-on-different-branches)
    - [I want to delete local branches that were deleted upstream](#i-want-to-delete-local-branches-that-were-deleted-upstream)
@ -80,6 +84,7 @@ All commands should work for at least git version 2.13.0. See the [git website](
    - [I want to set a remote branch as the upstream for a local branch](#i-want-to-set-a-remote-branch-as-the-upstream-for-a-local-branch)
    - [I want to set my HEAD to track the default remote branch](#i-want-to-set-my-head-to-track-the-default-remote-branch)
    - [I made changes on the wrong branch](#i-made-changes-on-the-wrong-branch)
+    - [I want to split a branch into two](#i-want-to-split-a-branch-into-two)
  - [Rebasing and Merging](#rebasing-and-merging)
    - [I want to undo rebase/merge](#i-want-to-undo-rebasemerge)
    - [I rebased, but I don't want to force push](#i-rebased-but-i-dont-want-to-force-push)
@ -109,6 +114,7 @@ All commands should work for at least git version 2.13.0. See the [git website](
    - [Clone all submodules](#clone-all-submodules)
    - [Remove a submodule](#remove-a-submodule)
  - [Miscellaneous Objects](#miscellaneous-objects)
+    - [Copy a folder or file from one branch to another](#copy-a-folder-or-file-from-one-branch-to-another)
    - [Restore a deleted file](#restore-a-deleted-file)
    - [Delete tag](#delete-tag)
    - [Recover a deleted tag](#recover-a-deleted-tag)
@ -129,7 +135,6 @@ All commands should work for at least git version 2.13.0. See the [git website](
    - [I want to cache a username and password for a repository](#i-want-to-cache-a-username-and-password-for-a-repository)
    - [I want to make Git ignore permissions and filemode changes](#i-want-to-make-git-ignore-permissions-and-filemode-changes)
    - [I want to set a global user](#i-want-to-set-a-global-user)
-    - [I want to add command line coloring for Git](#i-want-to-add-command-line-coloring-for-git)
  - [I've no idea what I did wrong](#ive-no-idea-what-i-did-wrong)
  - [Git Shortcuts](#git-shortcuts)
    - [Git Bash](#git-bash)
@ -234,6 +239,20 @@ There is no way to suggest a pull request using the CLI using Git (although ther

 After all of this, do not forget to respond to any code review feedback.

+#### Suggesting code via patches
+
+Another approach to suggesting code changes that doesn't rely on third party sites such as Github is to use `git format-patch`.
+
+`format-patch` creates a .patch file for one or more commits. This file is essentially a list of changes that looks similar to the commit diffs you can view on Github.
+
+A patch can be viewed and even edited by the recipient and applied using `git am`.
+
+For example, to create a patch based on the previous commit you would run `git format-patch HEAD^` which would create a .patch file called something like 0001-My-Commit-Message.patch.
+
+To apply this patch file to your repository you would run `git am ./0001-My-Commit-Message.patch`.
+
+Patches can also be sent via email using the `git send-email` command. For information on usage and configuration see: https://git-send-email.io
+
 #### I need to update my fork with latest updates from the original repository

 After a while, the `upstream` repository may have been updated, and these updates need to be pulled into your `origin` repo. Remember that like you, other people are contributing too. Suppose that you are in your own feature branch and you need to update it with the original repository updates.
@ -241,18 +260,18 @@ After a while, the `upstream` repository may have been updated, and these update
 You probably have set up a remote that points to the original project. If not, do this now. Generally we use `upstream` as a remote name:

 ```sh
-$ (master) git remote add upstream <link-to-original-repository>
-# $ (master) git remote add upstream git@github.com:k88hudson/git-flight-rules.git
+$ (main) git remote add upstream <link-to-original-repository>
+# $ (main) git remote add upstream git@github.com:k88hudson/git-flight-rules.git
 ```

 Now you can fetch from upstream and get the latest updates.

 ```sh
-$ (master) git fetch upstream
-$ (master) git merge upstream/master
+$ (main) git fetch upstream
+$ (main) git merge upstream/main

 # or using a single command
-$ (master) git pull upstream master
+$ (main) git pull upstream main
 ```

 ## Editing Commits
@ -263,7 +282,7 @@ $ (master) git pull upstream master
 Let's say that you just blindly committed changes with `git commit -a` and you're not sure what the actual content of the commit you just made was. You can show the latest commit on your current HEAD with:

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

 Or
@ -330,6 +349,58 @@ $ git commit --amend --no-edit

 This is particularly useful when you have an open patch and you have committed an unnecessary file, and need to force push to update the patch on a remote. The `--no-edit` option is used to keep the existing commit message.

+<a name="move-change-to-new-commit"></a>
+### I want to move a change from one commit to another
+If you've made a commit that includes changes that would fit better in another commit, you can move the changes to the other commit using an interactive rebase. This comes from [stackoverflow](https://stackoverflow.com/a/54985304/2491502).
+
+For example, you have three commits (a, b, c). On b, you've changes file1 and file2 and you want to move the change on file1 from commit b to commit a.
+
+First, rebase interactively:
+
+```sh
+$ git rebase -i HEAD~3
+```
+
+This will open an editor with the following:
+
+```sh
+pick a
+pick b
+pick c
+```
+
+Change the lines with a and b to edit:
+
+```sh
+edit a
+edit b
+pick c
+```
+
+Save and close the editor. This will bring you to commit b. Now, reset the file1 changes:
+
+```sh
+$ git reset HEAD~1 file1
+```
+
+This will unstage the changes in file1. Now, stash those changes and continue the rebase:
+
+```sh
+$ git stash
+$ git rebase --continue
+```
+
+Now you will be editing commit a. Unstash the changes then add them to the current commit and continue the rebase:
+
+```sh
+$ git stash pop
+$ git add file1
+$ git commit --amend --no-edit
+$ git rebase --continue
+```
+
+Now your rebase is complete, with the changes from b on a. If you wanted to move the changes from b to c, you would have to do two rebases since c comes before b: one to get the changes out of b, then another to edit c and add the stashed changes.
+
 <a name="delete-pushed-commit"></a>
 ### I want to delete or remove my last commit

@ -343,8 +414,7 @@ $ git push --force-with-lease [remote] [branch]
 If you haven't pushed, to reset Git to the state it was in before you made your last commit (while keeping your staged changes):

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

 This only works if you haven't pushed. If you have pushed, the only truly safe thing to do is `git revert SHAofBadCommit`. That will create a new commit that undoes all the previous commit's changes. Or, if the branch you pushed to is rebase-safe (ie. other devs aren't expected to pull from it), you can just use `git push --force-with-lease`. For more, see [the above section](#deleteremove-last-pushed-commit).
@ -392,13 +462,13 @@ If you accidentally do `git reset --hard`, you can normally still get your commi
 Note: This is only valid if your work is backed up, i.e., either committed or stashed. `git reset --hard` _will remove_ uncommitted modifications, so use it with caution. (A safer option is `git reset --keep`.)

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

 You'll see a list of your past commits, and a commit for the reset. Choose the SHA of the commit you want to return to, and reset again:

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

 And you should be good to go.
@ -439,6 +509,7 @@ echo sensitive_file >> .gitignore
 Alternatively store your sensitive data in local environment variables.

 If you want to completely remove an entire file (and not keep it locally), then run
+
 ```sh
 (feature-branch)$ git rm sensitive_file
 (feature-branch)$ git commit --amend --no-edit
@ -463,18 +534,21 @@ There are two options for rewriting history, the built-in `git-filter-branch` or
 Using bfg-repo-cleaner requires java. Download the bfg jar from the link [here](https://rtyley.github.io/bfg-repo-cleaner/). Our examples will use `bfg.jar`, but your download may have a version number, e.g. `bfg-1.13.0.jar`.

 To delete a specific file.
+
 ```sh
-(master)$ git rm path/to/filetoremove
-(master)$ git commit -m "Commit removing filetoremove"
-(master)$ java -jar ~/Downloads/bfg.jar --delete-files filetoremove
+(main)$ git rm path/to/filetoremove
+(main)$ git commit -m "Commit removing filetoremove"
+(main)$ java -jar ~/Downloads/bfg.jar --delete-files filetoremove
 ```
+
 Note that in bfg you must use the plain file name even if it is in a subdirectory.

 You can also delete a file by pattern, e.g.:
+
 ```sh
-(master)$ git rm *.jpg
-(master)$ git commit -m "Commit removing *.jpg"
-(master)$ java -jar ~/Downloads/bfg.jar --delete-files *.jpg
+(main)$ git rm *.jpg
+(main)$ git commit -m "Commit removing *.jpg"
+(main)$ java -jar ~/Downloads/bfg.jar --delete-files *.jpg
 ```

 With bfg, the files that exist on your latest commit will not be affected. For example, if you had several large .tga files in your repo, and then in an earlier commit, you deleted a subset of them, this call does not touch files present in the latest commit
@ -488,7 +562,7 @@ Note, if you renamed a file as part of a commit, e.g. if it started as `LargeFil
 In the below, replace `filepattern` may be a specific name or pattern, e.g. `*.jpg`. This will remove files matching the pattern from all history and branches.

 ```sh
-(master)$ git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch filepattern' --prune-empty --tag-name-filter cat -- --all
+(main)$ git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch filepattern' --prune-empty --tag-name-filter cat -- --all
 ```

 Behind-the-scenes explanation:
@ -502,19 +576,19 @@ Behind-the-scenes explanation:
 Once you have removed your desired files, test carefully that you haven't broken anything in your repo - if you have, it is easiest to re-clone your repo to start over.
 To finish, optionally use git garbage collection to minimize your local .git folder size, and then force push.
 ```sh
-(master)$ git reflog expire --expire=now --all && git gc --prune=now --aggressive
-(master)$ git push origin --force --tags
+(main)$ git reflog expire --expire=now --all && git gc --prune=now --aggressive
+(main)$ git push origin --force --tags
 ```

 Since you just rewrote the entire git repo history, the `git push` operation may be too large, and return the error `“The remote end hung up unexpectedly”`. If this happens, you can try increasing the git post buffer:
 ```sh
-(master)$ git config http.postBuffer 524288000
-(master)$ git push --force
+(main)$ git config http.postBuffer 524288000
+(main)$ git push --force
 ```

 If this does not work, you will need to manually push the repo history in chunks of commits. In the command below, try increasing `<number>` until the push operation succeeds.
 ```sh
-(master)$ git push -u origin HEAD~<number>:refs/head/master --force
+(main)$ git push -u origin HEAD~<number>:refs/head/main --force
 ```
 Once the push operation succeeds the first time, decrease `<number>` gradually until a conventional `git push` succeeds.

@ -561,6 +635,24 @@ will do the rest of the work for you.

 ## Staging

+<a href="#i-want-to-stage-all-tracked-files-and-leave-untracked-files"></a>
+
+### I want to stage all tracked files and leave untracked files
+
+```sh
+$ git add -u
+```
+
+#### To stage part of tracked files
+
+```sh
+# to stage files with ext .txt
+$ git add -u *.txt
+
+# to stage all files inside directory src
+$ git add -u src/
+```
+
 <a href="#i-need-to-add-staged-changes-to-the-previous-commit"></a>
 ### I need to add staged changes to the previous commit

@ -574,7 +666,6 @@ If you already know you don't want to change the commit message, you can tell gi
 (my-branch*)$ git commit --amend -C HEAD
 ```

-
 <a name="commit-partial-new-file"></a>
 ### I want to stage part of a new file, but not the whole file

@ -645,7 +736,7 @@ If you want to discard all your local staged and unstaged changes, you can do th
 ```sh
 (my-branch)$ git reset --hard
 # or
-(master)$ git checkout -f
+(main)$ git checkout -f
 ```

 This will unstage all files you might have staged with `git add`:
@ -783,7 +874,7 @@ $ git checkout -b <branch> <SHA1_OF_COMMIT>
 This is another chance to use `git reflog` to see where your HEAD pointed before the bad 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
 ```
@ -811,44 +902,44 @@ Confirm that you haven't pushed your changes to the server.
 #
 ```

-One way of resetting to match origin (to have the same as what is on the remote) is to do this:
+One way of resetting branch `my-branch` to match `origin/my-branch` (to have the same as what is on the remote) is to do this:

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

 <a name="commit-wrong-branch"></a>
-### I committed to master instead of a new branch
+### I committed to main instead of a new branch

-Create the new branch while remaining on master:
+Create the new branch while remaining on main:

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

-Reset the branch master to the previous commit:
+Reset the branch main to the previous commit:

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

 `HEAD^` is short for `HEAD^1`. This stands for the first parent of `HEAD`, similarly `HEAD^2` stands for the second parent of the commit (merges can have 2 parents).

 Note that `HEAD^2` is **not** the same as `HEAD~2` (see [this link](http://www.paulboxley.com/blog/2011/06/git-caret-and-tilde) for more information).

-Alternatively, if you don't want to use `HEAD^`, find out what the commit hash you want to set your master branch to (`git log` should do the trick). Then reset to that hash. `git push` will make sure that this change is reflected on your remote.
+Alternatively, if you don't want to use `HEAD^`, find out what the commit hash you want to set your main branch to (`git log` should do the trick). Then reset to that hash. `git push` will make sure that this change is reflected on your remote.

-For example, if the hash of the commit that your master branch is supposed to be at is `a13b85e`:
+For example, if the hash of the commit that your main branch is supposed to be at is `a13b85e`:

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

 Checkout the new branch to continue working:

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

 <a name="keep-whole-file"></a>
@ -891,10 +982,10 @@ Note: Spike solutions are made to analyze or solve the problem. These solutions
 <a name="cherry-pick"></a>
 ### I made several commits on a single branch that should be on different branches

-Say you are on your master branch. Running `git log`, you see you have made two commits:
+Say you are on your main branch. Running `git log`, you see you have made two commits:

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

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

 Let's take note of our commit hashes for each bug (`e3851e8` for #21, `5ea5173` for #14).

-First, let's reset our master branch to the correct commit (`a13b85e`):
+First, let's reset our main branch to the correct commit (`a13b85e`):

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

 Now, we can create a fresh branch for our bug #21:

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

@ -939,11 +1030,11 @@ Now, let's *cherry-pick* the commit for bug #21 on top of our branch. That means

 At this point, there is a possibility there might be conflicts. See the [**There were conflicts**](#merge-conflict) section in the [interactive rebasing section above](#interactive-rebase) for how to resolve conflicts.

-Now let's create a new branch for bug #14, also based on master
+Now let's create a new branch for bug #14, also based on main

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

@ -955,6 +1046,7 @@ And finally, let's cherry-pick the commit for bug #14:

 <a name="delete-stale-local-branches"></a>
 ### I want to delete local branches that were deleted upstream
+
 Once you merge a pull request on GitHub, it gives you the option to delete the merged branch in your fork. If you aren't planning to keep working on the branch, it's cleaner to delete the local copies of the branch so you don't end up cluttering up your working checkout with a lot of stale branches.

 ```sh
@ -969,7 +1061,7 @@ where, `upstream` is the remote you want to fetch from.
 If you're regularly pushing to remote, you should be safe most of the time. But still sometimes you may end up deleting your branches. Let's say we create a branch and create a new file:

 ```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
@ -999,31 +1091,31 @@ Date:   Tue Jul 29 13:14:46 2014 -0400
    Fixes #6: Force pushing after amending commits
 ```

-Now we're switching back to master and 'accidentally' removing our branch.
+Now we're switching back to main and 'accidentally' removing our 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!
 ```

 At this point you should get familiar with 'reflog', an upgraded logger. It stores the history of all the action in the 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
 ```

 As you can see we have commit hash from our deleted branch. Let's see if we can restore our deleted 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
@ -1038,25 +1130,25 @@ Voila! We got our removed file back. `git reflog` is also useful when rebasing g
 To delete a remote branch:

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

 You can also do:

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

 To delete a local branch:

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

 To delete a local branch that *has not* been merged to the current branch or an upstream:

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

 ### I want to delete multiple branches
@ -1064,7 +1156,7 @@ To delete a local branch that *has not* been merged to the current branch or an
 Say you want to delete all branches that start with `fix/`:

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

 ### I want to rename a branch
@ -1072,13 +1164,19 @@ Say you want to delete all branches that start with `fix/`:
 To rename the current (local) branch:

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

 To rename a different (local) branch:

 ```sh
-(master)$ git branch -m old-name new-name
+(main)$ git branch -m old-name new-name
+```
+
+To delete the `old-name` remote branch and push the `new-name` local branch:
+
+```sh
+(main)$ git push origin :old_name new_name
 ```

 <a name="i-want-to-checkout-to-a-remote-branch-that-someone-else-is-working-on"></a>
@ -1087,13 +1185,13 @@ To rename a different (local) branch:
 First, fetch all branches from remote:

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

 Say you want to checkout to `daves` from the remote.

 ```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'
 ```
@ -1146,14 +1244,14 @@ By checking your remote branches, you can see which remote branch your HEAD is t
 ```sh
 $ git branch -r
  origin/HEAD -> origin/gh-pages
-  origin/master
+  origin/main
 ```

-To change `origin/HEAD` to track `origin/master`, you can run this command:
+To change `origin/HEAD` to track `origin/main`, you can run this command:

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

 ### I made changes on the wrong branch
@ -1166,6 +1264,21 @@ You've made uncommitted changes and realise you're on the wrong branch. Stash ch
 (correct_branch)$ git stash apply
 ```

+<a name="i-want-to-split-a-branch-into-two"></a>
+### I want to split a branch into two
+
+You've made a lot of commits on a branch and now want to separate it into two, ending with a branch up to an earlier commit and another with all the changes.
+
+Use `git log` to find the commit where you want to split. Then do the following:
+
+```sh
+(original_branch)$ git checkout -b new_branch
+(new_branch)$ git checkout original_branch
+(original_branch)$ git reset --hard <sha1 split here>
+```
+
+If you had previously pushed the `original_branch` to remote, you will need to do a force push. For more information check [Stack Overflow](https://stackoverflow.com/questions/28983458/how-to-split-a-branch-in-two-with-git/28983843#28983843)
+
 ## Rebasing and Merging

 <a name="undo-rebase"></a>
@ -1183,10 +1296,10 @@ You may have merged or rebased your current branch with a wrong branch, or you c
 Unfortunately, you have to force push, if you want those changes to be reflected on the remote branch. This is because you have changed the history. The remote branch won't accept changes unless you force push. This is one of the main reasons many people use a merge workflow, instead of a rebasing workflow - large teams can get into trouble with developers force pushing. Use this with caution. A safer way to use rebase is not to reflect your changes on the remote branch at all, and instead to do the following:

 ```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
 ```

 For more, see [this SO thread](https://stackoverflow.com/questions/11058312/how-can-i-use-git-rebase-without-requiring-a-forced-push).
@ -1194,23 +1307,23 @@ For more, see [this SO thread](https://stackoverflow.com/questions/11058312/how-
 <a name="interactive-rebase"></a>
 ### I need to combine commits

-Let's suppose you are working in a branch that is/will become a pull-request against `master`. In the simplest case when all you want to do is to combine *all* commits into a single one and you don't care about commit timestamps, you can reset and recommit. Make sure the master branch is up to date and all your changes committed, then:
+Let's suppose you are working in a branch that is/will become a pull-request against `main`. In the simplest case when all you want to do is to combine *all* commits into a single one and you don't care about commit timestamps, you can reset and recommit. Make sure the main branch is up to date and all your changes committed, then:

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

 If you want more control, and also to preserve timestamps, you need to do something called an interactive rebase:

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

 If you aren't working against another branch you'll have to rebase relative to your `HEAD`. If you want to squash the last 2 commits, for example, you'll have to rebase against `HEAD~2`. For the last 3, `HEAD~3`, etc.

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

 After you run the interactive rebase command, you will see something like this in your  text editor:
@ -1270,7 +1383,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
@ -1281,20 +1394,20 @@ Newer, awesomer features
 If everything is successful, you should see something like this:

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

 #### Safe merging strategy
 `--no-commit` performs the merge but pretends the merge failed and does not autocommit, giving the user a chance to inspect and further tweak the merge result before committing. `no-ff` maintains evidence that a feature branch once existed, keeping project history consistent.

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

 #### I need to merge a branch into a single commit

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

 <a name="rebase-unpushed-commits"></a>
@ -1303,7 +1416,7 @@ If everything is successful, you should see something like this:
 Sometimes you have several work in progress commits that you want to combine before you push them upstream. You don't want to accidentally combine any commits that have already been pushed upstream because someone else may have already made commits that reference them.

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

 This will do an interactive rebase that lists only the commits that you haven't already pushed, so it will be safe to reorder/fix/squash anything in the list.
@ -1320,7 +1433,7 @@ This command is available since Git version >= 1.7.4

 ### I need to update the parent commit of my branch

-Say I have a master branch, a feature-1 branch branched from master, and a feature-2 branch branched off of feature-1. If I make a commit to feature-1, then the parent commit of feature-2 is no longer accurate (it should be the head of feature-1, since we branched off of it). We can fix this with `git rebase --onto`.
+Say I have a main branch, a feature-1 branch branched from main, and a feature-2 branch branched off of feature-1. If I make a commit to feature-1, then the parent commit of feature-2 is no longer accurate (it should be the head of feature-1, since we branched off of it). We can fix this with `git rebase --onto`.

 ```sh
 (feature-2)$ git rebase --onto feature-1 <the first commit in your feature-2 branch that you don't want to bring along> feature-2
@ -1333,13 +1446,13 @@ This helps in sticky scenarios where you might have a feature built on another f
 To check if all commits on a branch are merged into another branch, you should diff between the heads (or any commits) of those 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
 ```

 This will tell you if any commits are in one but not the other, and will give you a list of any nonshared between the branches. Another option is to do this:

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

 ### Possible issues with interactive rebases
@ -1354,7 +1467,7 @@ noop

 That means you are trying to rebase against a branch that is at an identical commit, or is *ahead* of your current branch. You can try:

-* making sure your master branch is where it should be
+* making sure your main branch is where it should be
 * rebase against `HEAD~2` or earlier instead

 <a name="merge-conflict"></a>
@ -1389,7 +1502,7 @@ You will need to resolve the differences between the code that was added in your
 If you want to keep one branch's version of the code, you can use `--ours` or `--theirs`:

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

 - When *merging*, use `--ours` to keep changes from the local branch, or `--theirs` to keep changes from the other branch.
@ -1398,7 +1511,7 @@ If you want to keep one branch's version of the code, you can use `--ours` or `-
 If the merges are more complicated, you can use a visual diff editor:

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

 After you have resolved all conflicts and tested your code, `git add` the files you have changed, and then continue the rebase with `git rebase --continue`
@ -1591,6 +1704,12 @@ $ rm -rf .git/modules/submodulename

 ## Miscellaneous Objects

+### Copy a folder or file from one branch to another
+
+```sh
+$ git checkout <branch-you-want-the-directory-from> -- <folder-name or file-name>
+```
+
 ### Restore a deleted file

 First find the commit when the file last existed:
@ -1642,7 +1761,7 @@ From github.com:foo/bar
 ### Exporting a repository as a Zip file

 ```sh
-$ git archive --format zip --output /full/path/to/zipfile.zip master
+$ git archive --format zip --output /full/path/to/zipfile.zip main
 ```
 ### Push a branch and a tag that have the same name

@ -1672,21 +1791,21 @@ $ git push origin refs/tags/<tag-name>
 ### I want to change a file name's capitalization, without changing the contents of the file

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

 ### I want to overwrite local files when doing a 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>
 ### I want to remove a file from Git but keep the file

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

 ### I want to revert a file to a specific revision
@ -1694,13 +1813,13 @@ $ git push origin refs/tags/<tag-name>
 Assuming the hash of the commit you want is c5f567:

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

 If you want to revert to changes made just 1 commit before c5f567, pass the commit hash as 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
 ```

 ### I want to list changes of a specific file between commits or branches
@ -1709,12 +1828,16 @@ Assuming you want to compare last commit with file from commit c5f567:

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

-Same goes for branches:
+If you are going to compare changes between the tips of the `main` and the `staging` 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
+# or
+$ git diff main staging -- path_to_file/file
 ```

 ### I want Git to ignore changes to a specific file
@ -1735,7 +1858,7 @@ $ git update-index --no-assume-unchanged file-to-stop-ignoring

 The [git-bisect](https://git-scm.com/docs/git-bisect) command uses a binary search to find which commit in your Git history introduced a bug.

-Suppose you're on the `master` branch, and you want to find the commit that broke some feature. You start bisect:
+Suppose you're on the `main` branch, and you want to find the commit that broke some feature. You start bisect:

 ```sh
 $ git bisect start
@ -1794,7 +1917,7 @@ On OS X and Linux, your git configuration file is stored in ```~/.gitconfig```.
    wip = rebase -i @{u}
    zap = fetch -p
    day = log --reverse --no-merges --branches=* --date=local --since=midnight --author=\"$(git config --get user.name)\"
-    delete-merged-branches = "!f() { git checkout --quiet master && git branch --merged | grep --invert-match '\\*' | xargs -n 1 git branch --delete; git checkout --quiet @{-1}; }; f"
+    delete-merged-branches = "!f() { git checkout --quiet main && git branch --merged | grep --invert-match '\\*' | xargs -n 1 git branch --delete; git checkout --quiet @{-1}; }; f"
 ```

 ### I want to add an empty directory to my repository
@ -1830,6 +1953,7 @@ $ git config --global credential.helper cache
 $ git config --global credential.helper 'cache --timeout=3600'
 # Set the cache to timeout after 1 hour (setting is in seconds)
 ```
+
 To find a credential helper:

 ```sh
@ -1882,14 +2006,6 @@ To set an email address that will be associated with each history marker:
 git config --global user.email “[valid-email]”
 ```

-### I want to add command line coloring for Git
-
-To set automatic command line coloring for Git for easy reviewing:
-
-```sh
-$ git config --global color.ui auto
-```
-
 ## I've no idea what I did wrong

 So, you're screwed - you `reset` something, or you merged the wrong branch, or you force pushed and now you can't find your commits. You know, at some point, you were doing alright, and you want to go back to some state you were at.
@ -1897,21 +2013,21 @@ So, you're screwed - you `reset` something, or you merged the wrong branch, or y
 This is what `git reflog` is for. `reflog` keeps track of any changes to the tip of a branch, even if that tip isn't referenced by a branch or a tag. Basically, every time HEAD changes, a new entry is added to the reflog. This only works for local repositories, sadly, and it only tracks movements (not changes to a file that weren't recorded anywhere, for instance).

 ```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
 ```

-The reflog above shows a checkout from master to the 2.2 branch and back. From there, there's a hard reset to an older commit. The latest activity is represented at the top labeled `HEAD@{0}`.
+The reflog above shows a checkout from main to the 2.2 branch and back. From there, there's a hard reset to an older commit. The latest activity is represented at the top labeled `HEAD@{0}`.

-If it turns out that you accidentally moved back, the reflog will contain the commit master pointed to (0254ea7) before you accidentally dropped 2 commits.
+If it turns out that you accidentally moved back, the reflog will contain the commit main pointed to (0254ea7) before you accidentally dropped 2 commits.

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

-Using `git reset` it is then possible to change master back to the commit it was before. This provides a safety net in case history was accidentally changed.
+Using `git reset` it is then possible to change main back to the commit it was before. This provides a safety net in case history was accidentally changed.

 (copied and edited from [Source](https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog)).

--- 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,7 +1061,7 @@ 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.
@ -1071,7 +1070,7 @@ Si deseas conservar la versión del código de una rama, puedes usar `--us` o` -
 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 :
@ -240,7 +239,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).
@ -288,13 +287,13 @@ 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.
@ -420,7 +419,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` :
@ -556,7 +555,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
 ```
@ -577,7 +576,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 +586,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 +663,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 +689,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 +711,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)$
 ```

@ -743,7 +741,7 @@ où `upstream` est le dépôt distant depuis lequel vous voulez mettre à jour.
 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 +771,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 +810,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 +836,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,13 +844,13 @@ 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>
@ -861,13 +859,13 @@ Pour renommer une autre branche (locale) :
 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'
 ```
@ -920,14 +918,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 +955,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 +966,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 +1042,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 +1053,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 +1075,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 +1092,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 +1126,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,7 +1161,7 @@ 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.
@ -1172,7 +1170,7 @@ Si vous voulez garder la version du code d'une des branches, vous pouvez utilise
 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` :
@ -1356,7 +1354,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 +1382,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

@ -1414,21 +1412,21 @@ $ git push origin refs/tags/<nom-du-tag>
 ### 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>
 ### 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 +1434,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 +1449,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 +1566,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 +1573,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]
 ```

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

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

@ -158,10 +157,10 @@ $ git clone [url] name-of-new-folder
 `git commit -a` 로 막 커밋을 남기고 내가 뭐라고 안에 적었더라? 한다고 하고. 최근의 커밋을 현재 HEAD에서 볼 수 있어요.

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

-또는 
+또는

 ```sh
 $ git log -n1 -p
@ -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>
@ -279,7 +278,7 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.
 ```

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

 절대로 아무도 같은 브랜치를 안 쓰거나, 절대로 브랜치에 업데이트를 해야할때 `--force` (`-f`) 옵션을 쓸 수 있지만 일반적으론 피하는게 좋아요.
@ -287,18 +286,18 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.
 <a href="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
 ```

 계속 할 수 있을거에요.
@ -308,14 +307,14 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.

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

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

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

 알아두기 : 부모 번호는 커밋 식별자가 아니고, 오히려 머지된 커밋이 `Merge: 8e2ce2d 86ac2e7` 이라는 라인을 가지고 있어요.
 부모 번호는 이 라인에서 원하는 부모의 1 기반 인덱스이고, 첫번째 식별자는 1, 다음은 2 이렇게 이어져요.
@ -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
@ -354,7 +353,7 @@ $ git add -N filename.x
 <a href="unstaging-edits-and-staging-the-unstaged"></a>
 ### 아직 스테이지에 안 올라간 변경점을 스테이지에 추가하고, 스테이지에 있는 변경점을 다시 빼고 싶어

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

 ```sh
 $ git stash -k
@ -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
@ -476,7 +475,7 @@ $ git checkout .
 <a href="i-want-to-discard-all-my-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
@ -535,7 +534,7 @@ $ git reset --hard c5bc55a

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

-`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
@ -707,7 +706,7 @@ $ git fetch -p upstream
 주기적으로 리모트으로 푸시한다면, 대부분은 안전해야 해요. 그치만 가끔은 브랜치를 지울 수 있어요. 새 브랜치를 만들고 파일을 하나 만들었다고 해보죠:

 ```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>
 ### 다른 사람이 작업중인 리모트 브랜치로 체크아웃 하고 싶어

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

 ```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'
 ```
@ -886,14 +885,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 +924,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 +940,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 +989,11 @@ pick e3851e8 another fix
 # Note that empty commits are commented out
 ```

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

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

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

 ```vim
 pick a9c8a1d Some refactoring
@ -1020,7 +1019,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 +1029,7 @@ Newer, awesomer features
 전부 다 성공하면, 이런 메세지를 볼거에요:

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

 #### 안전한 머지 전략
@ -1040,13 +1039,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 +1055,10 @@ Newer, awesomer features
 다른 누군가가 벌써 참고해서 커밋을 만들고 있을테니 이미 푸시된 커밋을 잘못 합치길 바라진 않을거에요.

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

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

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

@ -1076,13 +1075,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
 ```

 ### 대화형 리베이스로 발생가능한 이슈
@ -1107,7 +1106,7 @@ noop

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

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

 ```sh
 (my-branch)$ git status
@ -1134,16 +1133,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#git-rebase---merge)를 보세요.

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

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

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

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

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

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

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

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

@ -1263,7 +1262,7 @@ $ git log -- <path to file>
 $ git log -- **/*.js
 ```

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

 ```sh
 $ git log --name-status -- **/*.js
@ -1315,7 +1314,7 @@ $ rm -rf .git/modules/submodulename
 $ git rev-list -n 1 HEAD -- filename
 ```

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

 ```
 git checkout deletingcommitid^ -- filename
@ -1362,7 +1361,7 @@ 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
 ```

 ## 파일 추적하기
@ -1372,21 +1371,21 @@ $ git archive --format zip --output /full/path/to/zipfile.zip master
 ### 파일 내용엔 변경이 없이 파일 이름을 앞글자만 대문자로 바꾸고 싶어

 ```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>
 ### 파일을 로컬에는 보관하고 깃에서 지우고 싶어

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

 ### 특정한 버전대로 파일을 복구하고 싶어
@ -1394,13 +1393,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 +1409,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 +1452,7 @@ $ git diff master:path_to_file/file staging:path_to_file/file

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

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

 ```
 # Ignore everything in this directory
@ -1483,13 +1486,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 +1500,7 @@ $ git config --global core.fileMode false

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

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

 ```sh
 $ git config --global user.name “[firstname lastname]”
@ -1509,26 +1512,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 +1537,7 @@ $ git reset --hard 0254ea7
 ```

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

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

@ -1581,7 +1576,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
 ```

 或者
@ -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)。
@ -208,13 +207,13 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.
 如果你意外的做了 `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
 ```

 这样就完成了。
@ -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
 ```

 重置某个特殊的文件, 你可以用文件名做为参数:
@ -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
 ```
@ -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)$
 ```

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

 ```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
@ -597,19 +596,19 @@ 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
 ```

 <a name="i-want-to-checkout-to-a-remote-branch-that-someone-else-is-working-on"></a>
@ -618,13 +617,13 @@ README.md foo.txt
 首先, 从远程拉取(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。
@ -985,14 +984,14 @@ $ git update-ref refs/tags/<tag_name> <hash>
 ### 我只想改变一个文件名字的大小写，而不修改内容

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

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

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

 ## 配置(Configuration)
@ -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
lumynou5	ad82e06b32	Fix links for zh-TW	2023-06-25 15:00:06 +08:00
lumynou5	ee2b977217	Sync "Other Resources" with en for zh-TW	2023-06-25 14:55:44 +08:00
lumynou5	9766b3714e	Sync "Git Shortcuts" with en for zh-TW	2023-06-25 14:32:28 +08:00
lumynou5	fcc7508195	Sync "Configuration" with en for zh-TW	2023-06-24 11:34:34 +08:00
lumynou5	e275970496	Sync "Debugging with Git" with en for zh-TW	2023-06-24 11:06:05 +08:00
lumynou5	02f590f2e6	Sync "Tracking Files" with en for zh-TW	2023-06-24 10:48:30 +08:00
lumynou5	21ff580f4d	Sync "Miscellaneous Objects" with en for zh-TW	2023-06-23 16:24:14 +08:00
lumynou5	589f1e474e	Sync "Submodules" with en for zh-TW	2023-06-23 15:59:41 +08:00
lumynou5	bee4819794	Sync "Finding" with en for zh-TW	2023-06-23 15:53:41 +08:00
lumynou5	7c4841b91e	Sync "Stash" with en for zh-TW	2023-06-23 14:50:11 +08:00
lumynou5	4b209049d9	Unify word "Stack Overflow" with space for zh-TW Because the title of the website has a space.	2023-06-22 16:16:25 +08:00
lumynou5	5226b2985e	Sync "Rebasing and Merging" with en for zh-TW	2023-06-22 16:14:57 +08:00
lumynou5	45fe7228fb	Sync "Branches" with en for zh-TW	2023-06-21 17:15:38 +08:00
lumynou5	340790ad57	Sync "Unstaged Edits" with en for zh-TW	2023-06-20 15:56:39 +08:00
lumynou5	847ecf5b1a	Sync "Staging" with en for zh-TW	2023-06-16 11:04:31 +08:00
lumynou5	924e14f0eb	Sync "Editting Commits" with en for zh-TW Translate and add missing contents.	2023-06-13 01:45:57 +08:00
lumynou5	80b2f2e260	Sync "Repositories" with en for zh-TW This adds the missing chapter in zh-TW.	2023-06-10 01:34:27 +08:00
lumynou5	70e72e95c5	Translate untranslated for zh-TW	2023-06-10 01:34:27 +08:00
lumynou5	1368e078d4	Correct word for zh-TW	2023-06-10 01:34:27 +08:00
lumynou5	a29cce33e0	Reformat for zh-TW	2023-06-10 01:34:27 +08:00
lumynou5	567712427c	Correct terms for zh-TW This makes all terms match with the official translations Git uses and keep the consistency of the translations.	2023-06-10 01:34:27 +08:00
lumynou5	eceaab46b6	Change trnaslation of "prompt" for zh-TW Use "提示字元" to match with the wording of Microsoft.	2023-06-10 01:34:27 +08:00
lumynou5	129f987523	Correct word for zh-TW The original contains unconventional words "文件", and it should be "檔案" to refer to "file" in zh-TW.	2023-06-10 01:34:27 +08:00
lumynou5	6a51685003	Improve sentences for zh-TW This makes the sentences more readable.	2023-06-10 01:34:27 +08:00
lumynou5	73e2f36610	Remove unnecessary anchors for zh-TW Because the table of contents is generated by DocToc, it doesn't need anchors for each sections actually.	2023-06-10 01:34:04 +08:00
lumynou5	f7dbe43636	Correct case for zh-TW	2023-06-05 13:15:50 +08:00
lumynou5	13918894cf	Correct use of punctuations for zh-TW	2023-06-05 13:14:53 +08: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