一.Git提交规范
一次提交包含四个信息：
- commit message - 提交的内容相关描述
- author & committer - 作者及提交者
- changed files - 修改的文件
- hash & parent - 提交内容的hash及在提交树上的位置
1.提交信息
一般包括<header><body><footer>三部分。
<header>是必须的，一般在50个字符之内，其结构为：（其中<scope>可以不写）
<type>(<scope>): <short summary>
│ │ │
│ │ └─⫸ Summary in present tense. Not capitalized. No period at the end.
│ │
│ └─⫸ Commit Scope: animations|bazel|benchpress|common|compiler|compiler-cli|core...
│
└─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test<type>表明本次提交的类型，一般有如下几种：
build: 涉及构建相关的改动ci: 持续集成相关的改动docs: 文档feat: 新功能fix: bug修复perf: 性能相关改动refactor: 重构相关（非bug、非新功能）test: 测试相关，包括新增测试或者更改已有测试
<summary>使用现在时或祈使句。
<body>提交信息的更为详细的描述，与<header>一样也是用祈使句、现在时。<body>描述本次 修改的动机，比如为什么引入本次改动，之前的逻辑是什么，现在的逻辑是什么，本次改动有哪些影响，等等。
最后,<footer>是可选项，一般涉及破坏性改动、功能的弃用等说明，以及对GitHub issue或Jira ticket的引用，PR的引用等。
1.1自动化校验
通过使用Git hooks达成目的。
想使用相关的Git Hooks，可以在目录.git/hooks创建对应的文件，文件名为prepare-commit-msg 及commit-msg，并赋予可执行权限。这样在我们进行git commit操作时，对应的脚本就会执行。
Git的提交不会包含.git目录，所以对应的hooks的改动并不会被提交到仓库中。我们可以在仓库根目录 创建.githooks文件夹并将我们实现的代码放到该目录中，通过更改配置或者软连接的方式进行引用：
2 Author & Committer
3 Changed files
（此处复制教程原文）
- 提交前使用
git diff查看文件的改动，使用git add添加期望进入提交的文件， 使用git status查看文件状态，最终使用git commit进行提交 - 单次提交仅提交相关的改动，例如修复两个不同的bug应该使用两次独立的提交
- 鼓励经常性的提交，这样可以更快的分享实现的功能，并且减少代码丢失的风险
- 在主分支或者协作的功能分支不能提交半成品，提交之前需要进过测试
- 编译输出，日志，中间产物等，不要引入到提交中，使用
.gitignore进行相关文件的排除，不同语言 或者操作系统有一些通用的排除配置，参考github/gitignore - 密码、授权凭证、密钥等，不要提交。如AWS的certificate.csv文件或内容， GCP的Service Account文件等，泄露到公开仓库会导致资源被不法分子使用，造成损失。同时由于Git的特性， 想从历史提交中移除这类文件会较为困难，参考GitHub官方相关文档及描述
- 对于配置文件（如数据库连接信息等），一般使用配置模板，个人维护本地文件，且该文件在
.gitignore中配置。或者使用git update-index --[no-]assume-unchanged <file>来忽略某些文件的改动 - 其他一些常用命令（请在明确知道其含义后使用）
git reset <file>- 移除被添加的文件（提交之前），reset命令的其他可以查看帮助文档git clean -f- 移除较多的未被追踪的中间文件git checkout <file>- 回退对某个文件的改动（提交之前）
4 Hash & Parent
- 在一些Git工作流模型中，使用
git pull --rebase对本地提交进行更新 - 原则上禁止对主分支等进行
git push -f操作，涉及需要回退的，使用git revert <commit> - 涉及多分枝代码同步，可以使用
git cherry-pick命令
二、Git使用说明
1 使用Github托管代码
1.2创建仓库
在git主页右上角点击+号，跳转表单。
注意：
- github上的仓库一般都会包含readme文件，该readme文件会在项目页面进行展示
- .gitignore文件可以用来忽略工作区的私有文件（例如本地配置、缓存文件、node_modules等）
点击绿色code按钮可获得项目地址，本地clone后即可开发，开发后push到仓库。
1.3 仓库界面介绍
1.star表示别人对项目的认可，最好别乱刷集赞式搜集star.
2.Fork操作可建立仓库副本，方便多人协作。
3.Watch操作可向邮箱推送信息。
4.Issues:Issues在Github官方文档中被翻译为议题，作用是针对仓库的内容进行讨论（例如bug反馈/新功能推荐）
5.Pull Requests：Pull Requests，简称PR，是github中将修改过的代码分支合并到目标分支的操作。前面git的学习中，我们都知道commit是git的最小工作单元，在github的仓库中，PR是主要的工作单元。很多同学刚刚接触GitHub时，对于Pull Requests很不理解：什么是拉取请求？在gitlab中，pr的操作叫做Merge Request， 实际上大家可以把PR理解为“我修改好了你的代码，现在请求你把代码拉回主仓库中”
6.Action：Github Action 是GitHub推出的自动化构建工具，感兴趣的同学可以阅读文档
7.Projects：针对某一仓库的项目板（看板）
8.Wiki： 存放一些介绍性的内容
9.Security：与安全相关，这里不做介绍
10.Insight：里面包含里项目的一些数据，包括代码贡献的时间分布图，每个人的贡献量等metric
11.discussion：vscode仓库中并没有开启discussion功能，这里展示一下wagtail社区的，该功能像一个真正的讨论区
2 提交issue
vscode中可点击bug report.
3 提交PR
点击New pull request即可新建pr。
一些注意点和教程原文：
注意：不是所有的PR都会被合并，所以在提交PR前请先和maintainer进行沟通，并且在开发的过程中反馈进度，一种比较好的方式就是draft PR。
draft PR表示该PR还没有开发完，项目的maintainer不需要进行reveiw和merge，只需要简单看看代码是否符合预期。
小提示：在提交PR时，尽可能关联相关Issue，并说明你的代码解决了什么问题。
4 探索Github
1.Github explore
2.快捷键
ctrl/command+k可以直接进行搜索。
完整的快捷键见文档键盘快捷键 - GitHub Docs
3.高级搜索（如何使用？）
4.内置 IDE-CodeSpace
在你的仓库界面，输入英文状态下的 .，即可进入该项目的web editor，这实质上是一个云端的vscode，方便用户查找编辑代码。很可惜现在CodeSpace还不能支持在线运行代码，一些简单的修改可以配合Action使用。
5.Copilot
还在内测阶段，是代码补全工具，暂不做详细描述。
6.用户主页
7.用数据探索GItHub-GitHub API
Github对针对开发者提供了一系列API，详情见Developers - GitHub Docs 。
8.保持清醒和正义
5 国内其他代码托管平台简介
Gitee Gitee - 基于 Git 的代码托管和研发协作平台
在Gitee创建仓库时，点击右上角点击导入即可导入其他平台的项目。
399
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
