Merge pull request #75 from doggy8088/copilot/create-proofreading-plan

English translation proofreading: Complete review and quality enhancements (100%)

Author: doggy8088

en/02.md

@@ -1,10 +1,8 @@
-Day 02: Three Essential Git Tools for Windows Platform
-==========================================
+# Day 02: Three Essential Git Tools for Windows Platform
 
 To start using Git version control, you first need to install appropriate Git tools. This series of articles mainly focuses on the Windows platform. This article will introduce three Git version control tools we use most often, introduce the similarities and differences between these tools, and when to use which tool.
 
-First Tool: [Git for Windows](https://msysgit.github.io/)
----------------------------------------------
+## First Tool: [Git for Windows](https://msysgit.github.io/)
 
 This is a set of command-line tools that can be executed in the **Command Prompt**. Currently, all GUI tools for Git on the market actually execute these lower-level Git tools internally, so it is an essential Git management tool that must be installed!
 
@@ -66,8 +64,7 @@ Below is the installation process:
 
 ![image](figures/02/114.png)
 
-Second Tool: [GitHub for Windows](https://windows.github.com/)
----------------------------------------------
+## Second Tool: [GitHub for Windows](https://windows.github.com/)
 
 This is a tool officially developed by [GitHub](https://github.com) for people who don't have a deep understanding of Git. It uses a simple and friendly GUI interface, attempting to hide those hard-to-understand concepts and command parameters of Git. Although the GitHub for Windows tool is much more friendly than Git for Windows, for people who have no concept of Git at all, getting started with the GitHub for Windows tool may not be easy.
 
@@ -117,8 +114,7 @@ Below is the GitHub for Windows installation process:
 
 ![image](figures/02/206.png)
 
-Third Tool: [SourceTree](https://www.sourcetreeapp.com/)
----------------------------------------------
+## Third Tool: [SourceTree](https://www.sourcetreeapp.com/)
 
 [SourceTree](https://www.sourcetreeapp.com/) is currently a tool I highly recommend that can support Windows and Mac platforms. This tool is a GUI tool developed by Atlassian (the company that makes JIRA, Confluence, Bamboo) and is provided free of charge. With this tool, almost all Git version control work can be done (including git-flow workflow), which is a very powerful Git version control tool.
 

en/10.md

@@ -14,9 +14,9 @@ If we want to see the content of the commit object in the above figure, we can u
 
 ## Short Syntax for Object Absolute Names
 
-Since the Git object id is the result of SHA1 hashing of the content, it is very long. When marking the "absolute name" in Git, you can use the first few codes instead, with a minimum of not less than 4 characters. This means that "absolute names" of 4 to 40 characters in length can all be used.
+Since the Git object id is the result of SHA1 hashing of the content, it is quite long (40 characters). When specifying the "absolute name" in Git, you can use just the first few characters instead, with a minimum of 4 characters. This means that "absolute names" between 4 to 40 characters in length can all be used to identify an object.
 
-For example, we can also see from the above figure that the content of this commit object contains a tree object, which also has an absolute name of the tree object `07c1321be49815d53eb2413f0ad5286010ebb6cc`. So I can also use `git cat-file -p treeid` again to get the content of that tree object, as shown in the following figure:
+For example, we can also see from the above figure that the content of this commit object contains a tree object, which also has an absolute name of `07c1321be49815d53eb2413f0ad5286010ebb6cc`. So I can also use `git cat-file -p treeid` again to get the content of that tree object, as shown in the following figure:
 
 ![image](figures/10/03.png)
 

en/11.md

@@ -4,9 +4,9 @@ After understanding the "absolute names" of Git objects, next we will introduce
 
 ## Understanding Object Reference Names
 
-Reference names (ref) are simply a "pointer" to Git objects, or another "memorable name" relative to "absolute names," using a predefined or your own defined name to represent a certain Git object.
+Reference names (ref) are simply a "pointer" to Git objects, or another "memorable name" compared to "absolute names." They use a predefined or user-defined name to represent a specific Git object.
 
-The "branch names" we learned before or the HEAD we have used (representing the latest version), or the "tag names" we will learn later, these are all "reference names," in short, to help you remember.
+The "branch names" we learned before, the HEAD we have used (representing the latest version), or the "tag names" we will learn later - these are all "reference names," essentially created to make things easier to remember.
 
 We will use "branch names" as an example to explain what the physical structure of "reference names" is. In the following figure, we use `git branch` to get all branch names. You can see that we currently have three branches. However, these three branch names are actually "reference names," which means these three "reference names" correspond to three commit objects in the Git object repository. In the following figure, you can also see that these branch reference names are actually just files. All "local branch" reference names are located in the `.git\refs\heads` directory:
 

en/12.md

@@ -1,10 +1,10 @@
 # Day 12: Understanding Git Object Relative Names
 
-After understanding the "absolute names" and "reference names" of Git objects, finally we will introduce "relative names" that are also commonly used in the Git version control process.
+After understanding the "absolute names" and "reference names" of Git objects, we will now introduce "relative names," which are also commonly used in the Git version control process.
 
-Let's review again. In the Git version control process, each version represents a commit object. Each commit object has an "absolute name," which is a 40-character string obtained by SHA1 hashing the content. You can use the first 4 to 40 characters as the identification name of that commit object. During version control, you can also use "reference names" to represent a certain commit object. Each "reference name" will ultimately correspond to the "absolute name" of an object. "Reference names" are further divided into "general references" and "symbolic references." Among them, "general references" directly correspond to "absolute names," while "symbolic references" correspond to another "general reference."
+Let's review again. In Git version control, each version represents a commit object. Each commit object has an "absolute name" - a 40-character string obtained by SHA1 hashing the content. You can use the first 4 to 40 characters as the identification name of that commit object. During version control, you can also use "reference names" to represent a specific commit object. Each "reference name" ultimately corresponds to the "absolute name" of an object. "Reference names" are further divided into "general references" and "symbolic references." Among them, "general references" directly correspond to "absolute names," while "symbolic references" correspond to another "general reference."
 
-What this article will introduce is the use of "relative name" notation, which allows you to find other "commit objects" based on relative positions after finding a specific commit object.
+What this article will introduce is the use of "relative name" notation, which allows you to find other "commit objects" based on their relative positions after finding a specific commit object.
 
 ## Relative Name Notation
 

en/13.md

@@ -26,6 +26,30 @@ If you want to create a "staging version" for these half-developed files, you ha
 
 **Note**: `git stash` can also be written as `git stash save`. The result of the two commands is the same, it's just that the `save` parameter can be omitted.
 
+### Example Workflow
+
+Here's a simple practical example:
+
+```bash
+# You're working on features
+echo "new feature" > feature.txt
+git add feature.txt
+
+# Suddenly need to fix a bug
+# Stash your work-in-progress
+git stash
+
+# Now working directory is clean
+# Fix the bug on another branch
+git checkout main
+# ... make fixes ...
+git commit -m "Fix urgent bug"
+
+# Return to your feature work
+git checkout feature-branch
+git stash pop  # Restore your work
+```
+
 ## Restoring Stashed Changes
 
 After stashing your changes, you can switch to another branch or work on the urgent task. When you're ready to continue your original work, you can restore your stashed changes using:

en/14.md

@@ -1,19 +1,33 @@
 # Day 14: Git for Windows Configuration Options
 
-When using Git for Windows, there are many configuration options you can adjust to better suit your working habits and environment. This article introduces various important configuration options.
+Using Git for Windows command-line tools is definitely more efficient than operating through GUI tools. The reason is that you can automate many repetitive version control tasks through commands, or transform complex standard operating procedures (SOPs) into simple command operations. This article will share some tips for using Git for Windows command-line tools.
+
+## About Git Command-Line Tool Configuration Options
+
+In Git command-line tools, there are many "options" that can be set, just like we usually have [Tools] -> [Preferences] when using GUI tools, to fine-tune some behaviors when commands are executed. The most common, of course, is when you first use Git for Windows, you must set the `user.name` and `user.email` options. Without these two options set, you don't even have the right to execute `git commit`.
+
+To list all options currently set in Git for Windows tools, you can use the `git config --list` command.
+
+**Note**: Since most Git articles on the internet introduce how to set up Linux or Mac environments, my article will focus on Windows platform configuration. However, except for the storage path being different, the usage of commands is actually the same.
+
+If you want to check what "options" are available, you can execute `git help config` at the command prompt to display complete documentation or visit the [git-config(1) Manual Page](https://www.kernel.org/pub/software/scm/git/docs/git-config.html).
 
 ## Understanding Git Configuration Levels
 
 Git has three levels of configuration:
 
 1. **System level** (`--system`): Applies to all users on the system
    * Location: `C:\Program Files\Git\etc\gitconfig`
+   * **Important for Windows**: With UAC enabled, settings may be redirected to `%LOCALAPPDATA%\VirtualStore\Program Files\Git\etc\gitconfig`
+   * **Recommendation**: Always run Command Prompt as Administrator when setting system-level options
 
 2. **Global level** (`--global`): Applies to the current user
-   * Location: `C:\Users\[username]\.gitconfig`
+   * Location: `C:\Users\[username]\.gitconfig` or `%USERPROFILE%\.gitconfig`
+   * Commonly used for `user.name`, `user.email`, and personal preferences
 
 3. **Local level** (`--local`): Applies only to the current repository
    * Location: `.git\config` in the repository
+   * Created automatically when you initialize or clone a repository
 
 Configuration at lower levels overrides higher levels (local > global > system).
 
@@ -69,6 +83,19 @@ git config --global core.autocrlf input
 git config --global core.autocrlf false
 ```
 
+### Important: Windows UAC and VirtualStore
+
+On Windows Vista and later with User Account Control (UAC) enabled, there's an important consideration when setting system-level configuration:
+
+**The Problem**: Windows VirtualStore technology redirects file writes when non-administrator processes try to write to system directories. This means:
+- Settings made with normal Command Prompt go to `%LOCALAPPDATA%\VirtualStore\Program Files\Git\etc\gitconfig`
+- Settings made with Administrator Command Prompt go to `C:\Program Files\Git\etc\gitconfig`
+- These two locations don't sync, causing unexpected behavior
+
+**The Solution**: When setting system-level options (`--system`), always run Command Prompt as Administrator to ensure settings apply system-wide.
+
+For more information: [VirtualStore - Inside Windows Vista User Account Control](https://learn.microsoft.com/en-us/previous-versions/technet-magazine/cc138019(v=msdn.10))
+
 ## Configuring Aliases
 
 Create shortcuts for commonly used commands:

en/15.md

@@ -1,15 +1,23 @@
 # Day 15: Tags - Marking Important Events in Version Control
 
-In the process of software development, we often need to mark certain important milestones in the project, such as release versions (v1.0, v2.0, etc.). Git provides the tag feature for this purpose.
+When using Git for version control, a large number of versions will be generated. Over time, among these many versions, there will definitely be some important versions worth recording. This is what "tags" can help us do.
 
-## Understanding Tags
+## Understanding Tags - Basic Concepts
+
+Basically, the purpose of a tag is to mark a specific "version" or "commit object" with an "easy-to-remember name" to help us remember a particular version.
 
 A tag is a reference that points to a specific commit in your Git history. Unlike branches, tags don't move when you make new commits - they always point to the same commit. This makes tags ideal for marking release points or other significant milestones.
 
 Git supports two types of tags:
 
-1. **Lightweight tags**: Simply a name for a specific commit
-2. **Annotated tags**: Stored as full objects with additional metadata
+1. **Lightweight tags**: Simply a name (alias) for a specific commit - it's a type of "reference name"
+2. **Annotated tags**: Stored as full Git objects with additional metadata
+
+As mentioned in Day 11 (Understanding Git Object References), "general references" include "tag names," and the "tag name" here refers to "lightweight tags." So "lightweight tags" can be said to be just an "alias" for a certain commit version, which is a type of "relative name."
+
+"Annotated tags" are a type of Git object. As mentioned in Day 06 (Parsing Git Data Structure - Object Structure), Git objects include 4 object types: Blob, Tree, Commit, and Tag objects. The "annotated tag" mentioned here is a Tag object. Tag objects are stored in Git's object storage (stored in the `.git\objects\` directory) and are associated with another commit object. When creating "annotated tags," you can include "version messages" just like when creating commit objects. In Git's built-in tag mechanism, you can even use GnuPG keys to sign Tag objects to ensure message "non-repudiation."
+
+Although we have these two tag types, and both look like "aliases" for commit objects, the usage of these two tags only has slight differences. In most use cases, we use "annotated tags" to create "tag objects" and provide "version messages," because this type of "tag" is a "permanent object" in the Git repository. (Git objects stored in the object storage are immutable; only the index changes.)
 
 ## Creating Lightweight Tags
 
@@ -27,6 +35,17 @@ To tag a specific commit:
 git tag v0.9 <commit-hash>
 ```
 
+**Note**: All files under `.git\refs\` are "reference names."
+
+Basic usage:
+* List all tags: `git tag`
+* Create lightweight tag: `git tag [tagname]`
+* Delete lightweight tag: `git tag [tagname] -d`
+
+If you want to see the content of a "lightweight tag," you can use `git cat-file -p [tagname]`. If you want to see the object type of the "lightweight tag," you can use `git cat-file -t [tagname]`.
+
+**Important Note**: A lightweight tag is not a Git object. From the above, you can see that the tag name retrieves the content of the commit object, and the object type found by the name is a commit object.
+
 ## Creating Annotated Tags
 
 Annotated tags are recommended for most use cases because they store extra information:
@@ -37,6 +56,11 @@ git tag -a v1.0 -m "Release version 1.0"
 
 The `-a` flag creates an annotated tag, and `-m` specifies the tag message.
 
+Differences from lightweight tags:
+1. When executing `git tag` to list all tags, all tags are mixed together and you can't see the tag type
+2. Creating "annotated tags" requires the `-a` parameter
+3. Creating "annotated tags" must include a "version message," just like executing `git commit`, both have the `-m` parameter available
+
 ## Listing Tags
 
 To see all tags in your repository: