版本控制工具git
版本控制工具 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)]