Git版本控制

2022-09-03

本文为学习廖雪峰老师的git教程后的记录与总结，一些图片和解释是借鉴的，但代码都自己打过一遍，还记录了一些遇到的错误

一、创建版本库

版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来。

在某文件夹下git bash，输入git init命令即可

Lenovo@LAPTOP-S6KNM8Q9 MINGW64 /f/gitcode
$ git init
Initialized empty Git repository in F:/gitcode/.git/

这个时候该目录下会自动生成一个文件夹。注意

这个.git目录是隐藏的，要在查看中打开才能看见
如果你使用Windows系统，为了避免遇到各种莫名其妙的问题，请确保目录名（包括父目录）不包含中文。

在gitcode目录下写一个readme.txt,再添加到本地仓库（touch创建，add添加）:

$ touch readme.txt
$ git add readme.txt

用git commit将文件添加到仓库：

$ git commit -m "wrote a readme file"

-m后是对本次提交的声明

为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

总结：添加文件到Git仓库，分两步：

使用命令git add <file>，注意，可反复多次使用，添加多个文件；
使用命令git commit -m <message>，完成。
如果commit时忘了-m:

用git commit提交时没有加-m后缀,会进入vim,如何写入提交说明然后退出? 可以查看另一个博主的这篇文章： https://blog.csdn.net/qq_40415721/article/details/82120654

二、时光机穿梭

上文写了一个readme文件，现在修改它，再输入git status：

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交的修改。

虽然Git告诉我们readme.txt被修改了，但如果能看看具体修改了什么内容，自然是很好的。有时候已经记不清上次怎么修改的readme.txt，所以，需要用git diff这个命令看看：

$ git diff
diff --git a/readme.txt b/readme.txt
index e29912c..ca0fed9 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1 +1,2 @@
-This is for git learning.
\ No newline at end of file
+This is for git learning,hhh.
+Git is free software.
\ No newline at end of file

这里看到，我们添加了一句话。

知道了对readme.txt作了什么修改后，再把它提交到仓库就放心多了。

在执行第二步git commit之前，我们再运行git status看看当前仓库的状态：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   readme.txt

git status告诉我们，将要被提交的修改包括readme.txt，下一步，就可以放心地提交了：

$ git commit -m "add distributed"
[master e475afc] add distributed
 1 file changed, 1 insertion(+), 1 deletion(-)

提交后，再用git status命令：

$ git commit -m "add distributed"
[master e475afc] add distributed
 1 file changed, 1 insertion(+), 1 deletion(-)

三、版本回退

再在之前的基础上修改一次readme文件，这样前前后后一共三个版本

“wrote a readme”
“update1”
“update2”

在实际工作中，我们脑子里不可能记得一个几千行的文件每次都改了什么内容。版本控制系统肯定有某个命令可以告诉我们历史记录，在Git中，我们用git log命令查看：

$ git log
commit 81496a781599f152371a652e80e01a1b46b37d9d (HEAD -> master)
Author: Bob <884851491@qq.com>
Date:   Fri Aug 5 16:39:58 2022 +0800

    update2

commit 119f3db254f638bad77d65885e9b0bf256357328
Author: Bob <884851491@qq.com>
Date:   Fri Aug 5 15:14:30 2022 +0800

    update1

commit 05ed98b4f6679fe51ae333745836c989a71a473e
Author: Bob <884851491@qq.com>
Date:   Fri Aug 5 14:26:44 2022 +0800

    wrote a readme file

可以看到最近到最远非常清晰的三个版本

一大串类似1094adb...的是commit id（版本号），Git的commit id不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示，而且你看到的commit id和我的肯定不一样，以你自己的为准。为什么commit id需要用这么一大串数字表示呢？因为Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3……作为版本号，那肯定就冲突了。

我们现在可以将readme.txt回退到上一个版本：

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交。

上一个版本就是HEAD^
上上一个版本就是HEAD^^
往上100个版本HEAD~100。

现在，我们要把当前版本update2回退到上一个版本update1，就可以使用git reset命令：

$ git reset --hard HEAD^
HEAD is now at 119f3db update1

参数--hard HEAD^的作用后面学这时最新的那个版本update2已经看不到了！但是有办法可以回去，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个update2的commit id是81496a...，于是就可以指定回到未来的某个版本：

$ git reset --hard 81496a
HEAD is now at 81496a7 update2

这个时候看到update2又回来了，版本号不用全写，但尽量往后多写几位

想回退到某个版本，找不到某个版本的commit id怎么办？也有命令：

