官方教程文档:Redirecting…
0 什么是 Git
有以下三个区别于其他版本控制工具的特点:
- 基于快照而非差异的版本控制
- 所有操作都基于本地执行
- 保证完整性,不可能在Git不知情的情况下修改内容,使用文件哈希作为索引而非文件名
- 几乎不会执行任何可能导致文件不可恢复的操作
- 已提交(committed):修改了文件,但还没保存到数据库中
- 已修改(modified):对一个已修改文件的当前版本做了标记,使之包含在下次提交的快照中
- 已暂存(staged):数据已经安全地保存在本地数据库中
1 Git 基础
安装看官方文档即可,Git 在安装后需要进行配置:常用git配置项。
init | 配置并初始化一个仓库(repository)。 |
---|---|
向 Git 中添加要追踪的文件 | 添加工作区的文件到 Git 暂存区中,下一次提交就会提交暂存区的文件。 |
在 Git 中正则匹配忽略文件 .gitignore | 总有一些程序生成的文件或临时数据没有必要被 Git 处理,不仅不需要提交,也不必在 git status 中显示。 |
使用 git diff 查看文件详细差异 | 查看文件在已暂存和未暂存的版本中出现的差异。 |
提交暂存区的更新 | 将目前暂存区的内容提交到分支上。 |
删除在 Git 中已跟踪在暂存区的文件 | 若错误使用 git add ,可以删除已加入暂存区的文件,也可以强制从 Git 仓库中删除包括该文件的历史提交快照。 |
移动和改名在 Git 中已跟踪在暂存区的文件 | 重命名和移动文件位置也需要记录并提交。 |
查看git日志信息 | 查看git日志信息,并按日期,作者,甚至具体修改的代码段来检索 |
暂存区的修改 | 通过使用 restore 回滚到上次提交/工作区的版本来撤销刚才所做的修改,只包括单文件而非所有内容 |
2 远程仓库
为了能在任意 Git 项目上协作,你需要知道如何管理自己的远程仓库。 远程仓库是指托管在因特网或其他网络中的你的项目的版本库。管理远程仓库包括了解如何添加远程仓库、移除无效的远程仓库、管理不同的远程分支并定义它们是否被跟踪等等。
查看Git远程仓库 | 通常是查看本地 Clone 下来的远程仓库信息 |
---|---|
新建远程仓库 | 除了 clone 也可以使用 remote add,还能设置别名并且避免直接拉取 |
推动更改到远程仓库 | 需要提供服务器名称/链接,以及自己要推送的分支名 |
重命名远程仓库 | 重命名本地已经存在的远程仓库服务器简写名 |
删除远程仓库 | 删除本地的一个远程仓库 |
抓取远程仓库新更新的内容 | 会将远程服务器中抓取本地没有的内容,如果别人基于某个提交进行修改,也会抓取并新建一个对应人的分支 |
3 打标签
像其他版本控制系统(VCS)一样,Git 可以给仓库历史中的某一个提交打上标签,以示重要。 比较有代表性的是人们会使用这个功能来标记发布结点( v1.0
、 v2.0
等等)。
列出标签 | 列出当前git仓库下的所有标签,或只列出需要的标签 |
---|---|
新建标签 | 新建一个本仓库的标签,并自动标记到最新的提交上 |
[[202501071410 git tag#git tag -a | 对历史提交添加标签 |
显示标签对应的提交信息 | 显示对应标签的提交信息,或者显示最新的提交信息 |
[[202501061731 git push#git push | 默认标签只会打在本地仓库中,需要使用 git push 命令来推送到远程仓库 |
[[202501071410 git tag#git tag -d | 删除本地仓库的标签,以及远程仓库的标签 |
[[202501061710 git checkout#git checkout | 会临时将当前工作区的内容用某个标签对应的版本替换掉,并且无法恢复未保存的提交,同时处于分离指针状态无法直接提交必须先创建分支 |
4 Git 分支
所有版本控制系统都以某种形式支持分支,使用分支可以把你的工作从开发主线上分离开来,以免影响开发主线。而Git的分支模型是轻量且高效的,通过 HEAD指针 可以确定当前分支。
本地分支管理
创建分支 | 新建一个分支指针 |
---|---|
查看所有分支 | 列出所有分支名 |
删除分支 | 删除某个分支指针 |
查看分支所指对象 | 查看所有存在的分支指针所指的提交对象 |
[[202501061710 git checkout#git checkout | 切换到某个分支指针指向的提交对象并重置工作区到对应版本 |
查看所有分支指向提交对象历史 | 输出你的提交历史、各个分支的指向以及项目的分支分叉情况 |
合并分支 | 向前合并、分叉合并以及对合并冲突的解决 |
变基合并 | 相比合并可以省去分支历史 |
远程分支相关
推送分支到远程仓库 | 本地新建的分支不会自动同步到远程仓库,需要自己显式推送 |
---|---|
跟踪分支 | 创建远程仓库对应的分支来进行修改 |
查看所有分支的跟踪情况 | 比查看所有分支有着更多的信息 |
拉取并合并分支 | 即先进行拉取,再对拉取的内容与本地追踪分支合并 |
删除远程分支 | 完成所有工作且服务器上已经合并到 master,则可以删除在服务器上对应的远程分支 |
5 分布式工作流程
几大工作体系
集中式 | 单点协作模型,前者做了修改后,后者必须先合并前者的提交再进行修改 |
---|---|
多仓库工作流 | GitHub 和 GitLab。每个开发者都有自己的关于项目的仓库 |
主管与副主管 | 是多仓库工作流的变种,一般有数百位开发者的超大型项目才会使用 |
作为项目贡献者
三大影响因素:
- 活跃贡献者的数量,小的可能有两三个开发者一天提交几次,多的可能几百个开发者每天提交上千次。开发者越多,你代码合并中就会遇到更多问题,提交的改动可能是过时的。
- 项目使用的工作流程,项目是否有检查所有补丁的维护者或整合者,是否所有补丁都经过同行评审后批准且你是否参与到过程,是否有副主管体系而你需要先提交在上面
- 提交权限,若项目没有给你写权限会提供哪种方式接受贡献,是否有一个贡献的规范,你一次贡献多少、多久贡献一次比较好
私有小型团队贡献样例 | 只有一两个其他开发者的私有项目 |
---|---|
私有管理团队贡献样例 | 有几个开发者小组,并有一个管理合并的整合工程师 |
派生的公开项目 | 自己没有权限的公开项目 |
作为项目维护者
新东西应该局限在主题分支 | 一些补丁或者别人的贡献要单独新建一个主题分支 |
---|---|
应用diff产生的 .patch 补丁 | 通过邮件收到别人通过 git diff 生成的一个 .patch 后缀的打包补丁 |
应用 format-patch 产生的 .patch 补丁 | 通过邮件收到别人通过 git format-patch 生成的一个 .patch 后缀的打包补丁 |
抓取贡献者的远程分支 | 适合长期合作的贡献者,频率高且补丁多,上面两种适合频率小的贡献者 |
查看贡献者远程分支的差异 | 抓取下来后查看更新内容并考虑是否合并 |
整合贡献工作—合并工作流 | 分为 master 和 develop 两个长期分支 |
整合贡献工作—变基与挑拣工作流 | 为了保持线性的提交历史和仅保留某些提交到主分支 |
准备一次发布并导出简报 | 使用 archive 制作压缩包和使用 shortlog 来导出简报 |
6 GitHub
GitHub 是最大的 Git 版本库托管商,是成千上万的开发者和项目能够合作进行的中心。在 GitHub 上会集成 Git 一些功能,并省去我们手动通过邮件沟通的麻烦。
Git - 对项目做出贡献 | 作为贡献者的样例 |
---|---|
Git - 维护项目 | 作为维护者的样例 |
这就是大部分 GitHub 项目使用的工作流程。创建分支,基于分支创建拉取请求,进行讨论, 根据需要继续在分支上进行修改,最终关闭或合并拉取请求。
你可以在同一个版本库中不同的分支提交拉取请求。 如果你正在和某人实现某个功能,而且你对项目有写权限,你可以推送分支到版本库, 并在 master
分支提交一个拉取请求并在此进行代码审查和讨论的操作。不需要进行“Fork”。
~ 后记
- 初版Git基础完成,学了前六章,大概掌握了Git仓库、分支、标签、提交、远程协作的一些内容,打个基础应该已经够了。 20250121143022