当前位置： 首页 > article >正文

Day1——GitHub项目共同开发

article 2024/12/3 1:23:31

MarkDowm解释

Markdown是一种轻量级标记语言，它允许人们使用易读易写的纯文本格式编写文档，然后转换成结构化的HTML代码。Markdown的目的是让文档的编写和阅读变得更加容易，同时也不失HTML的强大功能。以下是Markdown的一些基本概念和用法：

基本语法：

  • 标题：使用#来表示标题，#的数量代表标题的级别。例如，# 一级标题，## 二级标题。
  • 强调：使用*或_包围文本来表示斜体，使用**或__包围文本来表示粗体。
  • 列表：
    • 无序列表使用*、+或-加空格来表示。
    • 有序列表使用数字加点加空格来表示。
  • 链接：使用[链接文字](URL)的格式来创建链接。
  • 图片：使用![替代文字](图片链接)的格式来插入图片。
  • 代码：使用反引号（`）包围代码片段，或者使用三个反引号包围代码块。
  • 引用：使用>来表示引用段落。
  • 表格：使用-和|来创建表格。

示例：

以下是一个简单的Markdown文档示例：

# 这是一个一级标题
## 二级标题
这里有一些强调：
- *斜体* 
- **粗体**
- ***粗斜体***
下面是一个无序列表：
- 项目一
- 项目二
- 项目三
这是一个有序列表：
1. 第一项
2. 第二项
3. 第三项
这是一个链接：[Markdown官网](https://daringfireball.net/projects/markdown/)
这是一个图片：
![外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传](https://img-home.csdnimg.cn/images/20230724024159.png?origin_url=https%3A%2F%2Fexample.com%2Fimage.jpg&pos_id=img-iHuU7V3n-1732972212306)
代码片段：
`print("Hello, World!")`
代码块：

def hello():
print(“Hello, World!”)

引用：
> 这是一个引用段落。
表格：
| 标题1 | 标题2 | 标题3 |
|-------|-------|-------|
| 内容1 | 内容2 | 内容3 |
| 内容4 | 内容5 | 内容6 |

将上述Markdown文本转换成HTML后，浏览器可以渲染出格式化的文档。Markdown因其简单易学、格式清晰而广泛应用于写作、文档编写、博客和论坛等场景。

GitHub 开发整体流程

在GitHub上进行共同开发通常遵循以下步骤：

1. Fork仓库

  • 访问GitHub上的项目页面。
  • 点击页面上的“Fork”按钮，将项目复制到您的GitHub账户下。
  • 为什么要fork
  • 具体操作

2. 克隆仓库到本地

  • 在您账户下的该项目页面，复制仓库的HTTPS或SSH克隆链接。
  • 在本地计算机上，使用Git命令行或Git客户端工具克隆仓库。
git clone [您的仓库克隆链接]
cd [项目目录]
  • 为什么要colone
  • 具体操作

3. 设置上游仓库

  • 这将允许您同步原始仓库的最新更改。
git remote add upstream [原始仓库克隆链接]
  • 为什么要设置上游仓库
  • 具体操作

4. 创建新分支

  • 在开始新功能或修复之前，总是从main或master分支创建一个新分支。
git checkout -b [新分支名称]
  • 为什么要创建新分支
  • 具体操作

5. 进行更改（这个在第四步就已经操作了，省略）

  • 在新分支上，进行所需的代码更改、添加或修复。
  • 经常提交您的更改。
git add [文件路径]
git commit -m "提交信息"

6. 保持同步

  • 在提交PR之前，确保您的分支是最新的。
git pull upstream [原始分支名称]
git push origin [您的分支名称]
  • 为什么要保持同步
  • 具体操作

7. 创建Pull Request（PR）

  • 在GitHub上，切换到您创建的分支，点击“New pull request”按钮。
  • 选择您的分支和原始仓库的目标分支，填写PR的标题和描述。
  • 提交PR。
  • 为什么要创建Pull Request
  • 具体操作

8. 代码审查(已经在第七步实现）

  • 其他贡献者或项目维护者将审查您的代码并提出建议或直接合并您的更改。

9. 处理反馈(已经在第七步实现）

  • 根据审查意见进行必要的更改。
  • 如果需要，您可以提交额外的commit到您的分支，这些commit将自动添加到现有的PR中。

10. 合并PR(已经在第七步实现）

  • 一旦PR被批准，项目维护者将合并您的更改到主分支。

11. 更新本地仓库

  • 在您的PR被合并后，更新您的本地仓库。
git checkout main
git pull upstream main
  • 为什么要更新本地仓库
  • 具体操作

问题回答：

解释一下为什么要fork

在GitHub上进行开源项目贡献时，"Fork"是一个关键步骤，以下是为什么要Fork的原因：

1. 独立的开发环境

  • 个性化工作流：Fork允许您在原始项目之外创建一个独立的副本，这样您就可以在不受原始项目限制的情况下进行开发。
  • 避免干扰：在您的Fork上工作不会直接影响原始项目，这意味着您可以自由地尝试新功能或进行实验性更改，而不用担心破坏主分支。

2. 权限管理

  • 无需直接访问权限：即使您没有权限直接向原始仓库提交代码，也可以通过Fork来进行贡献。
  • 安全：Fork提供了一个安全的环境，让贡献者可以在自己的仓库中进行更改，然后通过Pull Request（PR）的方式请求将这些更改合并到主项目中。

3. 代码审查

  • 审查过程：通过Fork创建的Pull Request提供了一个平台，让项目的维护者可以审查、讨论和改进贡献的代码，这是一个质量控制的过程。
  • 反馈循环：贡献者可以根据审查意见修改代码，并在Fork的分支上更新，直到代码被接受合并。

4. 并行开发

  • 多个贡献者：多个贡献者可以同时为项目做贡献，每个人都有自己的Fork，这样可以并行开发不同的功能或修复，而不会相互干扰。
  • 特性分支：Fork允许贡献者在自己的仓库中创建多个特性分支，这样可以同时处理多个问题或功能。

5. 版本控制

  • 跟踪更改：Fork可以作为一个独立的版本控制系统，允许贡献者跟踪自己的更改历史，而不会影响主项目的提交历史。
  • 合并管理：当贡献者准备好将更改合并到主项目时，维护者可以通过比较Fork和主项目的差异来决定是否合并。

6. 社区参与

  • 降低门槛：Fork机制降低了参与开源项目的门槛，使得更多的人可以参与到项目中来，即使他们不是项目的正式成员。
  • 促进协作：Fork机制促进了开源社区的协作，因为任何人都可以Fork一个项目，改进它，并通过PR与社区分享。
    总的来说，Fork是GitHub上协作开发的一个重要工具，它提供了一个安全、灵活且独立的开发环境，使得开源项目的贡献变得更加容易和高效。

解释一下为什么要clone

克隆GitHub仓库到本地有多个原因，以下是一些主要的好处：

  1. 离线工作：克隆仓库到本地后，即使在没有网络连接的情况下，你也可以查看文件、编辑代码和进行开发工作。
  2. 完整历史记录：克隆仓库会下载整个仓库的历史记录，包括所有的提交、分支和标签，这让你能够查看项目的历史变更和演进。
  3. 版本控制：通过本地仓库，你可以使用Git的所有版本控制功能，比如创建分支、提交更改、合并代码和解决冲突。
  4. 安全性：在本地进行更改并验证它们之前，不会直接影响远程仓库。这可以防止你意外破坏生产代码库。
  5. 性能：与直接在远程服务器上操作相比，在本地进行文件操作通常更快，尤其是在处理大量文件或大型项目时。
  6. 自定义工作流：你可以设置和使用本地工具和脚本，比如IDE、文本编辑器、构建工具、测试框架等，来自定义你的开发工作流。
  7. 协作：在提交更改到远程仓库之前，你可以在本地进行多次提交和重构，确保提交历史清晰且有意义，这有助于其他协作者理解你的更改。
  8. 备份：本地仓库为你提供了一个额外的备份，以防远程仓库出现任何问题。
  9. 隐私：如果你正在处理敏感或未公开的项目，将代码保留在本地可以提供额外的隐私保护。
  10. 网络限制：在某些网络环境下，访问远程仓库可能受到限制，而本地仓库则不受这些限制的影响。

总之，克隆仓库到本地为开发者提供了一个稳定、可控且功能丰富的开发环境，有助于提高开发效率和代码质量。

一句话概括: 克隆仓库到本地是为了在稳定、可控的环境中离线开发，利用Git的完整功能进行版本控制和工作流管理。

解释一下为什么要说设置上游仓库

在 Git 中，“设置上游仓库”（通常使用 git remote add upstream 命令）是一个重要的步骤，尤其是在参与开源项目或与其他开发者协作时。以下是设置上游仓库的几个原因：

  1. 同步最新更改：
    • 当您克隆一个仓库时，通常会设置一个默认的远程仓库，通常称为 origin，指向您克隆的仓库。但是，如果原始仓库（比如一个开源项目的主仓库）是由多个贡献者维护的，它可能会不断更新。设置上游仓库允许您轻松地从原始仓库获取最新的更改。
  2. 保持代码更新：
    • 通过设置上游仓库，您可以定期从上游拉取（git pull upstream）最新的更改，以确保您的本地副本是最新的。这对于保持与项目主分支的同步非常重要。
  3. 简化合并操作：
    • 当您想要合并上游仓库的最新更改到您的本地分支时，拥有一个已设置的上游仓库可以简化这一过程。您可以直接从上游仓库获取更改，并将其合并到您的本地分支。
  4. 避免冲突：
    • 如果您在本地进行了一些更改，并且上游仓库也有了新的提交，设置上游仓库可以帮助您更容易地处理潜在的合并冲突，因为您可以清楚地看到上游的更改与您的更改之间的差异。
  5. 贡献代码：
    • 当您想要向一个项目贡献代码时，通常需要基于上游仓库的最新更改创建一个分支。设置上游仓库可以让您更容易地遵循项目的贡献指南，因为它允许您保持与主仓库的同步。
  6. 遵循最佳实践：
    • 在开源社区中，设置上游仓库是一种被广泛认可的最佳实践。这样做有助于维护代码的整洁和一致性，并且使得与其他贡献者的协作更加顺畅。
      总之，设置上游仓库是 Git 协作中的一个关键步骤，它帮助开发者保持代码的最新性，简化合并和贡献流程，并遵循开源项目的开发准则。

解释一下为什么要为什么要创建新分支

创建新分支的原因是多方面的，主要涉及到代码版本控制的最佳实践、团队协作和项目管理的需要。以下是一些核心原因：

  1. 特性隔离：每个新特性都应该在一个独立的分支上开发。这样，如果特性开发出现问题，它不会影响到主分支（通常是 master 或 main）的稳定性。这也使得代码审查更加集中和有效。
  2. 并行开发：在大型项目或团队协作中，多个开发者可能同时工作在不同的特性或修复上。使用不同的分支允许他们并行工作而不相互干扰。
  3. 快速迭代：新分支允许开发者快速迭代和实验，而不必担心破坏现有的工作。这有助于快速原型设计和测试新想法。
  4. 代码审查：创建拉取请求（Pull Request）通常涉及从一个特性分支到主分支的合并。这提供了一个代码审查的过程，其他开发者可以在代码合并到主分支之前审查和讨论更改。
  5. 问题修复：当需要快速修复生产环境中的问题时，可以在一个专门的修复分支上进行工作。这样，修复可以独立于其他正在进行的开发工作。
  6. 版本控制：在发布新版本时，创建分支可以帮助维护不同版本的代码。例如，可以有一个 release/x.y.z 分支用于准备即将发布的版本。
  7. 避免混乱：主分支应该始终保持可部署的状态。通过在分支上进行所有开发工作，可以确保主分支的代码是经过测试和审查的。
  8. 回滚和恢复：如果在某个分支上的更改导致问题，可以更容易地回滚这些更改，而不会影响到其他分支。
  9. 环境分离：不同的分支可以用于不同的环境，如开发、测试和生产，确保每个环境的代码都是稳定和经过验证的。
    总之，创建新分支是现代软件开发中一种管理代码变化、促进协作和提高代码质量的重要实践。

解释一下为什么要保持同步

"保持同步"这一步骤是创建 pull request（PR）之前的一个重要环节。以下是为什么需要这样做以及如何操作的详细解释：

  1. 避免合并冲突：随着时间的推移，其他贡献者可能已经向主分支或其他目标分支提交了新的更改。如果你的分支不是最新的，当你尝试合并时，可能会遇到冲突，这些冲突需要解决才能完成合并。
  2. 确保最新的更改：保持分支与主分支同步可以确保你的更改是基于最新的代码库状态，这有助于减少重复工作或解决已经解决的问题。
  3. 安全性：最新的代码可能包含重要的修复或安全更新，同步这些更改可以保护你的代码库不受潜在的安全威胁。

解释一下为什么要为什么要创建PR

创建 Pull Request (PR) 是在 Git 和许多基于 Git 的托管平台（如 GitHub、GitLab、Bitbucket 等）上进行协作开发时的一个关键步骤。

为什么要创建 Pull Request？

  1. 代码审查：Pull Request 允许其他开发者审查你的代码更改。这有助于提高代码质量，确保新的代码符合项目的标准和风格。
  2. 讨论和反馈：Pull Request 提供了一个平台，让团队成员可以在代码层面上进行讨论和提供反馈。
  3. 集成管理：通过 Pull Request，维护者可以控制何时将更改集成到主分支，有助于避免破坏性的提交。
  4. 自动化：许多平台允许在 Pull Request 中运行自动化测试和检查，确保更改不会引入错误。
  5. 历史记录：Pull Request 保留了对代码更改的讨论和决策的历史记录，这对于项目的知识管理和回顾很有帮助。

解释一下为什么要为什么要更新本地库

  1. 同步更改：合并 PR 意味着远程仓库的主分支（通常是 master 或 main）已经更新。为了同步这些更改到你的本地环境，你需要更新本地仓库。
  2. 避免冲突：如果你在本地继续工作而不更新，当你下次尝试推送更改时，可能会遇到由于其他人已经合并的更改导致的冲突。
  3. 保持最新状态：确保你的本地副本反映了项目的最新状态，这对于继续开发非常重要。

具体操作：

fork操作

  • 点击fork
    在这里插入图片描述
  • 点击create fork
    在这里插入图片描述
  • 创建完成，这个就是你自己的该工程
    -在这里插入图片描述

clone操作

  1. 新建文件夹
    在这里插入图片描述
  2. 进入该文件夹
    Git Bash 快捷键
$ cd D:\SoftwareEngineeringMajor
  1. git clone
$ git clone https://github.com/username/repository.git
  1. 结果
    在这里插入图片描述

设置上游仓库

设置上游仓库的具体操作步骤如下：

  1. 首先，确保您已经克隆了您想要贡献的仓库。例如，假设您已经克隆了自己的仓库副本，通常这个远程仓库被称为 origin。
  2. 打开终端（在 macOS 或 Linux 上）或命令提示符/PowerShell（在 Windows 上）。
  3. 切换到您克隆的仓库目录中。例如：
    cd path/to/your/repository

    cd yy_pb
  4. 使用 git remote -v 命令查看当前配置的远程仓库。您会看到类似以下输出：
    origin  https://github.com/your-username/repository.git (fetch)
origin  https://github.com/your-username/repository.git (push)
  • (fetch): 这表示当您执行 git fetch origin 命令时，Git 将使用这个 URL 来从远程仓库获取数据。
  • (push): 这表示当您执行 git push origin 命令时，Git 将使用这个 URL 来将您的更改推送到远程仓库。
  1. 添加上游仓库。上游仓库通常是指原始项目的主仓库。使用以下命令添加上游仓库：
    git remote add upstream https://github.com/original-owner/repository.git
    请确保将 https://github.com/original-owner/repository.git 替换为原始仓库的实际 URL。
  2. 再次使用 git remote -v 命令验证上游仓库是否已正确添加：
    origin  https://github.com/your-username/repository.git (fetch)
origin  https://github.com/your-username/repository.git (push)
upstream        https://github.com/original-owner/repository.git (fetch)
upstream        https://github.com/original-owner/repository.git (push)

现在，您已经设置了上游仓库，可以使用以下命令从上游仓库获取最新更改：

  • 获取上游仓库的最新更改：
    git fetch upstream
  • 结果
$ git fetch upstream
From github.com:yypeter1/yy_pb
 * [new branch]      master     -> upstream/master

  • 这条 Git 命令的输出信息解释如下：

  • $ git fetch upstream: 这条命令是用来从名为 upstream 的远程仓库获取最新的分支和提交信息。在 Git 中，fetch 命令会下载目标远程仓库的所有你还没有的数据，但不合并任何内容到你当前的工作分支。

  • From github.com:yypeter1/yy_pb: 这部分告诉你，Git 正在从哪个远程仓库获取数据。在这个例子中，远程仓库的 URL 是 github.com/yypeter1/yy_pb。

  • * [new branch] master -> upstream/master: 这部分是命令输出的关键信息，它告诉你以下内容：

    • * [new branch]: 这表示 Git 发现了一个新的分支。如果这是一个已经存在的分支，并且有新的提交，那么这里会显示 [new commits] 而不是 [new branch]。
    • master: 这是从远程仓库 upstream 获取的分支的名称。
    • -> upstream/master: 这表示本地仓库中创建或更新了一个远程跟踪分支。在这个例子中，upstream/master 是一个远程跟踪分支，它对应于 upstream 远程仓库的 master 分支。这个远程跟踪分支允许你在本地查看 upstream 仓库的 master 分支的最新状态，而无需合并到你的本地分支。
      总结来说，这条命令的输出表明你成功地从名为 upstream 的远程仓库获取了 master 分支的最新内容，并在本地创建了一个名为 upstream/master 的远程跟踪分支。

  • 将上游仓库的最新更改合并到您的本地分支中：

      $ git merge upstream/master
  Already up to date.

    请注意，main 是上游仓库的主分支名称，它可能是 master、develop 或其他名称，取决于项目的设置。
    通过这些步骤，您可以保持本地仓库与上游仓库的同步，并更容易地贡献代码回原始项目。

总结

先添加上游仓库git remote add upstream —，也就是一开始fork的源仓库，给远程跟踪分支来源。然后从上游仓库获取最新更改git fetch upstream，就是获得当下源仓库的数据。最后合并到自己的本地主分支上git merge upstream/master。

远程跟踪分支是 Git 中的一个概念，它是在本地仓库中用来表示远程仓库分支状态的引用。每个远程跟踪分支都有一个与之对应的远程仓库分支，

创建分支

当然，以下是使用 Git 创建新分支的详细步骤：

步骤 1: 确保你的工作目录是干净的

在创建新分支之前，最好确保你的工作目录是干净的，也就是说，所有更改都已提交。如果有未提交的更改，你可以选择提交它们或者暂存起来。

git status  # 查看当前状态
git add .   # 暂存所有更改
git commit -m "Commit message"  # 提交更改

$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean

步骤 2: 切换到主分支（如果不在主分支上）

通常，你会在主分支的基础上创建新分支。

git checkout master  # 或者 git checkout main，取决于你的主分支名称

步骤 3: 创建并切换到新分支

使用 git checkout -b 命令创建一个新分支并立即切换到该分支。

git checkout -b new-branch-name

$ git checkout -b Requirement_Analysis
Switched to a new branch 'Requirement_Analysis'

这个命令相当于以下两个命令的组合：

git branch new-branch-name  # 创建新分支
git checkout new-branch-name  # 切换到新分支

步骤 4: 在新分支上进行更改

现在你已经在新的分支上了，可以开始进行你的更改。

# 进行一些更改，比如添加新文件、修改现有文件等

添加一个pb_需求分析.docx文件

在这里插入图片描述

$ git status
On branch Requirement_Analysis
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        需求分析与设计/pb_需求分析.docx

步骤 5: 暂存并提交你的更改

当你完成了一些更改后，需要暂存并提交它们。

git add .  # 暂存所有更改
git commit -m "Commit message describing your changes"  # 提交更改

$ git add 需求分析与设计/pb_需求分析.docx
$ git status
On branch Requirement_Analysis
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   需求分析与设计/pb_需求分析.docx
$ git commit -m "Add Requirement_Analysis"
[Requirement_Analysis 7bbb45a] Add Requirement_Analysis
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 需求分析与设计/pb_需求分析.docx

步骤 6: 推送新分支到远程仓库（可选）

如果你想要分享这个分支或创建拉取请求，你需要将其推送到远程仓库。

git push -u origin new-branch-name

$ git push -u origin Requirement_Analysis
Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Delta compression using up to 6 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 8.94 KiB | 8.94 MiB/s, done.
Total 4 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote:
remote: Create a pull request for 'Requirement_Analysis' on GitHub by visiting:
remote:      https://github.com/peng5620/yy_pb/pull/new/Requirement_Analysis
remote:
To github.com:peng5620/yy_pb.git
 * [new branch]      Requirement_Analysis -> Requirement_Analysis
branch 'Requirement_Analysis' set up to track 'origin/Requirement_Analysis'.

从命令行输出信息来看，已经成功地将本地分支 Requirement_Analysis 推送到了远程仓库 origin，并且设置了该分支的上游（upstream）跟踪分支。以下是输出的详细解释：

  • $ git push -u origin Requirement_Analysis: 这是你执行的命令，用于推送本地分支 Requirement_Analysis 到远程仓库 origin，并使用 -u 选项来设置上游跟踪分支。
  • Enumerating objects: Git 正在计算要推送的对象数量。
  • Counting objects: Git 完成了对象的计数。
  • Delta compression using up to 6 threads: Git 正在使用多达 6 个线程来压缩差异。
  • Compressing objects: Git 完成了对象的压缩。
  • Writing objects: Git 正在将对象写入远程仓库。
  • Total 4 (delta 2), reused 0 (delta 0), pack-reused 0: Git 显示了传输的总对象数（4个），其中包含的差异对象数（2个），以及重用和包重用的对象数。
  • remote: Resolving deltas: Git 在远程仓库上解决了对象之间的差异。
  • remote: 下的两行是远程仓库（GitHub）提供的提示信息，告诉你如何为 Requirement_Analysis 分支创建一个 pull request。
  • To github.com:peng5620/yy_pb.git: 表示推送的目标远程仓库。
  • * [new branch] Requirement_Analysis -> Requirement_Analysis: 表示在远程仓库中创建了一个新的分支 Requirement_Analysis。
  • branch 'Requirement_Analysis' set up to track 'origin/Requirement_Analysis'.: 表示本地分支 Requirement_Analysis 现在跟踪远程分支 origin/Requirement_Analysis。
  • 现在，你可以按照远程仓库提供的链接（https://github.com/peng5620/yy_pb/pull/new/Requirement_Analysis）访问 GitHub，为 Requirement_Analysis 分支创建一个 pull request，以便将更改合并到主分支或其他目标分支中。

如何保持同步

随便在github远程库master 添加一个test.txt文件模拟别人进行了修改

在这里插入图片描述

  1. 切换到主分支：

    git checkout main

    $ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

    或者，如果项目的主分支不是 main，可能是 master 或其他名称，请相应地替换。

  2. 从远程仓库获取最新的更改：

    git pull origin main

$ git pull origin master
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (4/4), 1013 bytes | 50.00 KiB/s, done.
From github.com:peng5620/yy_pb
 * branch            master     -> FETCH_HEAD
   390fcd2..c908106  master     -> origin/master
Updating 390fcd2..c908106
Fast-forward
 需求分析与设计/test.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 需求分析与设计/test.txt

从提供的 git pull 命令输出中，以下是对发生的事情的详细解释：

  1. 远程仓库操作:
    • remote: Enumerating objects: 表示 Git 正在列举远程仓库中的对象（文件和目录）。
    • remote: Counting objects: 表示 Git 正在计数这些对象。
    • remote: Compressing objects: 表示 Git 正在压缩这些对象以减少传输的数据量。
    • remote: Total 4 (delta 2), reused 0 (delta 0), pack-reused 0 表示从远程仓库接收到的对象总数是 4，其中有 2 个对象是差异（delta），表示它们是基于之前版本的更改。
  2. 本地操作:
    • Unpacking objects: 表示 Git 正在解压从远程仓库接收到的对象。
    • From github.com:peng5620/yy_pb 表示更新的来源是 origin 远程仓库的 master 分支。
    • 390fcd2..c908106 master -> origin/master 表示本地 master 分支从提交 390fcd2 更新到提交 c908106。
  3. 更新细节:
    • Updating 390fcd2..c908106 表示本地分支正在更新以反映远程分支的变化。
    • Fast-forward 表示这次更新是一个快进操作，这意味着没有冲突，本地分支可以直接移动到远程分支的最新提交。
  4. 文件更改:
    • 需求分析与设计/test.txt | 1 + 表示在 需求分析与设计 目录下有一个文件 test.txt 被修改了，并且有一个插入（通常是添加了一行）。
    • 1 file changed, 1 insertion(+) 确认了上述信息，即有一个文件被更改，且更改包括一个插入操作。
    • create mode 100644 需求分析与设计/test.txt 表示这个文件是新建的，并且权限模式设置为 100644（普通文件）。
      总结来说，这次 git pull 操作成功地将远程 master 分支的最新更改拉取到本地 master 分支，并且这些更改包括在 需求分析与设计 目录下创建了一个新的 test.txt 文件，文件中添加了一行内容。

  • 小question：

  • git pull origin main 拉取的是fork后的自己的远程库，还是一开始别人的源仓库？

    • git pull origin main 命令会拉取并合并名为 origin 的远程仓库的 main 分支到你的本地分支。

    • 在 Git 中，当你使用 fork 功能在平台如 GitHub 上创建了一个仓库的副本时，你的副本（即你的远程仓库）通常会自动被 Git 配置为 origin。因此，执行 git pull origin main 时，如果你已经将原始仓库（别人的源仓库）添加为一个新的远程仓库（通常命名为 upstream），那么这个命令会从你的远程仓库（即你 fork 后的仓库）拉取 main 分支。

    这将拉取远程仓库中主分支的最新更改，并更新你的本地主分支。

  1. 切换回你的分支：

    git checkout Requirement_Analysis

       $ git checkout Requirement_Analysis
Switched to branch 'Requirement_Analysis'
Your branch is up to date with 'origin/Requirement_Analysis'.

  2. 将主分支的最新更改合并到你的分支：

    git merge master

    或者，如果你想要一个更干净的历史记录，可以使用 rebase：

    git rebase main

    注意：使用 rebase 可能会更复杂，并且如果分支已经共享，可能会导致问题。

  • 结果
    在这里插入图片描述

  • 在默认消息下方，输入一个清晰的、描述性的提交消息，解释你为什么需要进行这次合并。例如：

    Merge branch 'master' into Requirement_Analysis to incorporate the latest changes from master into our feature development.

  • 保存并关闭编辑器。如果你使用的是 Vim，可以按 Esc 键，然后输入 :wq 来保存并退出；如果你使用的是 Nano，可以按 Ctrl + X，然后按 Y 键来保存更改，并按 Enter 键退出。

这将合并 master 分支到 Requirement_Analysis 分支，并使用双引号内的消息作为提交消息。

$ git merge master
hint: Waiting for your editor to close the file...       0 [sig] bash 1216! sigpacket::process: Suppressing signal 18 to win32 process (pid 20300)
Merge made by the 'ort' strategy.
 需求分析与设计/test.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 需求分析与设计/test.txt

  1. 解决任何合并冲突：
    如果在合并或 rebase 过程中出现冲突，你需要手动解决这些冲突，然后继续操作。(这个就先不做实验了)

  2. 推送到远程仓库：
    一旦你的本地分支是最新的，并且所有冲突都已解决，你需要将这些更改推送到远程仓库：

    git push origin Requirement_Analysis

    $ git push origin Requirement_Analysis
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 6 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 428 bytes | 428.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To github.com:peng5620/yy_pb.git
   7bbb45a..533ebc5  Requirement_Analysis -> Requirement_Analysis

在这里插入图片描述

完成以上步骤后，你的 Requirement_Analysis 分支就与主分支保持同步了，就有了test.txt这个文件，这时你可以安全地创建 pull request 并请求将你的更改合并到主分支。

如何创建PR

以下是在 GitHub 上创建 Pull Request 的步骤：

  1. 确保你的本地分支已经推送到远程仓库：

    git push origin Requirement_Analysis

  2. 打开你的 GitHub 仓库：

    • 访问 GitHub 网站。
    • 导航到你 fork 的仓库页面。

  3. 切换到要创建 Pull Request 的分支：

    • 在仓库页面上，点击分支选择器，选择你的分支（例如 Requirement_Analysis）。
      在这里插入图片描述

  4. 点击 “New pull request” 按钮：

    • 在分支页面上，你会看到一个 “New pull request” 按钮，点击它。

  5. 配置 Pull Request：

    • 在 “Create a pull request” 页面上，确认 “base fork”（通常是主仓库的主分支，如 main 或 master）和 “compare fork”（你的 fork 和分支）。
    • 填写标题和描述，解释你的更改和为什么它们应该被合并。

  6. 提交 Pull Request：

    • 确认所有信息填写正确后，点击 “Create pull request”。
      在这里插入图片描述
      在这里插入图片描述
      在这里插入图片描述

  7. 等待审查和讨论：

    • 一旦 Pull Request 被创建，其他贡献者和维护者可以查看你的更改，并提供反馈。
    • 根据反馈，你可能需要进行一些更改。如果需要，你可以继续在分支上工作，并推送新的提交，这些提交将自动添加到 Pull Request 中。

  8. 合并 Pull Request：

    • 一旦代码被审查并通过，维护者将合并你的 Pull Request，将你的更改集成到主分支中。

    • 点击merge pull request 同意合并到主分支上在这里插入图片描述
      在这里插入图片描述

    • 现在就只剩下了master一个主分支了。
      在这里插入图片描述

    • master 主分支里面有Requirement_Analysis 添加的pb_需求分析

遵循这些步骤，你就可以有效地创建和参与 Pull Request 流程，为开源项目或其他协作项目做出贡献。

问题：pr是合并到哪个主分支？是fork后自己的还是一开始的源远程库？

  • 在 GitHub 或其他 Git 托管平台上，当您创建一个 Pull Request (PR) 时，您是从您的 fork（分叉）的仓库的分支向原始仓库的某个分支提出更改请求。PR 是合并到原始仓库的主分支，而不是您 fork 后自己的主分支。
    以下是具体步骤和解释：
  1. Fork 仓库：您首先在 GitHub 上 fork 一个原始仓库，这会在您的账户下创建一个原始仓库的副本。
  2. 克隆您的 Fork：然后，您将您 fork 的仓库克隆到本地计算机。
  3. 创建特性分支：在本地，您创建一个特性分支来进行更改。
  4. 进行更改并提交：在这个特性分支上，您进行所需的更改，然后提交这些更改。
  5. 推送更改到您的 Fork：将您的特性分支推送到您 fork 的仓库中。
  6. 创建 PR：在 GitHub 上，您从您的 fork 的特性分支创建一个 PR，目标是原始仓库的主分支（通常是 main 或 master）。
  7. 审查和合并：原始仓库的维护者会审查您的 PR，如果一切看起来都很好，他们会将您的更改合并到原始仓库的主分支中。
    所以，PR 是合并到原始仓库的主分支，而不是您 fork 后的主分支。一旦 PR 被合并，您需要从原始仓库同步这些更改到您 fork 的仓库，以便您的 fork 保持最新。这通常通过以下步骤完成：
# 切换到您想要同步的分支（通常是主分支）
git checkout main
# 添加原始仓库作为上游仓库（如果还没有添加）
git remote add upstream https://github.com/original-repo/original-repo.git
# 从上游仓库获取最新更改
git fetch upstream
# 合并上游仓库的主分支到您 fork 的主分支
git merge upstream/main
# 推送更新到您 fork 的仓库
git push origin main

通过这种方式，您 fork 的仓库将包含原始仓库的最新更改。

如何创建PR

  1. 切换到主分支：
    git checkout main
    或者如果你使用的是 master 分支：
    git checkout master
  2. 从远程仓库获取最新更改：

  • 使用 git fetch 命令来下载远程仓库的所有你还没有的数据。

    git fetch upstream
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (1/1), 901 bytes | 225.00 KiB/s, done.
From github.com:yypeter1/yy_pb
   390fcd2..8d0f749  master     -> upstream/master

  • 合并远程分支：使用 git merge 或 git pull 命令来合并远程分支到你的本地分支。git pull 实际上是 git fetch 后跟 git merge 的缩写。如果你想要先检查更改，然后手动合并，可以：

    $ git merge upstream/master
Updating c908106..8d0f749
Fast-forward
 需求分析与设计/pb_需求分析.docx | Bin 0 -> 10006 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 需求分析与设计/pb_需求分析.docx
  1. 解决可能的合并冲突：
    • 如果在 pull 操作中出现了合并冲突，Git 会通知你哪些文件存在冲突。
    • 打开这些文件，手动解决冲突。
    • 解决冲突后，使用 git add 命令标记文件为已解决冲突。
    • 最后，使用 git commit 来提交合并。
  2. 推送到远程仓库（如果需要）：
    如果你解决了冲突并且想要更新远程仓库，可以执行以下命令：
    获取远程仓库的最新信息：使用 git fetch 命令来下载远程仓库的所有你还没有的数据。
    git push origin main
    或者如果你使用的是 master 分支：
    git push origin master

通过以上步骤，你的本地仓库就会与远程仓库保持同步，你可以继续进行开发工作。

补充资料

Git Bash 快捷键

在 Git Bash 中，有一些常用的快捷键可以帮助提高工作效率。以下是一些基本的快捷键：

  1. 导航快捷键:
    • Ctrl + A：跳转到命令行的开头。
    • Ctrl + E：跳转到命令行的末尾。
    • Ctrl + F：向前移动一个字符（向右）。
    • Ctrl + B：向后移动一个字符（向左）。
    • Alt + F：向前移动一个单词。
    • Alt + B：向后移动一个单词。
  2. 文本编辑快捷键:
    • Ctrl + U：剪切从光标位置到行首的文本。
    • Ctrl + K：剪切从光标位置到行尾的文本。
    • Ctrl + Y：粘贴之前剪切的文本。
    • Ctrl + W：剪切光标前的单词。
    • Ctrl + H：删除光标前的字符（相当于退格键）。
    • Ctrl + D：删除光标后的字符（相当于删除键）。
    • Ctrl + T：交换光标前后的字符。
  3. 历史命令快捷键:
    • Ctrl + R：逆向搜索命令历史。
    • Ctrl + P：历史命令中的上一条命令。
    • Ctrl + N：历史命令中的下一条命令。
    • Ctrl + S：正向搜索命令历史（在某些终端中可能与屏幕锁定快捷键冲突）。
  4. 其他快捷键:
    • Ctrl + L：清屏。
    • Ctrl + C：中断当前命令。
    • Ctrl + D：结束当前会话（相当于退出登录）。
    • Ctrl + Z：将当前进程置于后台。
  5. 复制与粘贴
    • 选中就是复制
    • 鼠标中键就是粘贴
      请注意，一些快捷键可能在不同的终端或配置下有所不同，上述快捷键在大多数基于 Bash 的环境中都是通用的。如果您使用的是 Git Bash，这些快捷键通常都是有效的。

gitbash ls,git status 出现中文乱码

  1. 设置locale 为zh_CN, Character set 为UTF-8
    在这里插入图片描述
  2. 确保 Git 配置正确处理 UTF-8 编码：
git config --global core.quotepath false
git config --global i18n.commitencoding utf-8
git config --global i18n.logoutputencoding utf-8
  1. 检查环境变量
echo $LANG
echo $LC_ALL
echo $LC_CTYPE
  • 这些命令会显示当前设置的语言和字符编码。如果它们被设置为 en_US.UTF-8 或其他以 .UTF-8 结尾的值，那么你的终端应该支持 UTF-8 编码。
  1. 检查 Git 的配置
git config --get core.quotePath
git config --get i18n.commitencoding
git config --get i18n.logoutputencoding
  1. 如果你的环境变量 LANG, LC_ALL, 和 LC_CTYPE 都设置为 zh_CN.GBK，你需要将这些变量更改为使用 UTF-8 编码。

  • 临时更改编码
    在当前会话中，你可以使用以下命令将编码更改为 UTF-8：

    export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
export LC_CTYPE=en_US.UTF-8

引用：

【Git】解决Ctrl+V无法粘贴文本的问题


http://www.kler.cn/a/419212.html

相关文章：

  • 一万台服务器用saltstack还是ansible?
  • yolov5 解决：export GIT_PYTHON_REFRESH=quiet
  • 【实验13】使用预训练ResNet18进行CIFAR10分类
  • Android 14之HIDL转AIDL通信
  • 分布式系统中的Dapper与Twitter Zipkin：链路追踪技术的实现与应用
  • C#面向对象之访问限制，类基础，继承
  • Vue进阶之单组件开发与组件通信
  • Unity中实现A*寻路算法参考
  • Scala 的知识点
  • Linux中pcap_loop()函数
  • 算法的复杂度
  • LeetCode：19.删除链表倒数第N个节点
  • 解决jupyter notebook 新建或打开.ipynb 报500 : Internal Server Error（涉及jinja2兼容性问题）
  • 蓝桥-希尔排序模板题
  • 【Java基础面试题004】封装、继承、重载、多态、接口和抽象类是什么？
  • 《JavaEat：探索 Java 在美食世界的奇妙之旅》
  • 无星的微前端之旅（四）——qiankun线上服务代理到本地
  • 后端-一对一的数据封装的两种写法对比
  • Android 图形系统之六：BufferQueue
  • 信息网络安全考试gjdw
  • 网络安全运维——高级 题库一 50题
  • vue3 + vite + antdv 项目中自定义图标
  • 华为OD机试真题---幼儿园篮球游戏
  • 【解决安全扫描漏洞】---- 检测到目标站点存在 JavaScript 框架库漏洞
  • 【Vue3】【Naive UI】＜NDropdown＞标签
  • 【机器学习】机器学习学习笔记 - 监督学习 - 多项式回归决策树回归 - 03