$ git reflog
81496a7 (HEAD -> master) HEAD@{0}: reset: moving to 81496a
119f3db HEAD@{1}: reset: moving to HEAD^
81496a7 (HEAD -> master) HEAD@{2}: commit: update2
119f3db HEAD@{3}: commit: update1
05ed98b HEAD@{4}: commit (initial): wrote a readme file

总结：

HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本

四、管理修改

创建文件touch <file> 查看某个文件cat <file>

注意：git管理的是修改，commit只会提交已经add到暂存区的文件。例：第一次修改 -> git add -> 第二次修改 -> git commit 如果按照这样的方式，第二次修改的内容不会被提交上去，因为没有被加入暂存区。此时用git status只能看到第一次修改后的内容。

怎样发现第二次修改有没有提交呢

提交后，用git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别，没有区别说明提交成功。那怎么提交第二次修改呢？你可以继续git add再git commit，也可以别着急提交第一次修改，先git add第二次修改，再git commit，就相当于把两次修改合并后一块提交了：第一次修改 -> git add -> 第二次修改 -> git add -> git commit

4.1 撤销修改

如果发现自己的文件内容修改后有不妥怎么办？

$ cat readme.txt
This is for git learning,hhh.
Git is free software distributed under the GPL.
My friend rhr is stupid.

这样可能会让朋友不满。如果你还没add，可以用git checkout -- readme.txt来使工作区的文件与版本库中的文件保持一致 注意命令的空格要打好不然会报错！

$ git checkout -- readme.txt

然后再看工作区的：

$ cat readme.txt
This is for git learning,hhh.
Git is free software distributed under the GPL.

打开文件发现里面的那句话也已经删掉了。

如果你已经add了–，状态变为待commit；

$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   readme.txt

这个时候相当于暂存区已经被修改，用命令git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区：

$ git reset HEAD readme.txt
Unstaged changes after reset:
M       readme.txt

这个时候再用前面的方法撤销工作区的修改即可

$ git checkout -- readme.txt

总结：

错误修改未add：git checkout -- <file> 注意空格
错误修改已add：git reset HEAD <file>可以把暂存区的修改撤销掉（unstage）再用checkout撤销工作区修改
已经commit了：$ git reset --hard commitid

4.2 删除文件

在Git中，删除也是一个修改操作，我们实战一下，先添加一个新文件test.txt到Git并且提交：

$ git add test.txt
$ git commit test.txt -m "test"
[master 696c517] test
 1 file changed, 1 insertion(+)
 create mode 100644 test.txt

一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了：

$ rm test.txt

这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了

$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    test.txt

no changes added to commit (use "git add" and/or "git commit -a")

这时 git status命令会告诉你工作区test.txt被deleted了，但没有commit

现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：

$ git rm test.txt
rm 'test.txt'
$ git commit -m "remove test.txt"
[master d8e685b] remove test.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 test.txt

现在，文件就从版本库中被删除了。

另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本，因为只对工作区进行了操作，暂存区和版本库都未被修改，所以用checkout就行

git checkout -- test.txt

五、关联远程库

现在的情景是，你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作。

在Github上创建一个Learngit仓库后，这个Learngit仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。

在本地仓库下关联远程库：

git remote add origin https://github.com/Bo-Vane/Learngit.git

注意：现在github的默认分支是main不是master，所以在关联后，分支要转到main

git branch -M main

然后上传文件和代码：

$ git push -u origin main

我遇到了这个错误：

fatal: unable to access 'https://github.com/Bo-Vane/Learngit.git/': SSL certificate problem: unable to get local issuer certificate

查资料发现这是因为服务器的SSL证书没有经过第三方机构认证。我们可以使用以下命令来解决这个问题：

git config --global http.sslVerify false

确实能解决问题，但会出现警告，所以存疑于此

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

$ git push origin main

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

5.*删除远程库

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

$ git remote -v
origin  https://github.com/Bo-Vane/Learngit.git (fetch)
origin  https://github.com/Bo-Vane/Learngit.git (push)

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

git remote rm origin

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

总结：

要关联一个远程库，使用命令git remote add origin https://github.com/Bo-Vane/库名.git
关联一个远程库时必须给远程库指定一个名字，origin是默认习惯命名
关联后，使用命令git branch -M main转到main
使用命令git push -u origin main第一次推送本地分支的所有内容
以后git push origin main推送最新修改

六、分支操作

附：该文章核心转载自廖雪峰老师的文章，有部分修改

6.1创建，合并分支

在版本回退里，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即main（master）分支。HEAD严格来说不是指向提交，而是指向main（master），main（master）才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候：在这里插入图片描述每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。（github现在是main）

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：在这里插入图片描述从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而main（master）指针不变：假如我们在dev上的工作完成了，就可以把dev合并到main（master）上。Git怎么合并呢？最简单的方法，就是直接把main（master）指向dev的当前提交，就完成了合并：在这里插入图片描述合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条main（master）分支：

