笔记：Git学习之应用场景和使用经验

目标：整理Git工具的应用场景和使用经验

一、开发环境

Git是代码版本控制工具；Github是代码托管平台。

工具组合：VSCode + Git

需要安装的软件：vscode、Git

其中vscode需要安装的插件：GitLens、Git History

二、应用场景

工作场景：嵌入式开发，本地使用

三、使用总结

基础操作，参考廖雪峰的Git教程

Git教程 - 廖雪峰的官方网站

Git 基本工作流程

3.1 版本管理

3.1.1 更改提交

git commit

使用 git commit 将当前工作目录的更改保存到本地代码库。

每次提交（commit）都会创建一个新的提交对象，

避免将无关或不相关的修改混合在一起提交。

3.1.2 版本回退

两种方式：reset、revert

git reset

通过改变HEAD和分支指针指向的方式，进行版本回退，

该操作之后的提交记录不会被保留，并且不会创建新的提交；

git revert

通过创建一个新提交的方式来撤销某次操作，该操作之前和之后的提交记录都会被保留，

并且会将该撤销操作作为最新的提交；

在个人开发上，建议使用reset；但在团队开发中建议使用revert，

特别是公共的分支（比如master)，这样能够完整保留提交历史，方便回溯。

3.2 分支管理

一个分支代表一条独立的开发线，使用分支可以从开发主线上分离开来，

不影响主线的同时继续工作。

注：未被放入代码库的文件会在分支切换时被抛弃，造成严重后果。

3.2.1 分支切换

git switch

使用git switch <branch_name> 来切换到指定的分支。

3.2.2 分支合并

两种方式：merge、rebase

相同点：都是从一个分支合并到当前分支。

注意：无论选择哪种方式，都应该谨慎处理可能产生的冲突，

并确保在操作前备份代码或创建临时分支以防意外。

git merge

自动创建一个新的commit，如果遇到冲突，仅需要修改后重新commit。

方式：git merge会将目标分支的提交历史合并到当前分支，形成一个新的合并提交。

这种方式被称为"合并提交"或"三方合并"，因为它保留了每个分支的独立提交历史。

结果：合并后的提交历史会包含源分支和目标分支的所有共同提交以及合并提交。

场景：适用于合并公共分支、团队开发时的代码集成，或者希望保留分支独立性的情况。

合并稳定的公共分支，如主分支或发布分支。多人协作开发时，将各自的特性分支合并到开发分支。

git rebase

找公共的节点，直接合并之前commit历史，得到简洁的分支发展历史，去掉了merge commit。

方式：git rebase会将当前分支的提交"移动"到目标分支的最新提交之后，

然后将目标分支的提交历史应用到当前分支。这种方式被称为"变基"，因为它改变了提交的基点。

结果：合并后的提交历史是线性的，没有合并提交，看起来更加整洁。

但是原始分支的提交历史会被修改，可能会导致冲突。

场景：适用于想要保持线性提交历史、清晰的提交记录，并希望将自己的提交"放到"目标分支上进行整合的情况。

最好不要在公共分支上使用rebase，如果前后基本上不会有别人改动你的分支，那么推荐rebase。

总结来说，在单人本地多分支开发中，使用变基操作来修复bug并更新所有分支是可行的，

可以确保所有分支都包含了最新的修复，并保持提交历史的线性和清晰。

但是仍然建议在执行变基操作之前，仔细考虑其可能带来的影响，并确保备份了代码。

3.3 标签管理

标签也是版本库的一个快照。

发布版本时，通常在版本库中打个标签（tag），则唯一确定打标签时刻的版本。

切换到某个标签，则相当于把打标签时刻的历史版本取出。

注意：标签总是和某commit挂钩。若该commit既出现在master分支，

又出现在dev分支，则在这两个分支上都可看到此标签。

3.3.1 标签切换

使用git checkout <tagname>可将git仓库的HEAD指针指向标签所在的提交，

