Git
Git
目录
Git 高级用法
包括合并、分支、多人协作等
翻译问题
参考：复刻：为 fork 的中文翻译定名，GitHub中文帮助文档上线：统一术语翻译，Fork成“分叉”
另外几个常见的翻译：
- Repository：此前有人称其为仓库，有人翻译为版本库，有人则翻译成项目。现在统一称为 “仓库”
- Fork：翻译一直很有争议，因此通常不翻译。有翻译成分叉、也有翻译成分支的。 Linux中国翻译组（LCTT）的译者dongfengweixiao曾提议将Fork译作 “复刻”，词义和读音两方面都比较契合。现在官方将其翻译成“分叉”
- Issue：通常情况下选择不翻译，现在统一称作 “议题”
- Blame：考虑了中外的文化差异导致的理解偏差，被翻译成 “追溯”，
- Fetch：翻译成 “获取”
- Pull：翻译成 “拉取”
Commit规范、Commit message、Change log
参考：
- https://zhuanlan.zhihu.com/p/182553920
- https://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html
commit message格式
<type>(<scope>): <subject>
type(必须)
用于说明git commit的类别，只允许使用下面的标识。
| 类别 | 作用 |
|---|---|
| feat | 新功能（feature） |
| fix/to | 修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。 - fix：产生diff并自动修复此问题。适合于一次提交直接修复问题 - to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix |
| docs | 文档（documentation） |
| style | 格式（不影响代码运行的变动） |
| refactor | 重构（即不是新增功能，也不是修改bug的代码变动） |
| perf | 优化相关，比如提升性能、体验 |
| test | 增加测试 |
| chore | 构建过程或辅助工具的变动。 |
| revert | 回滚到上一个版本 |
| merge | 代码合并 |
| sync | 同步主线或分支的Bug |
scope(可选)
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
例如在Angular，可以是location，browser，compile，compile，rootScope， ngHref，ngClick，ngView等。如果你的修改影响了不止一个scope，你可以使用*代替。
subject(必须)
subject是commit目的的简短描述，不超过50个字符。
建议使用中文（感觉中国人用中文描述问题能更清楚一些）。
- 结尾不加句号或其他标点符号。
- 根据以上规范git commit message将是如下的格式：
fix(DAO):用户查询缺少username属性
feat(Controller):用户查询接口开发
以上就是我们梳理的git commit规范，那么我们这样规范git commit到底有哪些好处呢？
- 便于程序员对提交历史进行追溯，了解发生了什么情况。
- 一旦约束了commit message，意味着我们将慎重的进行每一次提交，不能再一股脑的把各种各样的改动都放在一个git commit里面，这样一来整个代码改动的历史也将更加清晰。
- 格式化的commit message才可以用于自动化输出Change log。
Brach
先来说一下github.com界面
顶部左
Issues
提出bug、功能请求等
Pull requests 拉取请求（合并代码）
合并用的，要先Fork !!!
设置里有相关的设置，默认设置为：
- [x] 允许合并提交
- [x] 允许？？合并
- [x] 允许？？合并
- [ ] 始终建议更新拉取请求分支
- [ ] 允许自动合并
- [ ] 自动删除头部分支
这里有一张很好的图：
Actions
Projects
Wiki
类似于说明文档的东西
Security
Insights
Setting
设置
顶部右
Pin
Unwatch
Fork
这里有一张很好的图：
区分 Fork & Braches
Fork，直译：分流支流
“流”，有上流和下流，上流是原仓库，
下流是我的……呸，下流是克隆下来仓库用来将某个仓库克隆到你的账户之下，从而可以对其进行修改、衍生，也可以比较方便的将你的修改推回到原来的仓库（所谓的上游）。
Fork更准确的中文翻译是什么？
参考：复刻：为 fork 的中文翻译定名，GitHub中文帮助文档上线：统一术语翻译，Fork成“分叉”
主要翻译成：
- 复刻 (中文维基同款)
- 派生 (git软件包里蒋新的翻译)
- 分叉 (Github中文帮助文档的翻译)
在 GitHub 上评价一个项目（仓库）是否流行，其中一个重要指标就是其复刻数
在 GitHub 上参与一个开源项目的程度有三个阶段：
- star（点赞），如果你觉得某个项目不错，可以为其点赞（star）
- watch（关注），如果你希望进一步关注这个项目的进展，可以关注（watch）它
- fork（复刻），如果你还想进一步为这个项目做一些贡献，可以复刻（fork）它到你自己的账户下，做出了修改之后通过 Pull-Request（PR）方式将你的改动推回给原仓库（上游），如果被接纳就会进入到原仓库之中
Branch，直译：分支分叉
Starred
追踪问题
追踪中删除
当你删除一个已经存在的文件并修改.gitignore来忽略该文件后，如果文件再次产生，它将不会被自动同步到仓库。
但是，你需要确保已正确地将文件从Git历史中删除。仅从工作目录中删除文件并不足以将其从Git历史中删除。
git rm 文件名
git commit -m "删除 文件名"
查看所有追踪的文件
git ls-files
根据.ignore删除追踪的文件
git ls-files -ci --exclude-standard -z | xargs -r -0 git rm --cached
删除所有不存在的追踪文件
这里不需要加 --cached，该选项主要用于从Git索引中删除文件，而在工作目录中保留该文件。
其实上一个例子也可以不加的，可能会更好
git ls-files --deleted -z | xargs -r -0 git rm
实战中遇到的问题：管理编译产物
GPT：
Q：如果我有一个文件夹，需要存放release的html项目。而用vue框架build出来的dist文件夹里，.js文件的命名是随机的。 如果我使用git管理，在多次迭代中是否会产生大量的冗余的追踪文件
A：如果您使用Git来管理包含随机命名的.js文件的项目，确实有可能在多次迭代中产生大量冗余的追踪文件。这是因为在每次构建过程中，随机命名的.js文件可能会被视为新文件并被添加到Git仓库中。这将导致旧版本的文件依然存在于Git历史记录中，从而增加了仓库的大小。
为了避免这种情况，您可以采用以下几种策略：
- 不要将构建产物（如
dist文件夹）添加到Git仓库：在.gitignore文件中添加dist/，以避免将dist文件夹添加到版本控制。您可以将构建产物部署到其他存储或托管服务，例如使用CI/CD（持续集成/持续部署）管道。 - 在每次构建之前清理
dist目录：在每次运行构建命令之前，确保先清理dist目录。这样，您可以确保只有当前构建产生的文件存在于dist目录中。大多数构建工具（如Webpack）都提供了自动清理目标目录的功能。 - 定期清理Git历史记录：虽然这并不能完全解决问题，但定期清理Git历史记录可以帮助减小仓库大小。使用
git filter-branch、git rebase或BFG Repo-Cleaner等工具可以从历史记录中删除不再需要的文件。请注意，这些操作可能会重写Git历史记录，因此在执行这些操作时要格外小心，确保您了解它们的影响。
建议您采用第一种策略（不将构建产物添加到Git仓库），因为这是最符合实践的方法。这样，您可以专注于源代码的版本控制，而将构建产物部署到其他适当的托管服务。
Q：第二种策略会清除git的追踪文件？你确定？
A：抱歉，我在先前的回答中的表述不够准确。第二种策略（在每次构建之前清理dist目录）并不能直接解决Git冗余追踪文件的问题。在每次构建之前清理dist目录可以确保当前构建产生的文件不会与之前的构建产物混淆，但它不能自动从Git历史中删除这些文件。
实际上，最佳实践是不要将构建产物（如dist文件夹）添加到Git仓库。您应该遵循第一种策略，即在.gitignore文件中添加dist/，以避免将dist文件夹添加到版本控制。这将确保Git仓库中不会产生大量冗余追踪文件。
另外，您可以使用CI/CD（持续集成/持续部署）流程，将构建产物部署到其他存储或托管服务，而不是将它们包含在Git仓库中。
最后
emmm由于公司一向使用svn管理web的构建产物，无可更改。我最后决定：使用压缩包代替。 也许可能有的版本管理系统有的并不具备二进制文件的压缩存储功能，但管他呢，硬盘空间肯定是不缺那么一点点的，能让自己提交时少看点乱七八糟的文件，让自己更加舒服还是最重要的。
Git嵌套问题
这种情况有很多，最简单的就是记录下别人的git链接。
但问题在于：被嵌套的git库不公开怎么办？
- 情况一：我的 stable diffusion 是开源git，而内部又有多个git开源模型
- 不过这种情况下，两个git管理的范围其实没重叠，外部git是避开了内部git的位置
- 情况二：我的 pressvue 有个git，内部的多个文件夹的笔记有各自的git
- 0