54人参与 • 2025-11-25 • 其他编程
a、集中式版本控制工具
集中式版本控制工具,版本库是集中存放在中央服务器的,team 里每个人 work 时从中央服务器下载代码,是必须联网才能工作,局域网或互联网。个人修改后然后提交到中央版本库。
举例:svn 和 cvs
b、分布式版本控制工具
分布式版本控制系统没有 “中央服务器”,每个人的电脑上都是一个完整的版本库,这样工作的时候,无需要联网了,因为版本库就在你自己的电脑上。多人协作只需要各自的修改推送给对方,就能互相看到对方的修改了。
举例:git
git 是分布式的,git 不需要有中心服务器,我们每台电脑拥有的东西都是一样的。我们使用 git 并且有个中心服务器,仅仅是为了方便交换大家的修改,但是这个服务器的地位和我们每个人的 pc 是一样的。我们可以把它当做一个开发者的 pc 就可以就是为了大家代码容易交流不关机制的。没有它大家一样可以工作,只不过 “交换” 修改不方便而已。
git 是一个开源的分布式版本控制系统,可以有效、高速地处理从很小到非常大的项目版本管理。git 是 linus torvalds 为了帮助管理 linux 内核开发而开发的一个开放源码的版本控制软件。同生活中的许多伟大事物一样,git 诞生于一个极富纷争大举创新的年代。linux 内核开源项目有着为数众多的参与者。绝大多数的 linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上(1991-2002 年间)。 到 2002 年,整个项目组开始启用一个专有的分布式版本控制系统 bitkeeper 来管理和维护代码。
到了 2005 年,开发 bitkeeper 的商业公司同 linux 内核开源社区的合作关系结束,他们收回了 linux 内核社区免费使用 bitkeeper 的权力。 这就迫使 linux 开源社区(特别是 linux 的缔造者 linus torvalds)基于使用 bitkeeper 时的经验教训,开发出自己的版本系统。他们对新的系统制订了若干目标:
速度

流程节点与命令说明
| 步骤 | 操作 | 涉及区域 | 命令 | 说明 |
|---|---|---|---|---|
| 1 | 抓取 / 克隆 | 远程仓库 → 本地仓库 | clone | 从远程仓库中克隆代码到本地仓库 |
| 2 | 检出 | 本地仓库 → 工作区 | checkout | 从本地仓库中检出一个仓库分支然后进行修订 |
| 3 | 添加 | 工作区 → 暂存区 | add | 在提交前先将代码提交到暂存区 |
| 4 | 提交 | 暂存区 → 本地仓库 | commit | 提交到本地仓库,本地仓库中保存修改的各个历史版本 |
| 5 | 拉取 | 远程仓库 → 工作区 | pull(fetch+merge) | 从远程库拉到本地库,自动进行合并 (merge),然后放到工作区 |
| 6 | 推送 | 本地仓库 → 远程仓库 | push | 修改完成后,需要和团队成员共享代码时,将代码推送到远程仓库 |
| - | 抓取 | 远程仓库 → 本地仓库 | fetch | 从远程库抓取到本地库,不进行任何合并动作,一般操作比较少 |
区域说明
1)在电脑的任意位置创建一个空目录(例如 test)作为我们的本地 git 仓库
2)进入这个目录中,点击右键打开 git bash 窗口
3)执行命令 git init
4)如果创建成功后可在文件夹下看到隐藏的.git 目录。
创建一个文件夹->进去文件夹->右键点击后选择git bash here->输入命令 git init

