search

xiaochengzi6 / Blog

个人博客
GNU Lesser General Public License v2.1
0 stars 0 forks source link

git 学习笔记 #30

Open xiaochengzi6 opened 2 years ago

xiaochengzi6 commented 2 years ago

是通过学习廖雪峰的git后记录的笔记，方便个人查找和复习使用

ls dir 查看目录。ls -ah 查看隐藏目录

q 通常代表退出键

阅读注意：这里"file" 指的是添加文件名但不需要引号

git介绍

git 分为两个区域 ：工作区和版本库。

工作区域：工作区域是你代码编辑时保存的位置

版本库：缓存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。(master 分支是第一次安装就会自动创建的的分支，一般都在这个分支里来回操作====>新手)

第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

要是 在其他分支就会往其他分支内添加东西

git-stage

1 提交文件：

git add "file"

相当于是把文件修改存放入暂存区域，执行git commit 一次性把暂存区域的所有修改都放入一个分支内

git commit -m "修改的备注"

2 查看文件的是否提交和前后变动

git status

git diff "file"

3 查看文件每次修改了什么内容

git log
 git log --pretty=oneline

4 退回上一个版本

git reset --hard HEAD^

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交。上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

5 如果想回退之前的版本需要知道它的commit id

git reflog

6 退回上一个的版本

git reset --hard HEAD^

注意：当你用$ git reset --hard HEAD^回退到上一个版本时，再想恢复到原先的版，就必须找到文件的commit id。Git提供了一个命令git reflog用来记录你的每一次命令：

git reflog

7 撤销修改

git checkout -- "file"

命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

注意：如果这里没有保存进分支(保存进暂存区)的话，是可以这样操作的否则只能退回上一个版本

如果保存进入分支内(git commit之前)：

可以使用：get reset HEAD "flie"把暂存区的修改回退到工作区,然后在执行 git checkout -- "file"

假设你不但改错了东西，还从暂存区提交到了版本库 

git reset --hard HEAD^

8 删除文件

情况一：工作区文件删除，无其他操作

\1. rm test.txt

以下命令可恢复文件 前提文件被存入分支中

\1. git restore test.txt

情况二：工作区文件要删除，版本库文件也要删除

\1. rm test.txt

\2. git rm test.txt

\3. git commit -m "remove test.txt"

另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

$ git checkout -- "file"

版本库中的文件也被删除了，只能退回上一个版本了

git reset --hard HEAD^

注意：命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

创建分支

git branch命令会列出所有分支，当前分支前面会标一个*号

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

在分支上修改内容，提交后，返回主分支查看不到修改的内容，

合并分支

git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

git merge "分支名"

合并分支后只要不切换分支，就会呆在原先的分支内

且分支也一直存在。

删除分支

如果在分支时是无法删除分支的

git branch -d dev

建议使用：

git switch 创建分支

git switch -c "分支名"；创建并切换。

切换已有分支 ：

git switch '切换已有分支名'

分支操作总结：

分支操作小结

Git鼓励大量使用分支：

查看分支：git branch

创建分支：git branch <name>

切换分支：git checkout <name>或者git switch <name>

创建+切换分支：git checkout -b <name>或者git switch -c <name>

合并某分支到当前分支：git merge <name>

删除分支：git branch -d <name>

分支合并出现冲突

如果分支内容和主支产生冲突那么必须手动解决冲突后再提交

查看冲突的文件 ： git status

打开冲突文件内容

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，r

git log --graph 来查看分支图

用带参数的git log也可以看到分支的合并情况：

git log --graph --pretty=oneline --abbrev-commit

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

git merge --no-ff -m "merge with no-ff" 'file'

git log --graph 来查看分支图

Bug分支

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

git stash

现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

这个时候就可以去找到bug的分支然后去创建一个分支进行修复bug后提交后在到bug分支中合并

git merge --no-ff -m "分支描述" '
要合并的分支名'

在返回原来的分支 继续完成未完成的工作

git stash list

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了 再用git stash list查看，就看不到任何stash内容了

你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

$ git stash apply stash@{0}

小结

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

git cherry-pick 4c805e2
注意这里 4c805e2是那个bug的分支，每个分支的号码不一样需要自己去查看

开发一个新feature，最好新建一个分支；

如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除

git branch -D "file"

关联远地仓困：gitee;

首先要有一个本地仓困，也就是

git init

然后在gitee创建远程仓库，名字叫learngit

我这次选择关联的是gitee仓库，方便访问

git remote add origin https:

查看远程仓库名

git remote

添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

查看详细信息

git remote -v

把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。

由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令

git push -u origin main

从现在起，只要本地作了提交，就可以通过命令：

$ git push origin master

把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！

删除远程库

如果添加的时候地址写错了，或者就是想删除远程库，可以用git remote rm <name>命令。使用前，建议先用git remote -v查看远程库信息：

$ git remote -v
origin  git@github.com:michaelliao/learn-git.git (fetch)
origin  git@github.com:michaelliao/learn-git.git (push)

然后，根据名字删除，比如删除origin：

$ git remote rm origin

此处的“删除”其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库，需要登录到gitee，在后台页面找到删除按钮再删除。

$ git remote -v
origin  https://gitee.com/xiaochengzi6/learngit.git (fetch)
origin  https://gitee.com/xiaochengzi6/learngit.git (push)

上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

推送分支

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

$ git push origin main

如果要推送其他分支，比如dev，就改成：

$ git push origin dev

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

抓取分支

git clone git@gitee.com:xiaochengzi6/learngit.git

切换到相应的目录 （lerangit）

他要是想在dex分支开发就必须创建远程origin的dex分支到本地，于是他用这个命令创建本地dex分支：

git checkout -b dex origin/dex

详细：

$ git checkout -b dex origin/dex
Switched to a new branch 'dex'
Branch 'dex' set up to track remote branch 'dex' from 'origin'.

现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：

$ git add env.txt

$ git commit -m "add env"
[dev 7a5e5dd] add env
 1 file changed, 1 insertion(+)
 create mode 100644 env.txt

推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：

git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：

$ git branch --set-upstream-to=origin/dex dex
Branch 'dex' set up to track remote branch 'dex' from 'origin'.

再pull：

$ git pull

这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的[解决冲突](http://www.liaoxuefeng.com/wiki/896043488029600/900004111093344)完全一样。解决后，提交，再push：

git push origin dev

因此，多人协作的工作模式通常是这样：

  1. 首先，可以试图用git push origin <branch-name>推送自己的修改；
  2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
  3. 如果合并有冲突，则解决冲突，并在本地提交；
  4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

查看分支图

git log --graph --pretty=oneline --abbrev-commit

hexo部署码云后报错ERROR Deployer not found: git

解决办法：npm install --save hexo-deployer-git

xiaochengzi6 commented 1 year ago

修改历史 commit

  1. git rebase -i HEAD~number number 是commit 记录中要修改commit的倒数第几个
  2. 然后把要修改 commit 中的 pike 该 edit
  3. 其次使用 git commit --amend 修改文件
  4. 最后 git rebase --continue