Git 实战

1.1 git的一个最初流程

想要让git对一个目录进行版本控制的步骤：

  • 进入要管理的文件夹，即工作区
  • 执行初始化命令，即右键git bush here
git init
  • 管理目录下的文件状态
git status
注：新增文件且没有添加的管理文件均为红色字体，其余为绿色
  • 管理指定文件(红色->绿色)，即把文件从工作区提交到暂存区
git add file_name
or
git add .
  • 个人信息配置，一次即可
git config --global user......
  • 生成版本，即一个新的版本，即将暂存区的文件放入版本库
git commit -m '描述信息'
  • 此时你在查看状态，那些文件都已经不见了，因为已经生成了版本
  • 然后添加远端地址，即仓库地址，上传到gitee或者github
git remote add origin gitee_address
  • 将你的代码推到你git里面的远端地址
git push -u origin master
  • 附上3大区域的图

1.2 git回滚

比如你有很多的版本，版本顺序如下：

  • 欧美
  • 日韩
  • 亚洲
  • 短视频
  • 约饭

但是，这时政府查出了你的约饭这个版本有问题，要下架，我们的解决办法是回滚到上一个版本

  • 欧美
  • 日韩
  • 亚洲
  • 短视频
  • 约饭

那么我们要怎么执行git命令呢

git log ----->目的是为了查看生成的版本号
git reset --hard 版本号

但是这时政府又说约饭功能可以重新上线了，那我们希望再一次回滚到原来的版本，即

  • 欧美
  • 日韩
  • 亚洲
  • 短视频
  • 约饭

那么需要执行一下命令

git log
你会发现，约饭的那个版本号没有了，之前回滚后，他的版本号就删除了

所以要变一下
git reflog  ------>这个跟git log的区别是，relog是记录修改版本的版本号，跟log的版本号不一样
git reset --hard 版本号

1.3 git的branch

graph LR
A[C1]-->B(C2)-->C[C3]
C-->|bug_repair| D[C5]
C-->|新的功能| E[C4]
D-->|分支修改完后要合并到master,此时,C3已经不是之前那个C3了| FF(C3新)
E-->|新功能完善了| F(C6)
FF-->F(C6)
F-->|合并成C6时会有冲突,所以要根据提示,进入文档手动修改| G(c7)

以上的流程图说明了分支的作用，其中方框表示分支，圆框表示master。

那么继续我们上面的版本，即C3。当碰到以下情况我们需要用到分支：

  • 我们想开发新的功能，一个叫商城的新功能
  • 当新功能开发到50%时，发现C3的源代码是错的，所以需要修改

以上情况，我们就可以把新功能C4分到一个新的分支上，再给改bug建立一个新的分支，具体操作如下：

先看下有哪些分支，应该只有master
git branch

为C3创建一个新的分支,叫lris
git branch lris
git branch

跳到lris这个分支，即C4进行我们的新功能开发
注意：当前还没有生成C4，因为没有commit生成版本
git checkout lris

对C3版本的代码进行修改ing

修改结束
git status
git add .
git commit -m "C4"

到此我们生成了C4，即流程图C4

这时其实新功能我们只完成了50%，这时发现C3代码有bug
我们为修改bug再创建一个分支，叫repair
git checkout master
git branch repair
git branch
git checkout repair

至此我们进入了repair这个分支，准备开始对C3的bug修复

对C3代码修复中，修复完后
git status
git add .
git commit -m "C5"

到此我们已经生成了C5，但是我们跑代码是跑master，所以需要将分支合并到master主分支上。
git branch
git checkout master
git merge repair
git branch -d bug
git branch

git checkout lris
然后继续开发新功能，对C4进行完善,变成了C6
git status
git add .
git commit -m "C6"

然后这个lris分支完成了也要和master合并，如下操作
git checkout master
git merge lris
这里你会发现一个问题，会提示有矛盾：conflict(content)
原因是，我们在分支C4的时候，C3的bug还没有修改，当C4->C6的过程中，C3才改的，但是lris这个分支是在对原来C3的代码上进行修改，所以合并的时候会出现矛盾

