Added Chinese Translations

2026-05-13 17:21:50 +00:00 · 2025-05-13 18:19:46 +08:00
parent 28ce46db61
commit b86b03f57e
6 changed files with 395 additions and 0 deletions
@@ -0,0 +1,66 @@
+# 修改 Commit
+
+假设你已经将一个更改提交到远程仓库，但后来你发现提交信息有一个拼写错误，或者你忘记在最近的提交中添加一行。  
+你该如何编辑这个提交？这篇教程将为你解答。
+
+## 在推送到 Github 后修改最近的提交信息
+如果你不想打开文件，可以通过以下方式进行修改：
+* 输入 `git commit --amend -m "然后是你新的提交信息"`
+* 运行 `git push origin <branch-name>` 将更改提交到仓库。
+
+注意：如果只输入 `git commit --amend`，则会打开文本编辑器，提示你编辑提交信息。  
+添加 `-m` 标志可以防止这种情况。
+
+## 修改单个提交
+
+那么，如果我们忘记对文件做一个小的更改，比如更改一个单词，而且我们已经将提交推送到远程仓库了，怎么办呢？
+
+以下是我的提交日志：
+```
+g56123f 创建 bot 文件
+a2235d 更新 contributor.md
+a5da0d 修改 bot 文件
+```
+假设我忘记在 bot 文件中添加一个单词。
+
+有两种方法可以解决这个问题。第一种方法是创建一个包含更改的新提交，如下所示：
+```
+g56123f 创建 bot 文件
+a2235d 更新 contributor.md
+a5da0d 修改 bot 文件
+b0ca8f 添加 bot 文件中的单词
+```
+第二种方法是修改 `a5da0d` 提交，添加这个新单词，并将其作为一个提交推送到 Github。  
+第二种方法更好，因为这只是一个小改动。
+
+为了实现这一点，我们可以按照以下步骤操作：
+* 修改文件。在本例中，我会修改 bot 文件，加入之前遗漏的单词。
+* 接下来，使用 `git add <filename>` 将文件添加到暂存区。
+
+通常，在将文件添加到暂存区之后，我们会运行 git commit -m "我们的提交信息"`, 对吧？  
+但由于我们希望修改的是上一个提交，我们应该运行：
+
+* `git commit --amend`  
+  这会打开文本编辑器，提示你编辑提交信息。你可以选择保留原来的信息，也可以修改它。
+* 退出编辑器
+* 使用 `git push origin <branch-name>` 推送更改
+
+这样，两个更改就会合并为一个提交。
+
+## 修改远程提交
+
+如果你想修改的提交已经推送到远程，修改该提交将导致你的本地历史与远程分支不同步（因为你实际上创建了一个新提交并替换了已修改的提交）。  
+由于你希望更改远程的提交，你需要覆盖远程仓库中的历史记录。为了实现这一点，请按照上述相同的步骤操作，但在推送提交到远程时使用强制推送。
+
+> **警告**  
+> 强制推送到远程将覆盖（并丢弃）远程上的更改，只保留你推送的提交。其他团队成员在此期间对远程的更改也将被覆盖。
+
+这是如何修改远程仓库中最后一次提交的方法：
+
+```bash
+git add <your changed files>
+git commit --amend -m "然后是你的新提交信息"
+git push --force
+```
+
+>使用 `--force-with-lease` 比 `--force` 更安全，它可以避免覆盖远程分支上其他人的更改（如果你不打算这么做）。
@@ -0,0 +1,37 @@
+# 查看提交日志
+
+为了查看某个分支或某个文件的提交日志，可以使用以下命令：
+
+`git log [options] [path]`
+
+该命令的输出默认按逆时间顺序排列。
+
+## 命令输出示例
+```
+$ git log
+commit e3fabb30ab536bd5876461d8a749301a321e714f (HEAD -> check-commit-log-ko, upstream/main, origin/main, origin/HEAD, main)
+Author: Dan Yunheum Seol yunheum.seol@mail.mcgill.ca
+Date: Tue Jun 4 01:07:25 2024 -0400
+
+    Add dan-seol to Contributors list (#84962)
+
+commit 4af4ec8a56e057ce8768af77eda528453974d0bc
+Author: Edgar Humberto Tijerina Tamez <168693312+EdgarHTT@users.noreply.github.com>
+Date:   Mon Jun 3 23:06:05 2024 -0600
+
+    Add Edgar Tijerina to Contributors list (#84961)
+```
+
+
+## 命令变体和选项
+- 若要查看从某些特定提交 ids: <i>（例如 `foo` 和 `bar`）可达的提交，可以使用：</i><br>
+    `git log foo bar `
+- 也可以通过在提交 id 前添加 `^` 来排除某个提交<i>（例如 `baz`）：</i><br>
+    `git log foo bar ^baz`
+- 查看特定文件的提交日志：<br>
+    `git log --all <filename>`
+- 限制日志中提交的数量：<i>（例如 `5`）</i><br> 
+    `git log -n 5`
+
+## 参考
+- [官方文档](https://git-scm.com/docs/git-log)
@@ -0,0 +1,78 @@
+# 配置 git
+
+第一次使用 git 提交时，你可能会看到如下提示：
+
+```bash
+$ git commit
+*** 请告诉我你是谁。
+
+运行
+
+git config --global user.email "you@example.com"
+git config --global user.name "Your Name"
+
+来设置你账户的默认身份。
+如果只想在当前仓库设置身份，省略 --global。
+```
+
+Git 在创建提交时需要知道你是谁。当你在团队中协作时，你应该能够看到是谁修改了项目的哪些部分以及何时修改的，因此，Git 设计时就要求每个提交都与一个名字和电子邮件地址相关联。
+
+有多种方法可以为 `git commit` 命令提供你的电子邮件和用户名，下面我们将介绍几种常用的方法。
+
+### 全局配置 
+
+当你将某个配置存储在全局配置中时，它在你工作的所有仓库中都是可访问的。这是推荐的方式，并且适用于大多数使用场景。
+
+要将某个配置存储在全局配置中，你可以使用以下 `config` 命令：
+
+`$ git config --global <variable name> <value>`
+
+对于用户信息，我们可以运行：
+
+```
+$ git config --global user.email "you@example.com"
+$ git config --global user.name "Your Name"
+```
+
+### 仓库配置
+
+顾名思义，这些配置仅作用于当前仓库。如果你想在某个特定仓库中提交，例如工作项目，并使用你公司的电子邮件地址，你可以使用这种方法。
+
+要将某个配置存储在仓库配置中，可以在 `config` 命令中省略 `--global` 标志，如下所示：
+
+`$ git config <variable name> <value>`
+
+对于用户信息，我们可以运行：
+
+```
+$ git config user.email "you@alternate.com"
+$ git config user.name "Your Name"
+```
+
+### 命令行配置
+
+这些配置仅作用于当前命令。所有 git 命令在动作动词之前都可以使用 `-c` 参数来设置临时配置数据。
+
+要在命令行配置中存储某个配置，按如下方式运行命令：
+
+`$ git -c <variable-1>=<value> -c <variable-2>=<variable> <command>`
+
+在我们的例子中，我们将提交命令改为：
+
+`git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"`
+
+### 配置优先级说明
+
+在这里描述的三种方法中，优先级顺序是 `command-line > repository > global`。这意味着，如果同一个变量在命令行和全局中都有配置，命令行的值将用于该操作。
+
+### 超出用户信息
+
+到目前为止，我们仅在配置中处理了用户信息。然而，还有许多其他配置选项。以下是一些常见的配置：
+
+1. `core.editor` - 指定用于编写提交消息等的编辑器名称。
+2. `commit.template` - 指定系统中作为初始提交模板的文件。
+3. `color.ui` - 指定是否在 git 输出中使用颜色的布尔值。
+
+为了便于理解，我们简化了一些细节。如果你想进一步了解，访问 [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration)。
+
+
@@ -0,0 +1,76 @@
+# .gitignore
+
+.gitignore 文件是一个文本文件，用于告诉 Git 在项目中哪些文件或文件夹应被忽略。
+
+一个本地的 .gitignore 文件通常放置在项目的根目录下。你也可以创建一个全局的 .gitignore 文件，这样文件中的任何条目都会在你所有的 Git 仓库中被忽略。
+
+## 为什么使用 .gitignore
+现在你可能会想，为什么要让 Git 忽略某些文件和文件夹。原因是你不希望像构建文件、缓存文件、其他本地配置文件（例如 node_modules）、编译文件、IDE 创建的临时文件等被 Git 跟踪。通常，这样做是为了避免提交工作目录中的临时文件，这些文件对其他协作者没有用。
+
+## 入门
+要创建一个本地的 .gitignore 文件，创建一个文本文件并命名为 .gitignore（记得在文件名前加上 `.`）。然后根据需要编辑此文件。每一行都应该列出你希望 Git 忽略的文件或文件夹。
+
+该文件中的条目也可以遵循匹配模式。
+
+```
+* 用作通配符匹配
+/ 用于忽略相对于 .gitignore 文件的路径名
+# 用于在 .gitignore 文件中添加注释
+
+下面是 .gitignore 文件的一个示例：
+
+# 忽略 Mac 系统文件
+.DS_store
+
+# 忽略 node_modules 文件夹
+node_modules
+
+# 忽略所有文本文件
+*.txt
+
+# 忽略与 API 密钥相关的文件
+.env
+
+# 忽略 SASS 配置文件
+.sass-cache
+
+```
+要添加或更改全局 `.gitignore` 文件，运行以下命令：
+
+```
+git config --global core.excludesfile ~/.gitignore_global
+
+```
+这将创建文件 ~/.gitignore_global。现在，你可以像本地 .gitignore 文件一样编辑这个文件。你所有的 Git 仓库都会忽略全局 .gitignore 文件中列出的文件和文件夹。
+
+## 如何取消跟踪已提交的文件
+
+要取消跟踪单个文件，即停止跟踪该文件但不删除它，可以使用：
+
+```
+git rm --cached filename
+```
+
+要取消跟踪 .gitignore 中的每个文件：
+
+首先，提交任何未提交的代码更改，然后运行：
+
+```
+git rm -r --cached
+```
+
+这将从索引（暂存区）中移除任何已更改的文件，然后运行：
+
+```
+git add .
+```
+Commit it:
+
+```
+git commit -m ".gitignore is now working"
+```
+
+要撤销 ```git rm --cached filename```，使用 ```git add filename```
+
+
+
@@ -0,0 +1,19 @@
+# 删除本地创建的分支
+
+当你不小心拼错了分支名称时，这个操作会非常有用。
+
+你可以通过 *3* 种方式来删除分支：
+
+```
+git branch -D <branch_name>
+```
+
+```
+git branch --delete --force <branch_name>  # 与 -D 相同
+```
+
+```
+git branch --delete  <branch_name>         # 如果未合并会报错
+```
+
+-D 代表 --delete --force，即即使分支未合并，也会强制删除该分支。你也可以使用 -d，它代表 --delete，当分支未合并时，会抛出错误。
@@ -0,0 +1,119 @@
+# Gitflow
+
+Gitflow 是由 Vincent Driessen 创建的 Git 分支模型。本文将讨论 Gitflow 的要求和用例。<br />
+Gitflow 工作流定义了一个围绕项目发布而设计的严格分支模型，提供了一个强大的框架来管理大型项目。Gitflow 特别适用于具有计划发布周期的项目以及 DevOps 最佳实践中的持续交付。它为不同的分支分配了非常具体的角色，并定义了它们应该如何以及何时互动。它使用独立的分支来准备、维护和记录发布。
+
+
+## 实现
+
+1. **Develop 和 Master Branches**：与单一的 master 分支不同，Git Flow 使用两个分支来记录项目的历史。它基于两个具有无限生命周期的主分支，即 master 和 develop：
+  - **Master Branch**：master 分支包含生产代码并存储官方的发布历史。
+  - **Develop Branch**：develop 分支包含预生产代码，作为功能的集成分支。
+  - **创建 Develop Branch**：<br />
+    不使用 Gitflow 扩展时：
+    ```
+    git branch develop
+    git push -u origin develop
+    ```
+    使用 Gitflow 扩展时：当使用 gitflow 扩展库时，在现有的仓库中执行 `git flow init` 将创建 develop 分支。
+    ```
+    git flow init
+    ```
+2. **Feature Branch**：每个新功能应该放在它自己的分支上，可以推送到中央仓库以备份或协作。Feature 分支使用最新的 develop 作为其父分支。当功能完成时，它会合并回 develop。功能分支永远不应直接与 master 分支交互。
+  - **创建 Feature Branch**： <br />
+    不使用 git-flow 扩展时：
+    ```
+    git checkout develop
+    git checkout -b feature_branch
+    ```
+    使用 gitflow 扩展时：
+    ```
+    git flow feature start feature_branch
+    ```
+  - **完成 Feature Branch**： <br />
+    不使用 git-flow 扩展时：
+    ```
+    git checkout develop
+    git merge feature_branch
+    ```
+    使用 git-flow 扩展时：
+    ```
+    git flow feature finish feature_branch
+    ```
+3. **Release Branch**：当 develop 分支包含足够的功能用于发布（或者接近预定的发布日期）时，我们会从 develop 分支派生出一个 release 分支。创建这个分支标志着下一个发布周期的开始，因此在此之后不能再添加新功能——只能添加 bug 修复、文档生成和其他与发布相关的任务。Release 分支应从 develop 分支派生，并必须同时合并到 master 和 develop 分支。<br />
+使用专门的分支来准备发布使得一个团队可以在 polishing 当前发布时，另一个团队继续为下一个发布开发新功能。
+  - **创建 Release Branch**： <br />
+    不使用 git-flow 扩展时：
+    ```
+    git checkout develop
+    git checkout develop
+    git checkout -b release/0.1.0
+    ```
+    使用 git-flow 扩展时：
+    ```
+    git flow release start 0.1.0
+    ```
+    切换到新分支 'release/0.1.0'
+  - **完成 Release Branch**： <br />
+    不使用 git-flow 扩展时：
+    ```
+    git checkout master
+    git merge release/0.1.0
+    ```
+    使用 git-flow 扩展时：
+    ```
+    git flow release finish 0.1.0
+    ```
+4. **Hotfix Branch**：维护或“hotfix”分支用于快速修复生产发布。Hotfix 分支对于立即解决 master 分支中的不希望出现的问题非常必要。Hotfix 分支与 release 分支和 feature 分支类似，不同之处在于它是基于 master 分支而非 develop 分支派生的。这是唯一一个应直接从 master 分支派生的分支。修复完成后，它应该同时合并到 master 和 develop（或当前的 release 分支），并且 master 分支应该打上更新的版本号标签。
+  - **创建 Hotfix Branch**： <br />
+    不使用 git-flow 扩展时：
+    ```
+    git checkout master
+    git checkout -b hotfix_branch
+    ```
+    使用 git-flow 扩展时：
+    ```
+    git flow hotfix start hotfix_branch
+    ```
+  - **完成 Hotfix Branch**： <br />
+    不使用 git-flow 扩展时：
+    ```
+    git checkout master
+    git merge hotfix_branch
+    git checkout develop
+    git merge hotfix_branch
+    ```
+    使用 git-flow 扩展时：
+    ```
+    git branch -D hotfix_branch
+    git flow hotfix finish hotfix_branch
+    ```
+
+
+## 优势
+
+- 确保项目生命周期中的任何时刻分支状态保持清晰。
+- 分支的命名约定遵循系统化模式，使其更容易理解。
+- 支持大多数常用的 git 工具和扩展。
+- 适合在生产中维护多个版本。
+- 非常适合基于发布的软件工作流。
+- 提供了专门用于生产热修复的渠道。
+
+
+## 劣势
+
+- Git 历史记录变得难以阅读。
+- master 和 develop branch的分割被认为是冗余的，并使持续交付/集成变得更加困难。
+- 不推荐用于维护生产中的单一版本。
+
+
+## 总结
+
+我们在这里讨论了 Git Flow 工作流。Git Flow 是你和你的团队可以使用的多种 Git 工作流之一。让我们总结一下 Git Flow 的整个工作流：
+1. 从 master 创建一个 develop 分支。
+2. 从 develop 创建功能分支。
+3. 当功能完成时，将其合并到 develop 分支。
+4. 从 develop 创建一个 release 分支。
+5. 当 release 分支完成时，将其合并到 develop 和 master。
+6. 如果 master 中发现问题，则从 master 创建一个 hotfix 分支。
+7. 一旦 hotfix 完成，它将被合并到 develop 和 master。