Datawhale学习git-第一节

沛槐-艺锦

已于 2024-01-16 20:14:59 修改

阅读量961

点赞数 19

分类专栏： datawhale-- git 学习文章标签： git 学习

于 2024-01-16 20:13:10 首次发布

本文链接：https://blog.csdn.net/m0_63221910/article/details/135634168

版权

datawhale-- git 学习专栏收录该内容

4 篇文章 0 订阅

订阅专栏

✨ 思考是行动的种子。—— 爱默生

三层笔记法实践步骤：构思笔记 → 封存笔记 → 行动笔记

行动笔记

鼠标放置在正文左侧，点击 “+” 工具栏中的“高亮块”，高亮你的学习感悟

【输出】将构思笔记层中提炼出的需要执行的内容或最为核心的内容上移至行动笔记层，每次打开笔记文档时都能直指要点。

构思笔记

【收集】在构思笔记层中写下即时想法或大纲，亦或是会议记录或你对学习资料的注解

Git入门指南

简介

Git是一个分布式版本控制系统，用于追踪文件的变更。它允许多个用户在不同的系统上协作工作。

基本概念

版本控制系统（VCS）

一种软件，用于管理文件的版本和历史记录。

分布式版本控制系统（DVCS）

与集中式VCS不同，DVCS（如Git）允许多份完整的代码库副本存在于不同的计算机上。

集中式版本控制系统（CVCS）

优点：简单直观，易于管理和权限控制。
缺点：单点故障风险，依赖网络连接，备份和恢复较难。

分布式版本控制系统（DVCS）

优点：本地操作快速，更灵活的分支管理，更强的抗灾能力。
缺点：学习曲线较陡，占用更多资源，可能导致项目过度分散。

总结：CVCS适合简单、集中管理的场景，而DVCS适用于需要高度灵活性和离线工作能力的复杂项目。

仓库（Repository）

存储代码的地方，包括所有版本的历史记录。

提交（Commit）

一次更改的记录，包括更改的内容和说明。

分支（Branch）

代码的独立线路，允许在不影响主线（master）的情况下开发新功能。

合并（Merge）

将一个分支的更改合并到另一个分支上。

常用命令

git init

初始化一个新的Git仓库。

git clone [url]

克隆一个远程仓库到本地。

git add [file]

添加文件到暂存区。

这是个多功能命令：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等。将这个命令理解为“精确地将内容添加到下一次提交中”而不是“将一个文件添加到项目中”要更加合适

git commit -m "[commit message]"

提交更改到仓库，带有提交信息。

git branch [branch-name]

创建一个新的分支。

git checkout [branch-name]

切换到指定分支。

git merge [branch]

合并指定分支到当前分支。

git pull

从远程仓库拉取最新更改。

git push

推送本地更改到远程仓库。

工作流程

基本工作流

克隆仓库：获取远程仓库的副本。
创建分支：为新功能或修复创建一个新分支。
进行更改：在本地分支上工作并提交更改。
合并分支：完成后，将更改合并回主分支。

团队合作流程

Fork仓库：创建仓库的个人副本。
克隆Fork：将Fork仓库克隆到本地。
设置上游仓库：连接到原始仓库以获取更新。
同步更改：定期从上游仓库拉取更新。
推送更改：将提交推送到你的Fork。
发起合并请求（Pull Request）：请求将你的更改合并到原始仓库。

特性分支工作流

为每个新特性创建分支：保持主分支的稳定性。
独立开发：在特性分支上进行开发和测试。
代码审查：在合并前进行代码审查。
合并到主分支：开发完成后，合并到主分支。

最佳实践

频繁提交：经常提交可以减少丢失工作的风险。
清晰的提交信息：写明确的提交信息有助于理解历史更改。
保持分支同步：定期与主分支同步以避免合并冲突。
代码审查：通过代码审查保持代码质量。

结论

Git是一个强大的工具，适用于从个人项目到大型团队合作。理解其基本概念、常用命令和工作流程对于有效地使用Git至关重要。

封存笔记

【整理】随着“即时”笔记越来越多，你可以将构思笔记层中多余或不重要的内容移动到封存笔记层，使构思笔记层保留精华内容，而封存笔记层可以作为补充信息查看