git 工作目录下对于文件的修改 (增加、删除、更新) 会存在几个状态,这些修改的状态会随着我们执行 git 的命令而发生变化。
| 区域 | 说明 | 状态与转换 |
|---|---|---|
| 仓库(repository) | 修改进入到仓库就变成了一次提交记录 | 包含多次提交记录(如 commit 01、commit 02、commit 03),通过git commit命令从暂存区提交而来 |
| 暂存区(index) | 提交到仓库之前的缓存区 | 状态为已暂存(staged),通过git add命令从工作区转换而来 |
| 工作区(workspace) | 开发者实际编写、修改代码的区域 | 包含两种状态:-未暂存(unstaged):修改已有文件后的状态-未跟踪(untracked):新创建一个文件后的状态均可通过git add命令转换到暂存区 |
基础指令与状态转换
git add:实现工作区到暂存区的状态转换git commit:实现暂存区到本地仓库的状态转换
| 指令类别 | 作用 | 命令形式 | 补充说明 | |
|---|---|---|---|---|
| 查看修改的状态(status) | 查看暂存区、工作区中文件修改的状态 | git status | 可直观了解文件是未跟踪、已修改还是已暂存,是 git 操作的 “状态仪表盘” | |
| 添加工作区到暂存区(add) | 添加工作区一个或多个文件的修改到暂存区 | git add 单个文件名 | 通配符 <br> 示例:git add .`(将所有修改加入暂存区) | 是连接工作区和暂存区的关键指令,提交前需先执行该操作将修改 “暂存” |
| 提交暂存区到本地仓库(commit) | 提交暂存区内容到本地仓库的当前分支 | git commit -m '注释内容' | -m 用于指定提交说明,需简洁描述本次提交的修改意图,方便后续追溯版本 |
这些指令是 git 版本控制的核心流程节点:
通过git status掌握文件状态,用git add将修改纳入暂存区,再通过git commit固化为本地仓库的版本记录,从而完成一次完整的 “修改 - 暂存 - 提交” 版本管理流程。
| 维度 | 核心信息 |
|---|---|
| 作用 | 查看提交记录 |
| 命令形式 | git log [option] |
| 可选参数(options) | - --all:显示所有分支- --pretty=oneline:将提交信息显示为一行- --abbrev-commit:使得输出的 commitid 更简短- --graph:以图的形式显示 |
| 别名说明 | 在 3.1.3 中配置的别名git-log包含这些参数,后续可直接使用git-log指令 |
解读:
git log是追溯代码版本历史的关键指令,通过不同参数可定制输出形式。
--all能跨分支查看提交,--pretty=oneline简化信息展示,--abbrev-commit缩短 commitid 提升可读性,--graph则以可视化图形呈现分支合并历史,这些参数让开发者能高效定位历史版本、分析分支演进。
git log --pretty=oneline --abbrev-commit --all --graph
| 维度 | 核心信息 |
|---|---|
| 作用 | 版本切换 |
| 命令形式 | git reset --hard commitid |
| commitid 查看方式 | 可使用 git-log 或 git log 指令查看 |
| 已删除提交记录查看 | 可通过 git reflog 命令查看已经删除的提交记录 |
解读:
版本回退是 git 应对代码错误、需求变更的关键能力。
git reset --hard commitid 可让代码库直接切换到指定 commitid 对应的版本;git reflog 则能追溯包括已删除提交在内的所有操作历史,为版本恢复提供了兜底保障,是 git “时光回溯” 特性的重要支撑
| 维度 | 核心信息 |
|---|---|
| 适用场景 | 存在无需 git 管理的文件(如自动生成的日志文件、编译临时文件等),且不希望其出现在未跟踪文件列表 |
| 实现方式 | 在工作目录中创建名为 .gitignore 的文件(文件名固定),列出需忽略的文件模式 |
| 示例说明 | 以下是 .gitignore 规则示例及含义:- # no .a files:注释,说明规则意图- *.a:忽略所有以 .a 为后缀的文件- !lib.a:例外规则,即使上一条忽略 *.a,仍跟踪 lib.a 文件- /todo:仅忽略当前目录下的 todo 文件,不忽略子目录中的 todo 文件- build/:忽略 build 目录下的所有文件- doc/*.txt:忽略 doc 目录下所有以 .txt 为后缀的文件,但不忽略 doc/server/arch.txt- doc/**/*.pdf:忽略 doc 目录及其所有子目录中以 .pdf 为后缀的文件 |
解读:
.gitignore 是 git 管理 “无需版本控制文件” 的核心机制,通过灵活的规则语法(通配符、例外、目录级控制等),可精准排除日志、临时文件、编译产物等非业务代码文件,既避免这些文件干扰版本管理,又能确保真正需要跟踪的文件被正确纳入版本控制,是保障代码仓库整洁性的关键配置。
几乎所有的版本控制系统都以某种形式支持分支。
使用分支意味着你可以把你的工作从开发主线上分离开来进行重大的 bug 修改、开发新的功能,以免影响开发主线。
一个分支上的提交可以合并到另一个分支
命令: git merge 分支名称
规则:不能删除当前分支,仅可删除其他分支。
命令及说明:
git branch -d 分支名:删除分支时会进行各种检查,确保操作安全性。git branch -d 分支名:不做任何检查,强制删除分支。场景:当两个分支同时修改同一文件的同一行时,git 无法自动合并,需手动解决冲突。
步骤:
git add 文件名)。git commit -m "解决冲突")。说明:冲突解决是 git 分支协作中的关键环节,确保代码合并后逻辑正确,避免因冲突导致功能异常。

核心作用:
各分支说明:

常用的托管服务 [远程仓库]
前面我们已经知道了 git 中存在两种类型的仓库,即本地仓库和远程仓库。那么我们如何搭建 git 远程仓库呢?我们可以借助互联网上提供的一些代码托管服务来实现,其中比较常用的有 github、码云、gitlab 等。
本文档使用码云,现在码云上注册一个账号,点击右上角加号,选择新建仓库
注意,不要选择下面的三个选项


ssh-keygen -t rsa,然后不断回车即可生成。若已有公钥,此操作会自动覆盖。cat ~/.ssh/id_rsa.pub 可查看生成的公钥内容。ssh -t git@gitee.com,若返回相关成功提示信息,则说明配置成功。

此操作是先初始化本地库,然后与已创建的远程库进行对接。
命令:git remote add <远端名称> < 仓库路径 >
命令:git remote
命令:git push [-f] [–set-upstream] [远端名称 [本地分支名]:[远端分支名]]
如果远程分支名和本地分支名称相同,则可以只写本地分支
git push --set-upstream origin master
如果当前分支已经和远端分支关联,则可以省略分支名和远端名。

可通过 git branch -vv 命令查看本地分支与远程分支的关联情况。
命令格式为 git clone <仓库路径> [本地目录]。其中,本地目录可省略,省略时会自动生成与远程仓库同名的目录。
git fetch [remote name] [branch name]git pull [remote name] [branch name]git fetch + git merge操作。这两个操作的核心目的是将远程仓库的变更同步到本地,其中fetch更灵活(可先查看更新再决定是否合并),pull更便捷(一步完成抓取和合并),开发者可根据场景选择使用
git 合并冲突解决的说明内容,核心信息如下:
当 a、b 用户在同一时间段修改了同一个文件的同一行位置代码,a 先将修改推送到远程仓库,b 在拉取远程仓库更新时会发生合并冲突。
git pull(等同于fetch + merge)拉取远程更新,此时因代码冲突会触发合并冲突。git push推送到远程分支。远程分支本质上也是分支,因此合并冲突的产生和解决逻辑与本地分支间的合并冲突完全相同,都是因代码修改的重叠导致,需通过人工介入明确最终代码逻辑。
###################1 - 将本地仓库推送到远程仓库 完成 4.1、4.2、4.3、4.4 的操作 略 [git_test01] 添加远程仓库 git remote add origin git@gitee.com//.git [git_test01] 将 master 分支推送到远程仓库,并与远程仓库的 master 分支绑定关联关系 git push --set-upstream origin master ###################2 - 将远程仓库克隆到本地 将远程仓库克隆到本地 git_test02 目录下 git clone git@gitee.com//.git git_test02 [git_test02] 以精简的方式显示提交记录 git-log ###################3 - 将本地修改推送到远程仓库 [git_test01] 创建文件 file03.txt 略 [git_test01] 将修改加入暂存区并提交到仓库,提交记录内容为: add file03 git add .git commit -m 'add file03' [git_test01] 将 master 分支的修改推送到远程仓库 git push origin master ###################4 - 将远程仓库的修改更新到本地 [git_test02] 将远程仓库修改再拉取到本地 git pull 以精简的方式显示提交记录 git-log 查看文件变化 (目录下也出现了 file03.txt)
##############3 - 将本地修改推送到远程仓库 [git_test01] 创建文件 file03.txt 略 [git_test01] 将修改加入暂存区并提交到仓库,提交记录内容为: add file03 git add .git commit -m ‘add file03' [git_test01] 将 master 分支的修改推送到远程仓库 git push origin master ###################4 - 将远程仓库的修改更新到本地 [git_test02] 将远程仓库修改再拉取到本地 git pull 以精简的方式显示提交记录 git-log 查看文件变化 (目录下也出现了 file03.txt)
以上为个人经验,希望能给大家一个参考,也希望大家多多支持代码网。
您想发表意见!!点此发布评论
版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。
发表评论