下面是实战。

首先，我们创建dev分支，然后切换到dev分支：

$ git checkout -b dev
Switched to a new branch 'dev'

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

$ git branch dev
$ git checkout dev

然后，用git branch命令查看当前分支：

$ git branch
* dev
  main

会列出所有分支，当前分支前面会标一个*号。

然后，我们就可以在dev分支上正常提交，比如对readme.md做个修改，加上一行：

Creating a new branch is quick.

$ git add README.md
$ git commit README.md -m "branch test"
[dev 3a424c2] branch test
 1 file changed, 2 insertions(+)

现在，dev分支的工作完成，我们就可以切换回main分支。

$ git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.

切换回main分支后，再查看一个readme.md文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而main分支此刻的提交点并没有变：在这里插入图片描述现在，我们把dev分支的工作成果合并到main分支上：

$ git merge dev
Updating 3790728..3a424c2
Fast-forward
 README.md | 2 ++
 1 file changed, 2 insertions(+)

git merge命令用于合并指定分支到当前分支。合并后，再查看readme.md的内容，就可以看到，和dev分支的最新提交是完全一样的。注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把main（master）指向dev的当前提交，所以合并速度非常快。

合并完成后，就可以放心地删除dev分支了：

$ git branch -d dev
Deleted branch dev (was 3a424c2)

6.1.* 解决冲突

合并分支并非是一帆风顺的！

准备新的feature1分支，继续我们的新分支开发：

$ git switch -c feature1
Switched to a new branch 'feature1'

修改readme.md最后一行，改为：

Creating a new branch is quick AND simple.

在feature1分支上提交：

$ git add README.md
$ git commit README.md -m "AND simple"
[feature1 67d89d3] AND simple
 1 file changed, 1 insertion(+), 1 deletion(-)

切换到main分支：

$ git switch main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.

在main分支上把readme.md文件的最后一行改为：

Creating a new branch & quick.

提交：

$ git commit README.md -m "& simple"

现在，main分支和feature1分支各自都分别有新的提交，变成了这样：在这里插入图片描述这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

$ git merge feature1
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

Git告诉我们，readme.md文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件，我们查看文件

$ cat README.md
# gitskills
this is a repo for test cloning

<<<<<<< HEAD
Creating a new branch & quick.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

这个时候我们需要手动打开文件修改代码，删除那些特殊符号如<<<<<<< HEAD，把代码修改成我们想要的样子。

this is a repo for test cloning
Creating a new branch is quick and simple.

再提交：

$ git add README.md
$ git commit -m "conflict fixed"

注意：commit的时候不能加文件名！ 否则会报错：

$ git commit README.md -m "conflict fixed"
fatal: cannot do a partial commit during a merge.

现在，master（main）分支和feature1分支变成了下图所示：在这里插入图片描述使用git log --graph可以看到分支合并的图

$ git log --graph
*   commit 8c6e0b898e36aaf935568d30784231def2d07744 (HEAD -> main)
|\  Merge: 7b40424 67d89d3
| | Author: Bob <884851491@qq.com>
| | Date:   Sun Aug 7 10:51:51 2022 +0800
| |
| |     conflict fixed
| |
| * commit 67d89d396aa8c54ea70d13c45fc36cb370110371 (feature1)
| | Author: Bob <884851491@qq.com>
| | Date:   Sun Aug 7 09:59:42 2022 +0800
| |
| |     AND simple
| |
* | commit 7b404242daacc04f79112b7ad06bf886f0f7b10d
|/  Author: Bob <884851491@qq.com>
|   Date:   Sun Aug 7 10:08:05 2022 +0800
|
|       & simple
|
* commit 3a424c2566b6ef97866704d45c03110b52d1fb9f (origin/main, origin/HEAD)
| Author: Bob <884851491@qq.com>
| Date:   Sat Aug 6 21:51:35 2022 +0800
|

不过输入这个命令后不会自动退出，需要按q退出这个状态才能进行下一步！

6.2 switch命令切换分支

我们注意到切换分支使用git checkout ，而前面讲过的撤销修改则是git checkout -- ，同一个命令，有两种作用，确实有点令人迷惑。

实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支：

创建并切换到新的dev分支，可以使用：

git switch -c dev

直接切换到已有的main分支，可以使用：

$ git switch master

Switch意为切换更容易理解

总结：

