目标：整理Git工具的应用场景和使用经验
一、开发环境
Git是代码版本控制工具；Github是代码托管平台。工具组合：VSCode + Git需要安装的软件：vscode、Git其中vscode需要安装的插件：GitLens、Git History
二、应用场景
工作场景：嵌入式开发，多人本地使用三、使用总结
基础操作，参考廖雪峰的Git教程https://www.liaoxuefeng.com/wiki/896043488029600 Git 基本工作流程
3.1 版本管理
3.1.1 更改提交
git commit使用 git commit 将当前工作目录的更改保存到本地代码库。每次提交（commit）都会创建一个新的提交对象，避免将无关或不相关的修改混合在一起提交。3.1.2 版本回退
两种方式：reset、revertgit 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.03.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 falsegit config --global core.autocrlf false
git config --global core.filemode false
git config --global core.safecrlf true4.2 如何使.gitignore中新增设置对之前的文件生效
$ git rm -r --cached . #清除缓存 -r 表示递归删除（如果有文件夹的话） . 表示所有文件
$ git add . #重新trace file
$ git commit -m "update .gitignore" #提交和注释
$ git status --ignored #查看状态，包括忽略的文件资料整理自网络
标签：Git,git,合并,笔记,场景,提交,commit,分支 From： https://www.cnblogs.com/bog-box/p/18048299