如：git checkout v1.0

3.4 开发管理

涉及到多人协作，如果没有清晰的流程和规划，每个人都提交一堆杂乱无章的 commit，

项目很快就会变得难以协调和维护。Git 版本管理同样需要一个清晰的流程和规范。

3.4.1 Git flow

Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。

该模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。

长期分支：主分支master、开发分支develop。

前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；

后者用于日常开发，存放最新的开发版。

短期分支：功能分支（feature branch）、补丁分支（hotfix branch）、发布分支（release branch）。

3.4.2 Github flow

Github flow 是Git flow的简化版，专门配合"持续发布"。

3.4.3 Gitlab flow

Gitlab flow 是 Git flow 与 Github flow 的综合。

它吸取两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。

四、经验总结

4.1 文件未修改，但出现在工作区

修改文件权限可修复该异常。

项目修改：git config core.filemode false
全局修改：git config --global core.filemode false

如果在Linux和windows之间传递代码，可能出现该异常。

修改换行符转换设置，可修复该异常。

git config --global core.autocrlf false
git config --global core.filemode false
git config --global core.safecrlf true

4.2 如何使.gitignore中新增设置对之前的文件生效

$ git rm -r --cached .                #清除缓存 -r 表示递归删除（如果有文件夹的话） . 表示所有文件
$ git add .                           #重新trace file
$ git commit -m "update .gitignore"   #提交和注释$ git status --ignored                #查看状态，包括忽略的文件

4.3 导出历史提交记录

git log --pretty=format:"%ai , %an: %s" >> ./commit.log

在项目根目录下执行命令,导出 git 提交记录到桌面git log --pretty=format:"%ai , %an: %s" --since="100 day ago" >> ./commit.log
如果想导出某些提交者的提交记录,可以用grep过滤,比如我想导出zen这个人在项目中的提交记录:git log --pretty=format:"%ai , %an: %s" --since="126 day ago" | grep "zen" >> ./commit.log
当然也可以导出成 Excel 文件git log --date=iso --pretty=format:'"%h","%an","%ad","%s"' >> ./commit.log%ai: 表示提交的时间，格式为 ISO 8601 标准的时间（例如 2024-04-16 14:30:00）。
%an: 表示提交者的名字。
%s: 表示提交时填写的概要或简短描述。

选项	说明
`-p`	按补丁格式显示每个提交引入的差异。
`--stat`	显示每次提交的文件修改统计信息。
`--shortstat`	只显示 --stat 中最后的行数修改添加移除统计。
`--name-only`	仅在提交信息后显示已修改的文件清单。
`--name-status`	显示新增、修改、删除的文件清单。
`--abbrev-commit`	仅显示 SHA-1 校验和所有 40 个字符中的前几个字符。
`--relative-date`	使用较短的相对时间而不是完整格式显示日期（比如“2 weeks ago”）。
`--graph`	在日志旁以 ASCII 图形显示分支与合并历史。
`--pretty`	使用其他格式显示历史提交信息。可用的选项包括 oneline、short、full、fuller 和 format（用来定义自己的格式）。
`--oneline`	`--pretty=oneline --abbrev-commit` 合用的简写。

选项	说明
`%H`	提交的完整哈希值
`%h`	提交的简写哈希值
`%T`	树的完整哈希值
`%t`	树的简写哈希值
`%P`	父提交的完整哈希值
`%p`	父提交的简写哈希值
`%an`	作者名字
`%ae`	作者的电子邮件地址
`%ad`	作者修订日期（可以用 --date=选项来定制格式）
`%ar`	作者修订日期，按多久以前的方式显示
`%cn`	提交者的名字
`%ce`	提交者的电子邮件地址
`%cd`	提交日期
`%cr`	提交日期（距今多长时间）
`%s`	提交说明
%ai	表示提交的时间，格式为 ISO 8601 标准的时间