分布式版本控制工具git学习
git操作
-
git安装 卸载
sudo yum remove git sudo yum install git -
创建本地仓库
先创建一个目录 mkdir gitcode 进入目录下 git init # 执行该命令 在当前目录下就有一个 .git 目录==git --version== 查看git版本 -
git config [–global] user.name “your name”
-
git config [–global] user.email “your email”
可选项 --global 设置全局的
- git config -l 查看配置命令
- git config [–global] –unset user.name
- git config [–global] –unset user.email
设置是否使用了 --global 要和删除时一一对应
-
git add file 工作区修改提交到暂存区
-
git commit -m “注释” 暂存区修改提交的本地仓库
-
git log 查看 commit 记录
-
git log --pretty=oneline 查看commit精简版记录
-
tree .git 查看
index 就是我们的暂存区，add 后的内容都是添加到这⾥的
HEAD 就是我们的默认指向 master 分⽀的指针
objects 为 Git 的对象库，⾥⾯包含了创建的各种版本库对象及内容。当执⾏ git add 命令时，暂存区的⽬录树被更新，同时⼯作区修改（或新增）的⽂件内容被写⼊到对象库中的⼀个新的对象中，就位于==“.git/objects”== ⽬录下
23807c536969cd886c4fb624b997ca575756eed6 就是 commit id
-
git cat-file -p commit id 查看 对应commit 的修改
-
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7ti2MIMh-1689835553257)(C:\Users\VULCAN\AppData\Roaming\Typora\typora-user-images\image-20230624140715089.png)]
-
git status 查看工作区到暂存区的变化， 暂存区到本地仓库的变化
-
git diff file 查看 工作区 和暂存区 特定文件的差异
-
git diff HEAD – [file] 命令来查看版本库和⼯作区⽂件的区别
-
==git reset [–soft|–mixed|–hard] [HEAD]==版本回退
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nvMjCoro-1689835553258)(C:\Users\VULCAN\AppData\Roaming\Typora\typora-user-images\image-20230624141500542.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-k4vTWadv-1689835553258)(C:\Users\VULCAN\AppData\Roaming\Typora\typora-user-images\image-20230624141613453.png)]
回退完 我们又想回到最新的commit 中 ，应该再次使用get reset 加上对应的commit id
- git reflog 该命令⽤来记录本地的每⼀次命令 可以找到对应的commit id 回退到我们想去的版本
撤销操作 比如我们在工作区做了修改， 向回退到上一次的提交
情况一 本次修改 还没有git add
- git checkout – [file] 让⼯作区的⽂件回到最近⼀次 add 或 commit 时的状态
情况二 已经git add 了 还没有commit这时候 暂存区 和本地仓库就有差异了，我们可以git reset --mixed HEAD 就把本地仓库和暂存区回退到当前版本，其实就是回退了暂存区
- 先git reset --mixed HEAD [file] 再 git checkout – [file]
情况三 已经commit 了 直接使用
- git reset --hard HEAD^ 三大区都回退到上一个版本 前提是没有push
删除文件
- rm file 这是工作区的一次修改， git status 能查看到这次变化 ，我们需要 git add file 然后 git commit 才能同步到本地仓库
- 如果是删错了想要恢复 可以回顾前面撤销操作
- git rm file 这是方式二， 这样操作，变化已经同步到了暂存区 我们只需要 git commit 同步到本地仓库
分支管理
在版本回退⾥，你已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀
个分⽀。截⽌到⽬前，只有⼀条时间线，在Git⾥，这个分⽀叫主分⽀，即 master 分⽀。
再来理解⼀下HEAD，HEAD 严格来说不是指向提交，⽽是指向master，master才是指向提交的，所
以，HEAD 指向的就是当前分⽀
-
git branch 查看 当前所有分支
-
git branch dev 创建分支 dev 在当前分支创建一个新分支，就是以当前分支目前版本为起点开始
-
git checkout dev 切换到dev分支
-
git merge dev 如果要把 dev 分支合并到master分支，我们就要先切换到master分支，然后指向此命令
合并完成后, dev 分⽀对于我们来说就没⽤了， 那么dev分⽀就可以被删除掉，注意如果当前正处于某
分⽀下，就不能删除当前分⽀
- git branch -d dev 删除分支
- gti checkout -b dev 创建新分支dev 并切换到新分支上
合并冲突
当我们在master 分支上新建一个分支，并且两个分支都对同一个文件做了不同的修改，要将新分支合并到master 时 就会冲突
无法获知是要取master上的修改还是取新分支上的修改，形成完git merge dev1 是冲突报错，我们需要手动在冲突的文件中修改
文件总会把另个分支做的修改都列出，我们需要取我们想要的修改，删除另一份修改，然后再次 add commit
之后在 git merge 就会成功
- git log --graph --abbrev-commit graph 把提交记录以图表形式展示 abbrev-commit 提交id 简写
合并分支时 有fast 模型和no fast模型，前者合并无法区分修改是merge 分支进来的还是，当前分支commit 进来的，图表不显示
后者 是可以区分修改是merge进来的还是commit的
- git merge --no-ff -m “merge with no-ff” dev2 合并操作禁用 fast 模式， 合并时就形成一次新的提交 要带上 -m
如果我们在新分支dev2 对一个文件做了修改并且已经add +commit 了 那么切换到master 查看相同文件，我们看不到dev2上所做的修改
如果我们做了修改还没有commit 当切换到master 查看相同文件，我们是可以看到在dev2上做的修改。使用git stash 可以使还没有commitd的修改同样在master 上不被看到
- git stash 将工作区已经被git管理起来的文件的修改存储起来，存储起来后，在当前分支，和master 分支都看不到修改了，这样，我们在dev分支做的修改还没commit，切换到master分支就不会看到这些修改，如果是新建的文件，并没有add 被git 管理起来， 这时 git stash 将显示没有东西可以保存的
场景 master 是主分支 用来执行线上环境，dev2是我们的开发分支，当master上发现了bug 时 ，我们已经在dev2上开发修改了一下内容，还没有提交，此时在master 上是可以看到dev2作的修改，我们要在dev2下执行 git stash 然后切回到master 下新建 bug_fix 分支，在该分支下修复bug 然后合并到master
在bug_fix 修复完bug commit 后 回到master 分支 使用no fast 模型合并bug_fix分支，然后切换会的的dev2分支继续开发
- git stash pop 和git stash 对应， 我们先把修改存储起来，暂时停止了开发 到bug_fix 修复bug 去了，完成后我们继续在的dev2下开发，现在把之前做的修改从存储的地方 拿回来 git stash pop 也即把内容放回原位同时把存储区，拿的东西删除了
- ⽤git stash apply 恢复，但是恢复后，stash内容并不删除，你需要⽤ git stash drop 来删除；
- git stash list 显示我们存储的东西
恢复开发后，我们还是在dev2能看到bug 但在master 下已经修复，不影响继续开发,开发完成后，我们需要合并到maser分支上
可以在master分支上直接合并 dev2 因为dev2 做了commit 同时master 也做了commit 合并时相同文件内容不同又冲突需要解决冲突，再次合并，
更好的方式使 先在dev2上合并master 并解决冲突，然后再回到master 上合并dev2
- git branch -D 强制删除 我们开一个分支，开发完commit 然后合并到其他分支，这个分支的使命就完成了，我们使用 git branch -d 删除，如果 我们还没有合并 就在其他分支要删除此分支，就会失败，需要用-D
分布式版本控制系统
建立远程仓库
- git clone url 把远程仓库克隆报本地
注意不能在一个已经有.git文件的目录下克隆 即不能在任意一个本地仓库下指向该命令
克隆完成后就会出现一个以仓库名为名的目录
- git remote 显示远程仓库名 默认 origin 参数 -v 显示详细信息
在一般情况下，当我们通过git clone命令克隆一个远程仓库时，通常只能对该仓库进行读取操作，而不能进行推送操作。但是，在以下情况下，我们可以在git clone远程仓库后拥有推送权限：
- 当我们对远程仓库有写权限，例如有管理员或合作者权限，或是在自己的个人账户下创建了该仓库。这时候，我们可以使用git clone命令来克隆该仓库，并在本地对其进行修改并推送到远程仓库。
- 当我们在克隆远程仓库的时候，使用了SSH协议进行克隆，并且添加了SSH公钥到对应的仓库中。这种情况下，我们也可以在本地对仓库进行修改并推送到远程仓库。
使用ssh 来克隆远程仓库
如果没有在我们本地目录下配置公钥 那么克隆就会失败
1.第⼀步：创建SSH Key。在⽤⼾主⽬录下，看看有没有.ssh⽬录，如果有，再看看这个⽬录下有没有id_rsa 和 id_rsa.pub 这两个⽂件，如果已经有了，可直接跳到下⼀步。如果没有，需要执行ssh-keygen -t rsa -C “[email protected]” 邮箱要与远程仓库邮箱一致 ，一路确认直到执行完该指令
2.把生成在id_rsa.pub文件中的内容完整的设置到远程仓库中添加公钥下
git clone git@XXXXXXXXXX
这⾥由于我们使⽤的是 SSH 协议，是不⽤每⼀次推送都输⼊密码的，⽅便了我们的推送操
作。如果你使⽤的是 HTTPS 协议，有个⿇烦地⽅就是每次推送都必须输⼊⼝令
git push <远程主机名> <本地分⽀名>:<远程分⽀名>
# 如果本地分⽀名与远程分⽀名相同，则可以省略冒号：
git push <远程主机名> <本地分⽀名>
git pull <远程主机名> <远程分⽀名>:<本地分⽀名>
# 如果远程分⽀是与当前分⽀合并，则冒号后⾯的部分可以省略。
git pull <远程主机名> <远程分⽀名>
-
.gitignore 文件 ，设置不被git 管理追踪的文件类型 通常 是 *文件格式，如果我们把某一类忽略了，但又要其中一个文件可以使用如下
*.so !a.so #这里就是本来忽略.so 的 但我们要管理 a.so，就是把这单个排除在外
当gitignore 管理的文件非常多时，我们可以使用
-
git check-ignore -v a.so 那么git 就会告诉我们 a.so 被忽略是因为.gitignore 中设置了 *.so
-
git add -f file 强制推送一个文件，不管其是否被忽略
-
git config --global alias.别名 ‘替换的长指令’ 给命令取别名，快捷输入 如 git status 给 status 取别名 st --global 同样是全局的作用，可以不选
-
git tag XX 给最近一次commit 打上 XX 的标签
-
git tag 查看所有标签
-
git tag v0.9 edea4c0 给指定的一次commit打上 v0.9的标签
-
git show [tagname] 查看标签信息
Git 还提供可以创建带有说明的标签，⽤-a指定标签名，-m指定说明⽂字，格式为
- git tag -a [name] -m “XXX” [commit_id]
- git tag -d tagname 删除标签
- git push origin 标签推送到远程
- git push origin --tag 一次性推送所有标签
- 要删除远程标签，先git tag -d tagname 删除本地标签 然后 git push origin :tagname 修改更新到远程
git push origin :refs/tags/v1.0
- git branch -r 列出远程所有的分支
- git branch -a 列出本地和远程所有的分支
- git pull 不带选项 ，命令用于从远程仓库拉取最新的提交并合并到当前分支。它实际上相当于
git fetch和git merge两个命令的组合，可以更新远程的分支变化到本地
在进行git clone 时远程和本地就建立了连接，我们进行git push git pull 等操作不带选项也能完成就是因为有了连接，这就是链接的作用
git pull 更新了远程新建的dev ,我们在本地可以看到远程新建了dev ,但我们本地还是只有master分支，我们可以在本地新建分支dev 并和远程的dev 链接起来
- git checkout -b dev origin/dev 这里就是新建dev 切换到dev 并且dev 和远程dev 链接上
- git brach -vv 查看本地分支和远程分支的链接情况，可以看到本地master 链接上远程master dev-origin/dev
建立好链接 就可以直接使用 git push git pull
- 如果直接指向git checkout -b dev 则本地dev 没有与远程任何分支建立链接
- git branch --set-upstream-to=origin/dev dev 将本地的dev 与远程dev 建立链接
多人协作在同一分支下开发
当在两台不同服务器上建立本地仓库分别在本地dev上修改然后都合并到远程dev 如本地1 在test.txt 新增aaaa
本地2 在test.txt中新增bbbb,先push的可以顺利完成，后面push的就会把拒绝，因为git也不知道要保留谁的修改
按照提示，先pull远程的下来合并到后push的本地的dev上，我们就可以手动修改test.txt 消除冲突，再add commit push、
已经完成了多人协作在同一分支下修改并且同步到远程同一分支这里是dev的情况，我们要把远程dev合并的master分支
方式一 直接在远程远程操作 提交申请单 pull Requests
方式二 在本地先合并到master 然后本地master 合并到远程master
方式二 我们时刻要注意报错远程是最新的情况，我们先把远程dev pull 合并到本地dev ,保持本地dev 是最新的，然后在本地master pull远程master ，这样可以同步远程master的最新变化，然后本地dev合并本地master ，有冲突或bug 在本地dev解决，再在本地master 合并本地dev ,最后把本地master 推送上去，这样操作虽然繁琐，但规范， 然后就可以删除已经完成任务的dev了
多人协作在不同分支下开发
开发者1在本地先pull master 把最新的master 同步到本地，然后再本地新建一个分支 feature1 在该分支下开发一个function1文件，
这个分支目前没有与远程进行连接，远程没有相应的分支，开发完 add commit
指向push 会报错
- git push origin 本地新分支 这样就直接把featrue1 的开发同步到远程，远程就也新建了一个feature1
同理开发者2 也进行相同的操作，push到远程
git pull 要拉去分支中的内容就必须建立链接，但我们要拉去仓库的内容，比如远程有的分支，本地还没有显示，就可以直接git pull，更新一下
当开发者2 还没有开发完，生病了，需要我们接手远程feature2 的开发时 ，我本地是看不到feature2的，我们先git pull ,更新显示远程分支，然后新建本地分支feature2并链接到远程feature2 ,继续开发feature2，在push到远程，之后，如果开发者2 有回到岗位了，可以先把本地的feature2和远程feature2建立链接，之前push分支时并没有建立链接，然后git pull 只可以看到开发者1接替后做的工作， 就是同步更新feature2然后继续开发，完成后push
如果不建立链接，那么 git pull git push 后面都要显示指定是远程那个分支
开发完成后我们可以在远程把feature1 feature2 合并到master上，规范的做法是，现在本地进行，如本地开发者1 中，先把远程master 合并到本master ，然后把本地master合并到feature1 检测冲突，然后push feature1到远程更新远程feature1，这时再把远程feature1合并到远程master上，之后就是本地开发者2 同样的步骤，一 ,pull master 到本地master ，二，合并本地master到feature2 ，三，push feature2 ，之后在远程把feature2合并到master上
我们在远程删除了feature1 feature2 在本地 git branch -a 还是会显示远程仓库中这些已经删除的分支
-
git remote show origin 可以查看remote地址，远程分⽀，还有本地分⽀与之相
对应关系等信息
-
git remote prune origin 使用该命令后，就不会再显示远程已经删除的分支了