矛盾是因为C4中C3的代码段和C3新的代码有冲突，所以得手动修改

改完后，生成新的版本C7
git status
git add .
git commit -m "C7"

Github 实战

graph LR
A(home)-->B(github)
C(firm)-->B(github)

2.1github的推送

  • 先去github创建仓库
  • 再进入终端，通过命令将代码push上去，我们以上面的项目为例，比如版本里就一个index.html
git init
git add .
git commit -m "准备推送到github"
git remote add origin 远程仓库地址
git push -u origin 分支
  • 因为家里push到了github，所以到公司新电脑上就可以直接clone下来
1、克隆远程仓库代码（只要clone一次就行了）
    git clone 远程仓库地址
2、切换分支
    git checkout 分支
  • 到家了，要把公司新的代码拉下来，代码再dev分支上
git pull origin dev

git add .
git commit -m "xx"
git push -u origin dev
  • 到了公司，我们需要把dev写的代码合并到master，准备上线
git pull origin dev

git checkout master
git merge dev

若有冲突，就解决

git push origin master
graph LR
A(home)-->|新的功能|B(github)
C(firm)-->|约饭前完成的功能忘记推到github|B(github)
B(github)-->|第二天到了公司,pull代码,发现有冲突|C(firm)

2.2 约妹子吃饭代码忘记push到github

  • 男的跟女的约饭，结果快到点了，女的催促男的，结果导致男的忘记把新功能推送至github
  • 吃完饭后回到家，pull一拉发现，炸糊，但是不可能把firm写的代码再写一遍，索性就在写一些新代码
  • 第二天到公司，再次pull了home写的代码，发现有冲突
在firm
对代码处理后
git add . 
git commit -m "v1"
然后忘记push

在home
新的代码写好了
git add .
git commit -m "v2"
git push origin master

第二天,在firm，把代码拉下来，就会无形中进行一次合并（v1和v2），如果合并的内容有冲突，就需要手动改
git pull origin master
提示conflict(content)
进入具体文件进行修改
注意：

git pull origin dev 由以下两个命令合起来

git fetch origin dev
+
git merge origin/dev ----->这个地方是有一个origin/

2.3 rebase的应用场景（一）

  • 今天老板给了你一个任务，让你一星期完成
  • 然后每天都会完成一点，具体如下图
graph LR
A(start)-->B(C1)-->C(C2)-->D(C3)-->E(finish)
  • 但是老板并不想看到你提交的这些细节，只想看最终结果，也就是git log不要有C1,C2,C3，这是我们需要rebase让提交记录简洁
  • 首先看下没有rebase之前的logimage-20210115230619071
touch 1.sh 2.sh 3.sh 4.sh
然后提交4次，生成提交记录

我们想整合一些记录
1.git rebase -i 版本号  ---->从当前记录到版本号之间进行合并
2.git rebase -i HEAD~3 ---->从当前记录开始找最近的3条记录合并
出现下图界面

image-20210115225820608

  • 然后修改成如下图，其中s -->表示合并到上一个版本中

image-20210115230008510

  • 保存退出，出现下图

image-20210115230040819

  • 修改成如下图，出现一个提交信息，手动修改

image-20210115230341783

  • 也就是把流程图中C2，C3，finish 3个版本合并起来，合并到finish，然后git log只有两条消息了

image-20210115230527877

  • 这样实现了最简单的合并

注意：不要把已经push到github的记录和未push的记录合并，不是不可以，不好处理

2.4 rebase的应用场景（二）

  • 第二个应用就是把分支的记录合并到master主干上，让记录清晰，即将C3放到C4这条线上
graph LR
A(C1)-->B(C2)-->|master|C(C4)-->D(C5)
B(C2)-->|dev|E(C3)
E(C3)-->D(C5)
首先创建dev分支
git branch dev

然后进入dev，创建新的文件，然后生成C3版本
git checkout dev
touch dev.sh
git add .
git commit -m "C3"

然后切换到master生成C4版本
git checkout master
touch master.sh
git add .
git commit -m "C4"

然后merge形成C5
git merge dev

至此，两条分支形成

