企业开发基础-8-分布式版本控制 Git
概述
Git是一个免费的、开源的分布式版本控制系统
集中式版本控制工具
CVS、SVN(Subversion)、VSS…… 集中化的版本控制系统诸如 CVS、SVN 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。多年以来,这已成为版本控制系统的标准做法。
优点
- 每个成员都可以在一定程度上看到项目中的其他成员正在做些什 么
- 管理员轻松掌控每个开发者的权限
- 且管理一个集中化的版本控制系统,要远比在各个客户端上维护本地数据库来得轻松容易
缺点
中央服务器的单点故障
分布式版本控制工具
Git、Mercurial、Bazaar、Darcs……
像 Git 这种分布式版本控制工具,是把代码仓库完整地镜像下来(本地库)。这样任何一处协同工作用的文件发生故障,事后都可以用其他客户端的本地仓库进行恢复。因为每个客户端的每一次文件提取操作,实际上都是一次对整个文件仓库的完整备份。
如何弥补集中式版本控制工具的缺点
- 服务器断网的情况下也可以进行开发(因为版本控制是在本地进行的)
- 每个客户端保存的也都是整个完整的项目(包含历史记录,更加安全)
常用命令
命令名称 | 作用 |
---|---|
git config —global user.name 用户名 | 设置用户签名 |
git config —global user.email 邮箱 | 设置用户签名 |
git init | 初始化本地库 |
git status | 查看本地库状态 |
git add 文件名 | 添加到暂存区 |
git commit -m “日志信息” 文件名 | 提交到本地库 |
git reflog | 查看历史记录 |
git reset —hard 版本号 | 版本穿梭 |
设置用户签名
基本语法:
1 | git config --global user.name 用户名设置 |
说明:
签名的作用是区分不同操作者身份。用户的签名信息在每一个版本的提交信息中能够看到,以此确认本次提交是谁做的。Git 首次安装必须设置一下用户签名,否则无法提交代码。
※ 注意:这里设置用户签名和将来登录 GitHub(或其他代码托管中心)的账号没有任何关系。
初始化本地库
基本语法
1 | git init |
查看本地库状态
基本语法
1 | git status |
首次查看(工作区无任何文件)
新增文件(hello.txt)
1 | vim hello.txt |
提示:'i'进入insert模式,'Esc'退出insert模式,'yy'复制整行,'p'粘贴
'Shift'+';'输入'wq'保存一下
再次查看(检测到未追踪的文件)
添加暂存区
将工作区的文件添加到暂存区
基本语法
1 | git add 文件名 |
查看状态(检测到暂存区有新文件)
1 | git status |
提交本地库
将暂存区的文件提交到本地库
基本语法
1 | git commit -m "日志信息" 文件名 |
查看状态(没有文件需要提交)
查看引用日志信息
1 | git reflog |
查看详细日志
1 | git log |
修改文件
修改文件
1 | vim hello.txt |
查看状态(检测到工作区有文件被修改)
1 | git status |
将修改的文件再次添加到暂存区
1 | git add hello.txt |
再次提交到本地库
1 | git commit -m "second commit" hello.txt |
历史版本
查看历史版本
1 | git relog 查看版本信息 |
版本穿梭
1 | git reset --hard 版本号 |
切换版本的底层逻辑
Git 切换版本,底层其实是移动的 HEAD 指针,具体原理如下图所示
分支操作
分支概念
在版本控制过程中,同时推进多个任务,为每个任务,就可以创建每个任务的单独分支。使用分支意味着程序员可以把自己的工作从开发主线上分离开来,开发自己分支的时候,不会影响主线分支的运行。(分支底层其实也是指针的引用)
分支的优点
- 同时并行推进多个功能开发,提高开发效率。
- 各个分支在开发过程中,如果某一个分支开发失败,不会对其他分支有任何影响。失败的分支删除重新开始即可。
分支操作
命令名称 | 作用 |
---|---|
git branch 分支名 | 创建分支 |
git branch -v | 查看分支 |
git checkout 分支名 | 切换分支 |
git merge 分支名 | 把指定的分支合并到当前分支上 |
查看分支
1 | git branch -v |
创建分支
1 | git branch 分支名 |
修改分支
1 | # 在hot-fix分支上修改 |
1 | # 查看状态 |
切换分支
1 | git checkout 分支名 |
合并分支
1 | git merge 分支名 |
产生冲突
冲突产生的表现:后面状态为MERGING
1 | dell@DESKTOP-CYAN MINGW64 /f/Git-Space/SH0720 (master|MERGING) |
冲突产生的原因:
合并分支时,两个分支在同一个文件的同一个位置有两套完全不同的修改。Git 无法替我们决定使用哪一个。必须人为决定新代码内容。
解决冲突
1.编辑有冲突的文件,删除特殊符号,决定要使用的内容
特殊符号:<<<<<<<
HEAD 当前分支的代码 =======
合并过来的代码 >>>>>>>
hot-fix
2.添加到暂存区
3.提交到本地仓库 (注意:此时使用 git commit
命令时不能带文件名)
合并分支只会修改合并的内容
创建分支和切换分支图解
master
、hot-fix
其实都是指向具体版本记录的指针。当前所在的分支,其实是由HEAD
决定的。所以创建分支的本质就是多创建一个指针。HEAD
如果指向master
,那么现在就在master
分支上。HEAD
如果执行hotfix
,那么我们现在就在hotfix
分支上。- 所以切换分支的本质就是移动
HEAD
指针。
GitHub 操作
命令名称 | 作用 |
---|---|
git remote -v | 查看当前所有远程地址别名 |
git remote add 别名 远程地址 | 起别名 |
git push 别名 分支 | 推送本地分支上的内容到远程仓库 |
git clone 远程地址 | 将远程仓库的内容克隆到本地 |
git pull 远程库地址别名 远程分支名 | 将远程仓库对于分支最新内容拉下来后与 当前本地分支直接合并 |
创建远程仓库别名
1 | git remote -v 查看当前所有远程地址别名 |
推送本地分支到远程仓库
1 | git push 别名 分支 |
PULL基本语法
1 | git pull 别名 分支 |
克隆远程仓库
clone 会做如下操作。1、拉取代码。2、初始化本地仓库。3、创建别名
1 | git clone 远程地址 |
IDEA 集成 Git
配置 IDEA 忽略文件
eclipse 特定文件
IDEA 特定文件
maven 工程的 target 目录
为什么忽略它们
与项目的实际功能无关,不参与服务器上部署运行。把它们忽略掉能够屏蔽 IDE 工具之间的差异
如何忽略
1.创建忽略规则文件 xxxx.ignore
为了便于让~/.gitconfig 文件 引用,建议也放在用户家目录下 git.ignore 文件模版内容如下:
1 | # Compiled class file |
2.在.gitconfig 文件中引用忽略配置文件(此文件在 Windows 的家目录中)
1 | [core] |
注意:这里要使用“正斜线(/)”,不要使用“反斜线(\)”
定位Git程序
初始化本地库
添加到暂存区
提交到本地仓库
切换版本
提交两次
在 IDEA 的左下角,点击 Version Control,然后点击 Log 查看版本
右键选择要切换的版本,然后在菜单里点击 Checkout Revision。
创建分支
选择 Git,在 Repository 里面,点击 Branches 按钮。
在弹出的 Git Branches 框里,点击 New Branch 按钮。
切换分支
合并分支(正常合并)
在 IDEA 窗口的右下角,将 hot-fix 分支合并到当前 master 分支
如果代码没有冲突,分支直接合并成功,分支合并成功以后,代码自动提交,无需手动 提交本地库。
解决冲突
如果 master 分支和 hot-fix 分支都修改了代码,在合并分支的时候就会发生冲突。 现在站在 master 分支上合并 hot-fix 分支,就会发生代码冲突。点击 Conflicts 框里的 Merge 按钮,进行手动合并代码。 手动合并完代码以后,点击右下角的 Apply 按钮。 代码冲突解决,自动提交本地仓库。
IDEA 集成 GitHub
设置 GitHub 账号
如果出现 401 等情况连接不上的,是因为网络原因,可以使用以下方式连接:
然后去 GitHub 账户上设置 token。
推送本地库到远程库
右键点击项目,可以将当前分支的内容 push 到 GitHub 的远程仓库中
注意:
push 是将本地库代码推送到远程库,如果本地库代码跟远程库代码版本不一致, push 的操作是会被拒绝的。也就是说,要想 push 成功,一定要保证本地库的版本要比远程库的版本高!
**因此在动手改本地代码之前,一定会先检查下远程库跟本地 代码的区别!如果本地的代码版本已经落后,切记要先 pull 拉取一下远程库的代码,将本地代码更新到最新以后,然后再修改,提交,推送!**拉取远程仓库到本地仓库
右键点击项目,可以将远程仓库的内容 pull 到本地仓库。
注意
pull 是拉取远端仓库代码到本地,如果远程库代码和本地库代码不一致,会自动合并,如果自动合并失败,还会涉及到手动解决冲突的问题