Git鼓励大量使用分支
查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>或者git switch <name>，the latter is better
创建+切换分支：git checkout -b <name>或者git switch -c <name> the latter is better
合并某分支到当前分支：git merge <name>，合并之前先切换到主分支
删除分支：git branch -d <name>

6.3 管理分支策略

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

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

下面我们实战一下 –no-ff方式的git merge：

首先，仍然创建并切换dev分支：

$ git switch -c dev
Switched to a new branch 'dev'

修改readme文件并提交：

$ git commit README.md -m "add merge"
[dev 2323f6a] add merge
 1 file changed, 1 insertion(+)

然后切回main分支：

$ git switch main
Switched to branch 'main'

准备合并dev分支，请注意–no-ff参数，表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 README.md | 1 +
 1 file changed, 1 insertion(+)

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。合并后，我们用git log --graph看看分支历史：

$ git log --graph
*   commit c1983e567e13bba40b4c0cd69fd9dec31f16b5c3 (HEAD -> main)
|\  Merge: 8c6e0b8 2323f6a
| | Author: Bob <884851491@qq.com>
| | Date:   Sun Aug 7 11:34:52 2022 +0800
| |
| |     merge with no-ff
| |
| * commit 2323f6a6d007bfba4b684dd49050601b89995f5a (dev)
|/  Author: Bob <884851491@qq.com>
|   Date:   Sun Aug 7 11:22:08 2022 +0800
|
|       add merge
|

发现这种合并模式是这样的：在这里插入图片描述

小结

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，main分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：在这里插入图片描述简单来说，合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

6.4 Bug分支

有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

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

$ git status
On branch dev
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

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

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

$ git stash
Saved working directory and index state WIP on dev: 2323f6a add merge

现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug 首先确定要在哪个分支上修复bug，假定需要在main分支上修复，就从main创建临时分支：

$ git switch main
Switched to branch 'main'

$ git switch -c issue-101
Switched to a new branch 'issue-101'

现在修复bug，需要把“this is a repo for test cloning”改为“this is a repo for test bug”，然后提交：

$ git commit -m "fix bug 101"
[issue-101 6d8b9a2] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到main分支，并完成合并，最后删除issue-101分支：

$ git merge issue-101
Updating c1983e5..6d8b9a2
Fast-forward
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
$ git branch -d issue-101
Deleted branch issue-101 (was 6d8b9a2).

修复完成，就可以切换回dev干活了

但现在工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：

$ git stash list
stash@{0}: WIP on dev: 2323f6a add merge

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

用git stash pop，恢复的同时把stash内容也删了：

$ git stash pop
On branch dev
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (9583f38d6d96b00a31f7c0a29e46c8d20d4173cc)

恢复后再用git stash list查看，就看不到任何stash内容了。

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

$ git stash apply stash@{0}

在main分支上修复了bug后，我们要想一想，dev分支是早期从main分支分出来的，所以，这个bug其实在当前dev分支上也存在。这个时候重复一遍刚刚的操作会很麻烦。同样的bug，要在dev上修复，我们只需要把6d8b9a2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制6d8b9a2 fix bug 101这个提交所做的修改，并不是把整个main分支merge过来。

注意：fix bug 101前面的代码是刚刚修复bug提交时的代码

为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：

$ git cherry-pick 6d8b9a2
error: Your local changes to the following files would be overwritten by merge:
        README.md
Please commit your changes or stash them before you merge.
Aborting
fatal: cherry-pick failed

6.4 *遇到问题

这个时候我发现出现了问题，原因如其所说，我在本地对文件的修改还没有上传至远程库，导致远程库现在与本地库的文件不同，所以要先把修改提交或者放弃本地库修改 方法一：放弃本地修改内容，即这个修改我们原本不想要

1.还mei有git add 。直接checkout让工作区文件与新版本一致即可

git checkout .

2.已经add 但是还未git commit 用以下命令清除git add执行的代码命令，再使用checkout命令

git reset HEAD

方法二：上传本地分支代码也就是说这个修改是我们想要的，只是忘了提交，这篇文章案例中属于这种情况，所以我将本地修改提交：

$ git add README.md
$ git commit README.md -m "forget to commit local changes"
[dev e738d2b] forget to commit local changes
 1 file changed, 2 insertions(+)

提交代码后再切换分支或者其他命令就好了：

$ git cherry-pick 6d8b9a2
Auto-merging README.md
[dev 273a5c4] fix bug 101
 Date: Sun Aug 7 12:23:45 2022 +0800
 1 file changed, 1 insertion(+), 1 deletion(-)

总结：

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；
在main分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick 命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

6.5 功能分支

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。现在，你终于接到了一个新任务：开发代号为Vulcan的新功能