image-20210115234434419
image-20210115234523937

  • 通过rebase，可以变成以下流程图，让其变成只有master这个主干
graph LR
A(C1)-->B(C2)-->|master|E(C3)-->C(C4)-->D(C5)
  • 具体流程如下
先切换到dev，然后把master合并到dev，并且添加新文件，然后生成C3
git checkout dev
git merge master
touch dev1.sh
git add .
git commit -m "dev rebase to master"  -->C3

然后切换到master生成C4版本，即下图的master1
git checkout master
touch master1.sh
git add .
git commit -m "master1"   --->C4

最后切换回dev分支，即C3所在分支，通过rebase把dev分支“合并到”master主干上
git checkout dev
git rebase master

你可以切换回master查看记录，只有一条分支了，同时最开始的dev rebase to master这条记录没了，就简洁了很多
  • 显示到git上面就是,没有了分支

image-20210116000710256

2.5 rebase的应用场景（三）之再约妹子吃饭

  • 回顾一下之前提到了约妹子吃饭事件
  • 当可爱第二天去公司，想要pull昨天晚上在家写的代码，V1和V2两个版本合并时发生了冲突
  • 冲突是因为我们pull = fetch+merge，冲突发生在merge上，同时还会有分叉，我们的目的时不想要分叉，让其简洁，如场景（二）
  • 那这时，我们就用rebase来使其没有分支，如下图
graph TD
A(github)-->B(home)
A-->|之前用pull,现在我们用fetch+rebase,就不会有分叉,当然冲突还是会有|C(firm-v1)
  • git中操作如下
原先我们是
git pull origin dev

现在我们是
git fetch progin dev
git rebase orgin/dev

注意：因为rebase里面包含merge的一个操作，所以可能会报错的，就是之前提过的conflict，所以需要手动修改

​ 改完后，使用git rebase --continue，因为conflict时git处于一个中断的状态。

具体看如下操作

  • 先切换到dev分支，然后对dev.sh进行修改，生成X1版本

image-20210116145821510

  • 再切换到master主干，同样的对dev.sh进行修改，为了使其产生冲突，然后生成版本X2

image-20210116150012017

  • 然后编辑出问题的dev.sh文件即可

image-20210116150628897

  • 我们在git log看下是否有分支

image-20210116151016595

git的知识点补充

3.1 git的3大配置文件

  • 项目配置文件： 项目名/.git/config，仅在该项目，或项目文件夹生效
git config --local user.name 'xxx'
git config --local user.email 'xxxx'
  • 全局配置文件：~/.gitconfig，仅在该用户下生效，即home目录
git config --glocal user.name 'xxx'
git config --glocal user.email 'xxxx'
  • 系统配置文件： /etc/.gitconfig
git config --system user.name 'xxx'
git config --system user.email 'xxxx'

3.2 git的免密登录

  • SSH实现
1、生成公钥和私钥(默认放在 ~/.ssh目录下，id_rsa.pub公钥、id_rsa私钥)
    ssh-keygen -r rsa
2、拷贝公钥的内容，并设置到github中
3、在git本地中配置ssh地址
    git remote add origin git@xxxxx.com:xxxx/xxx.git  -->这个地址在github获取

4、以后使用
    git push origin master
  • git自动管理凭证，通过操作系统
这个是我们一般个人用户使用的

3.3 gitignore的作用

他的作用是可以帮你忽略到一些你不想push的文件，比如你的项目里有些数据库，你不想push到github，那么你可以使用gitignore去忽略掉他。

  • 他有点像正则

image-20210116204625522

  • 当然我们也可以忽略掉gitignore这个文件

image-20210116204729892

image-20210116204746079

  • 当然，你可能会说，一个项目那么大，忽略的文件那么多，怎么不能一个个动手写吧，这里可以去github搜索，有汇总详细参考该网站：https://github.com/github/gitignore

image-20210116204911673
image-20210116204959612

  • 一般有这么几种常见写法
*.h     --->正则里的通配符
!a.h    --->a.h这个文件不忽略
flie/   --->该文件夹下的均忽略

lionの金库