版本控制系统（VCS）

是一种软件工具，用于帮助软件团队管理项目代码的变更历史。主要功能包括：

跟踪变更：记录文件随时间的变化，允许用户查看过去的版本。
协同工作：支持多人在同一项目上工作，帮助管理不同人员的贡献和修改。
分支和合并：允许用户在不影响主项目（主分支）的情况下，独立开发新功能或修复问题（分支），之后可以将这些更改合并回主项目中。
错误定位和修复：如果引入了错误，可以快速回溯到引入错误之前的状态。
减少冲突：在多人协作时，帮助解决代码修改的冲突。

集中式版本控制vs分布式版本控制系统

集中式版本控制系统（CVCS）

优点

简单直观：对于新手来说，集中式系统通常更易于理解和使用。
集中管理：所有文件和历史记录存储在一个中央服务器上，便于管理员进行管理和控制。
易于管理权限：中央服务器可以轻松地控制对代码库的访问权限。

缺点

单点故障：如果中央服务器发生故障，整个系统可能会瘫痪，直至服务器恢复。
对网络依赖：团队成员必须连网才能提交更新或获取最新版本，限制了离线工作能力。
备份和恢复难度：如果中央服务器的数据丢失且没有备份，可能导致整个项目的历史记录丢失。

分布式版本控制系统（DVCS）

优点

本地操作：大多数操作（如提交、分支、合并）都在本地进行，速度快且不依赖网络连接。
更好的分支处理：分布式系统通常提供更高效和灵活的分支和合并机制。
抗灾备份：每个团队成员都拥有代码库的完整副本，大大减少了数据丢失的风险。

缺点

初始学习曲线较高：相对于集中式系统，DVCS通常更复杂，初学者可能需要更多时间来适应。
资源占用：由于每个副本都包含完整的历史记录，可能占用更多的磁盘空间。
可能导致过度分散：分布式系统中的分支可能过于分散，需要有效的协作和沟通策略来保持项目的整体性。

获取 Git 项目仓库主要有两种方式：