$ git switch -c feature-vulcan
Switched to a new branch 'feature-vulcan'

若干天后，开发完毕：

$ git commit vulcan.py -m "add feature vulcan"
[feature-vulcan 096d4e8] add feature vulcan
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 vulcan.py

切回dev准备合并：

一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。

但是！

就在此时，接到上级命令，因经费不足，新功能必须取消！

虽然白干了，但是这个包含机密资料的分支还是必须就地销毁：

但我中途发现一个问题，我在feature分支上新建的dev分支并切换到dev分支，删掉feature后，feature提交的add feature vulcan版本转移到了dev上

 (main)
$ git switch -c feature-vulcan
Switched to a new branch 'feature-vulcan'

(feature-vulcan)
$ touch vulcan.py

(feature-vulcan)
$ git add vulcan.py

(feature-vulcan)
$ git commit vulcan.py -m "add feature vulcan"
[feature-vulcan 096d4e8] add feature vulcan
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 vulcan.py

 (feature-vulcan)
$ git switch -c dev
Switched to a new branch 'dev'

(dev)
$ git branch -d feature-vulcan
Deleted branch feature-vulcan (was 096d4e8).

 (dev)
$ git log
commit 096d4e86c555f8787fbbf55ac48df423fff46b8f (HEAD -> dev)
Author: Bob <884851491@qq.com>
Date:   Sun Aug 7 14:56:32 2022 +0800

这说明feature作为“父分支”，在其上创建了“子分支”dev下删除feature这个“父分支”的结果是，dev会代替feature，HEAD指针原先指向feature，现在会指向dev 对此结果我做记录并存疑

但这也是我犯下的错误，正确操作应该是dev作为由main创建操作干活的主要分支，应该在dev下创建子分支来实现功能再换回dev进行合并，合并完删除此子分支。

在正确操作下：

$ git branch -d feature-vulcan
error: The branch 'feature-vulcan' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature-vulcan'.

销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。。（只要文件不为空，但feature中文件如果为空会删除成功）

$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 287773e).

进行强行删除。

七、多人协作

当你从远程仓库克隆时，实际上Git自动把本地的main分支和远程的main分支对应起来了，并且，远程仓库的默认名称是origin。

要查看远程库的信息，用git remote -v：

$ git remote -v
origin  https://github.com/Bo-Vane/gitskills.git (fetch)
origin  https://github.com/Bo-Vane/gitskills.git (push)

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

7.1 推送分支

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

$ git push origin 分支名

main分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

7.2抓取分支

现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆：

$ git clone https://github.com/Bo-Vane/gitskills.git
Cloning into 'gitskills'...
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 6 (delta 0), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (6/6), done.

当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的main（master）分支。不信可以用git branch命令看看：

$ git branch
* main

现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：

7.2* 遇到问题

$ git switch -c dev origin/dev
fatal: invalid reference: origin/dev

出现了错误，这是因为远程仓库还没有dev分支，我没有push push之后发现还是报错，那就必须先拉取：

$ git pull
remote: Enumerating objects: 28, done.
remote: Counting objects: 100% (28/28), done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 26 (delta 7), reused 26 (delta 7), pack-reused 0
Unpacking objects: 100% (26/26), 2.07 KiB | 15.00 KiB/s, done.
From https://github.com/Bo-Vane/gitskills
 * [new branch]      dev        -> origin/dev
Already up to date.

$  git switch -c dev origin/dev
Switched to a new branch 'dev'
Branch 'dev' set up to track remote branch 'dev' from 'origin'.

这样就成功了。

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

$ git add README.md
$ git commit README.md -m "my friend first commit"
[dev a13770f] my friend first commit
 1 file changed, 2 insertions(+)
$ git push origin dev

小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送：

$ git push origin dev
To https://github.com/Bo-Vane/gitskills.git
 ! [rejected]        dev -> dev (fetch first)
error: failed to push some refs to 'https://github.com/Bo-Vane/gitskills.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

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

$ git pull
这里省略一些代码
If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=origin/<branch> dev

根据提示，我们没有指定本地dev分支与远程origin/dev分支的链接，再根据提示，设置dev和origin/dev的链接：

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

再pull：

$ git pull
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

pull成功，但是自动合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：

$ git add README.md
$ git commit -m "my friend,conflict fixed"
[dev 939816f] my friend,conflict fixed

$ git push origin dev
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 476 bytes | 476.00 KiB/s, done.
Total 4 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/Bo-Vane/gitskills.git
   a13770f..939816f  dev -> dev

至此，冲突解决并push成功

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

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 remote -v；
本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。