版本控制工具git

版本控制工具 git

数据库 ==> 有代码历史版本 ==> 仓库

每个文件都是不同的历史版本，以便恢复

集中式版本控制系统

例如：SVN

缺陷：

1.依赖于中心服务器

分布式的版本管理系统

只有程序员用 git

只有需要在同步代码的时候需要联网

程序员电脑里有代码的所有历史版本

左边的中央服务器只解决转发

如果两个人同时push，解决冲突问题？

仓库对应到计算机就是一个文件夹

1. 本地安装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
   

2. 在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)]