将现有目录转换为 Git 仓库：
1. 进入项目目录（例如，在 Linux 上使用 $ cd /home/user/my_project）。
2. 执行 $ git init 初始化 Git 仓库，创建 .git 子目录，其中包含必要的仓库文件。
3. 使用 git add 和 git commit 命令开始追踪文件并进行初始提交，如 $ git add *.c 和 $ git commit -m 'initial project version'。
克隆现有的 Git 仓库：
1. 使用 git clone 命令获取现有仓库的拷贝，例如 $ git clone https://github.com/libgit2/libgit2。
2. 这会在当前目录下创建一个新目录（如 libgit2），包含 .git 文件夹和远程仓库的所有数据。
3. 可以通过额外参数自定义本地仓库名，如 $ git clone https://github.com/libgit2/libgit2 mylibgit。
4. Git 支持多种数据传输协议，包括 HTTPS (https://)、Git (git://) 和 SSH (user@server:path/to/repo.git)。

练习总结

2.2.1检查当前文件状态

使用 git status 查看文件状态。

若仓库刚克隆完成，通常显示工作目录干净，无未跟踪文件。
显示当前分支与远程分支同步情况。

Git 状态输出:

On branch main：你当前在名为 main 的分支上。Git 仓库中可以有多个分支，而 main 通常是默认的主分支。

Your branch is up to date with 'origin/main'.：这意味着你的本地 main 分支与远程仓库（通常称为 origin）中的 main 分支是同步的。换句话说，你本地的 main 分支包含了远程 main 分支上的所有最新更改。

nothing to commit, working tree clean：这表明你的工作目录是干净的，即你的工作目录中没有未跟踪（untracked）的文件，也没有已跟踪（tracked）但未提交（uncommitted）的更改。简而言之，你的工作目录与 Git 的头指针 HEAD 一致，没有任何更改待提交。

综上所述，这个 Git 状态信息告诉你，你当前在 main 分支上，你的本地仓库与远程仓库完全同步，并且你的工作目录中没有任何未提交或未跟踪的更改。

创建新文件后的状态变化

创建新文件（如 README），git status 会显示该文件为未跟踪状态。
未跟踪文件意味着 Git 在之前的快照中没有这些文件。

Git 状态输出:

On branch main: 你当前在 main 分支。

Your branch is up to date with 'origin/main'.: 你的本地 main 分支与远程仓库 origin 的 main 分支同步。

Untracked files: 显示 README 文件未被 Git 跟踪。这意味着该文件是新的或之前未被添加到 Git 仓库中。

(use "git add <file>..." to include in what will be committed): 这是一个提示，说明你可以使用 git add <file> 命令来开始跟踪这些文件。

nothing added to commit but untracked files present (use "git add" to track): 尽管没有文件被添加到提交（commit）中，但存在未跟踪的文件。如果你想将这些文件包含在下一个提交中，需要先使用 git add 命令将其添加到暂存区（staging area）。

简而言之，你创建或修改了 README 文件，但 Git 还没有开始跟踪这个文件。如果你想要将其更改包含在下一个提交中，你需要先用 git add README 将其加入暂存区，然后再进行提交。

2.2.2 跟踪新文件

使用 git add 开始跟踪文件（如 git add README）。

警告内容: 当你运行 $ git add README 时，出现了一个警告，指出在工作副本的 README 文件中，行结束符 LF（Line Feed，用于 UNIX/Linux 系统）将在 Git 下一次处理该文件时被 CRLF（Carriage Return Line Feed，用于 Windows 系统）替换。

原因: 这通常是由于 Git 的 core.autocrlf 配置引起的。在 Windows 系统上，Git 默认会将存储在仓库中的 LF 转换为 CRLF，当文件被提交或检出时，进行这种转换。这是为了确保跨平台的文件一致性，防止在不同操作系统之间切换时出现问题。

处理: 如果你希望保留原始的 LF 行结束符，可以通过更改 Git 配置来禁用这种自动转换，使用命令 git config --global core.autocrlf input。

文件被添加到暂存区后，git status 显示文件处于待提交状态。

Git 状态信息:

当前分支: 你在 main 分支上，且与远程 origin/main 分支同步。

更改待提交: README 文件被标记为新文件，并已添加到暂存区（staging area），准备进行下一次提交。

如何取消暂存: 如果你想取消暂存 README 文件，可以使用 git restore --staged <file> 命令。

这些信息表明，你已经成功将新文件 README 添加到了 Git 的暂存区，并准备好进行提交。

总结

已暂存状态（Staged State）:
1. 当文件显示在 "Changes to be committed" 下时，这意味着这些文件已经被暂存。
2. 暂存文件是准备被记录在下一个提交（commit）中的文件。也就是说，这些文件的当前状态（你最后一次使用 git add 时的状态）将被包含在接下来的提交中。
git add 的作用:
1. git add 命令用于开始跟踪新文件或将已更改的文件移至暂存区。
2. 这个命令不仅用于添加单个文件，还可以用于添加目录。当用于目录时，Git 会递归地将该目录下的所有更改加入暂存区。
3. git add 是一种预提交（pre-commit）步骤，它告诉 Git 你想在下一个提交中包含哪些更改。
提交过程（Committing Process）:
1. 执行 git commit 命令会将暂存区域中的更改记录到 Git 历史中。
2. 只有在暂存区域中的更改才会被提交。如果你在 git add 后对文件进行了更多的更改，这些新更改不会包含在即将进行的提交中，除非你再次执行 git add。
使用 git init 和 git add:
1. git init 用于初始化一个新的 Git 仓库。
2. 在一个新仓库中，使用 git add 开始跟踪文件是一个常见的首步操作。

2.2.3 暂存已修改的文件

修改已跟踪文件（如 CONTRIBUTING.md），git status 显示修改未暂存。

使用 git add 暂存修改。
若修改文件后再次修改，需要重新运行 git add。

状态简览

git status -s 或 git status --short 提供简洁的状态输出。
未跟踪文件前有 ??，已暂存文件前有 A，修改过的文件前有 M。
左栏显示暂存区状态，右栏显示工作区状态。

2.2.4 忽略文件

.gitignore 文件在 Git 仓库中用于指定应该忽略的文件和目录，以避免将它们加入到版本控制中。这通常包括编译生成的文件、日志文件或编辑器临时文件等。

.gitignore 文件的基本规则

忽略特定文件类型：使用模式如 *.[oa] 来忽略所有 .o 和 .a 结尾的文件。
忽略临时文件：使用 *~ 忽略编辑器生成的临时文件。
忽略特定目录：例如，使用 log/, tmp/, pid/ 忽略这些目录及其内容。
空行和注释：以 # 开头的行作为注释，被 Git 忽略。
使用 glob 模式：支持简化的正则表达式来匹配文件路径。

高级 .gitignore 配置

防止递归：以 / 开头的模式防止递归匹配。
指定目录：以 / 结尾的模式指定目录。
取反匹配：使用 ! 对特定模式取反，例如 !lib.a。

.gitignore 文件的实际应用

可以创建针对项目和语言特定的 .gitignore 文件。
GitHub 提供了一个广泛的 .gitignore 模板库：github/gitignore。
.gitignore 文件可以在仓库的根目录中使用，也可以在子目录中使用，仅应用于该目录。

注意事项

子目录中的 .gitignore 文件仅影响其所在目录。
对于复杂的项目，可能存在多个 .gitignore 文件。
详细的 .gitignore 配置可以通过 man gitignore 查看。
更多细节可参考 man gitignore 或 GitHub 的 .gitignore 文件列表。

通过适当配置 .gitignore 文件，可以确保仓库中不包含不必要的文件，从而使仓库保持清洁和组织有序。

2.2.5 查看已暂存和未暂存的修改

使用 git status 检查文件状态

你通常可能会用它来回答这两个问题：当前做的哪些更新尚未暂存？有哪些更新已暂存并准备好下次提交？

git status 显示哪些文件已暂存，哪些未暂存。
列出的文件名指示文件是否准备提交（已暂存）或有更改但未暂存。

使用 git diff 查看具体修改

git diff 显示未暂存文件的具体更改。
显示工作目录中的当前文件与暂存区快照之间的差异。

查看已暂存的更改

使用 git diff --staged 查看已暂存文件的更改（--staged 和 --cached 是同义词）。
比较已暂存文件与最后一次提交的文件差异。

处理多次修改的文件

对已暂存文件再次修改后，git status 会显示该文件在暂存区和工作目录中的状态。
git diff 显示最近的更改（自上次暂存以来的更改）。
git diff --cached 显示已暂存的更改。

2.2.6 提交更新

现在的暂存区已经准备就绪，可以提交了。在此之前，请务必确认还有什么已修改或新建的文件还没有 git add 过，否则提交的时候不会记录这些尚未暂存的变化。这些已修改但未暂存的文件只会保留在本地磁盘。所以，每次准备提交前，先用 git status 看下，你所需要的文件是不是都已暂存起来了，然后再运行提交命令 git commit：

准备提交

确认所需文件已经暂存。
使用 git commit 启动文本编辑器以输入提交信息。

提交信息的格式

编辑器中的默认信息包含 git status 的输出和注释行。
提交时，Git 会忽略注释行。

快速提交

可以使用 git commit -m 直接在命令行中提供提交信息。
提交后，Git 提供关于新提交的信息，如所在分支、SHA-1 校验和、变更概述。

提交的影响

提交记录的是暂存区的快照。
未暂存的更改不会包含在提交中，但保留在工作目录。

确保所有必要的更改都已暂存是进行提交之前的一个关键步骤。以下是这个过程的详细说明：

检查当前状态：
1. 使用 git status 命令来查看当前的工作状态。
2. 这个命令会显示所有已跟踪的文件中自上次提交以来的更改，包括已暂存（staged）和未暂存（unstaged）的更改。
暂存更改：
1. 如果发现有需要提交的文件还没暂存，使用 git add [file] 命令将这些文件添加到暂存区。
2. 对于新建的文件或已修改的文件都需要执行这个操作。
重新检查状态：
1. 再次运行 git status 确保所有需要的更改都已暂存。
2. 确认没有遗漏的文件或更改。
进行提交：
1. 所有必要的更改一旦暂存，就可以使用 git commit 命令来提交这些更改。
2. 在提交时，通常会打开文本编辑器让你输入提交信息。可以使用 git commit -m "commit message" 来提供简短的提交信息。