版本控制工具 git
数据库 ==> 有代码历史版本 ==> 仓库
每个文件都是不同的历史版本,以便恢复
集中式版本控制系统
例如:SVN
缺陷:
1.依赖于中心服务器
分布式的版本管理系统
只有程序员用 git
只有需要在同步代码的时候需要联网
程序员电脑里有代码的所有历史版本
左边的中央服务器只解决转发
如果两个人同时push,解决冲突问题?
仓库对应到计算机就是一个文件夹
-
本地安装git
在ubuntu上安装git
sudo apt install git
设置用户名
git config --global user.name "xxx"
设置email
git config --global user.email xxx.@xxx.com
默认编辑器改为vim
git config --global core.editor vim
-
在gitee网站上建一个仓库
克隆仓库
配置密钥
cat ~/.ssh/id_rsa.pub
若没有,就用 ssh-keygen 生成公钥
将密钥内容拷贝到个人账号(不是仓库的)中的SSH公钥中
将仓库克隆到本地
.git/ 存放所有历史版本
剩下的是当前的版本
做完克隆后是两个仓库
本地
查看仓库状态
接下来的所有命令,都必须要在仓库内执行
git status
.git/为历史文件
其他为工作树(当前工作区)
untracked 未被追踪的
任意 .o文件 .exe文件 测试文件必须一直处于untracked状态,不要被历史记录追踪到
增加追踪 git add
git add xxx.x
只添加单个文件,不要添加文件夹(不然删除的时候可能会比较麻烦)
清理暂存区 git restore
根据提示输入命令,不同版本可能不同
git restore
根据提示清理暂存区(使用的命令可能不同)
提交记录,只会提交暂存区的(记录不准修改) git commit
git commit -m "xxxxxxxxxxxxxxxx"
根据文件内容判断文件是否修改
列出所有历史记录 git log --oneline --graph --all
git log --oneline --graph --all
这个版本所有文件加在一起算的sha1哈希值
版本靠哈希值区分,每提交一个版本算一次哈希值
b57853b ===> cc30b33
创建文件 ==> 增加追踪 ==> 提交记录 ==> 所有文件都已被追踪
修改main.c
修改后的文件处于修改状态(modified)
恢复修改,回到上个版本的内容 git restore
git restore main.c
可以用git add将modified状态修改为staged,再git commit将main.c的修改永远留在历史版本中
流程图
分支
执行后续的所有命令,必须先 git status,以确保工作树干净。
分支:指向某个版本的指针,内容包含它指向的分支和历史版本。
特殊的指针变量 HEAD(当前的分支)
当commit时,只有HEAD分支会往后走,其它的不变
用 git log --oneline --graph --all 查看
新建分支 git branch
git branch b1
gir branch b2
当 commit 时,只有HEAD分支会往后走,其它的不变
时光穿梭:git checkout
checkout 改变 head 的指向
git checkout b1
工作的流程:
时空倒流
1)git branch fix_bug
2)git checkout fix_bug
3)修复代码,提交了一个新的版本git add,git commit,在fix_buf上就有提交,
===> 若不要了,切回master,删除掉fix_bug(单机版分支,自己保留的不用告诉其他人)
注意:git删除分支时报的错误,删除分支时,当前分支不能停留在要删除的分支上,要切换到其他任意分支,再去删除目标分支
git branch -D fix_buf
===> 保留,合并分支merge
流程:
checkout 到 master
merge fix_buf
branch -D fix_buf
实际工作中一般都在 fix_buf 写代码
合并分支的第一种情况:快进情况 git merge
active 主动方 passive被动方,被动方处于主动方正下游,主动方一定要处于上游
git checkout active
git merge passive
复杂的分支合并
Y型结构,主动方merge 分支,在两个分支的公共下游创建一个新的提交,让主动方的指针移动到新的位置
git merge fix_bug
以master作为主动方merge fix_bug,产生一个新的提交,他既是master的下游也是fix_bug的下游
此时若checkout回fix_bug,master作为fix_bug的下游,在fix_bug中添加新文件,修改文件,再add,commit,merge回master,是一种合法的无冲突的merge操作(快进模式)
冲突
Y型分支:
a,b
修改同一个文件同一位置,
或者一个修改,一个删除
同时修改
恢复到git merge之前的状态
git merge --abort
若是非要merge,打开main.c
<<<<<<< HEAD 主动方版本的内容
>>>>>>> fix_bug 被动方版本的内容
修改main.c 保留想要的内容
然后再add,再commit,看日志文件:
冲突的解决方案:
1.找到冲突的文件
2.根据业务需求,修正文件 ===> 使用 git status
3.git add
4.git commit
一改一删
git rm test.c
git commit -m "rm test.c"
发现冲突时要多用git status命令,它会提示怎么做
远程仓库(联机版)
git remote -v 列出关联的远端仓库的信息
对于testMyGit,git@gitee.com:xu-tsao/my-git.git 即gitee网页上的就是他的远程仓库,名字是origin
三个仓库的master不同,但是是同名分支,同名分支支持push/fetch 推送/获取
git push origin master 前提:本地的master是origin/master的正下游
test2仓库:
git fetch origin master 相当于把上面分支的内容取下来拿到下面,origin/master是远程分支在本地仓库的引用
以master作为主动方,origin/master作为被动方,进行merge
git checkout master
git merge origin/master 注意merge要有/
test2中若想同步fix_bug分支,
首先要在网页上创建一个fix_bug同名分支
test1仓库:
git fetch origin fix_bug 这时仓库中就有一个远端的origin/fix_bug
git checkout fixbug
git merge origin/fixbug
git push origin fix_bug
另一边test2仓库:
git fetch origin fix_bug 这时仓库中就有一个远端的origin/fix_bug
git branch fix_bug 三个fix_bug是同名分支,就可以push/fetch
pull 相当于先fetch,再merge
git fetch origin master
git merge origin/master
======>
git pull origin master
h origin fix_bug 这时仓库中就有一个远端的origin/fix_bug
git checkout fixbug
git merge origin/fixbug
git push origin fix_bug
另一边test2仓库:
git fetch origin fix_bug 这时仓库中就有一个远端的origin/fix_bug
git branch fix_bug 三个fix_bug是同名分支,就可以push/fetch
pull 相当于先fetch,再merge
git fetch origin master
git merge origin/master
======>
git pull origin master
[外链图片转存中...(img-2dhLyI7Q-1724943011171)]