这是我参与「第四届青训营」笔记创作活动的的第11天

一、远程仓库

1.添加远程库

第一步：首先创建SSH密钥,在用户主目录下面看有没有.ssh目录，然后再看里面是否有id_rsa(私钥)和id_rsa.pub(公钥)文件，如果没有，打开Git Bash(Shell)，创建SSH key:

$ ssh-keygen -t rsa -C "y1233@qq.com"

私钥不能泄露出去，公钥可以放心告诉别人

第二步，登录GitHub,点击右上角头像的settings,然后点击SSH and GPG keys,然后点击New SSH key新建一个ssh密钥,然后随便写TItle,最好用vscode打开id_rsa.pbu，复制里面的内容粘贴到key文本框中点击添加。
在本地创建一个git仓库，如果不会可以参考上一篇博客，然后在github上创建一个新的仓库，具体操作方法：点击右上角头像进入your repositories,然后点击New,然后填写仓库名称后，其它保持默认设置，直接创建仓库
第三步将本地的仓库与远程仓库相连，点击code,选择ssh并复制其地址在本地仓库下执行命令：

$ git remote add origin git@github.com:lgrdf/learngit.git

然后将本地库所有内容推送到远程库上：

$ git push -u origin master
Enumerating objects: 26, done.
Counting objects: 100% (26/26), done.
Delta compression using up to 8 threads
Compressing objects: 100% (20/20), done.
Writing objects: 100% (26/26), 2.05 KiB | 419.00 KiB/s, done.
Total 26 (delta 6), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (6/6), done.
To github.com:lgrdf/learngit.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

由于远程库是空的第一次推送master分支时加上-u参数，之后就可以省略这个参数直接把本地master分支的最新修改推送至Github

2.删除远程库

如果想删除远程仓库，可以用git remote rm <name>命令，使用前，建议先用git remote -v查看远程库信息：

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

其实这里的删除并不是物理上删除了远程库，而是接触了本地和远程的绑定关系，远程库本身没有任何改动，如果要真正删除远程库，在Github上手动删除，具体操作如下：

点击Settings,一直下滑到最下面：在这里插入图片描述

3.从远程库克隆

$ git clone git@github.com:lgrdf/js_practice.git
Cloning into 'js_practice'...
remote: Enumerating objects: 19, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 19 (delta 3), reused 15 (delta 2), pack-reused 0
Receiving objects: 100% (19/19), done.
Resolving deltas: 100% (3/3), done.

Git支持多种协议，默认使用ssh，但也可以使用https等其它协议，使用https除了速度慢以外，还有就是每次推送都需输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

二、分支管理

1.创建和合并分支

首先创建dev分支，然后切换到dev分支:

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

相当于：

$ git branch dev
$ git checkout dev

然后用git branch列出所有所有分支，当前分支前面会有个*号

$ git branch
* dev
  master

对之前写的readme.txt文件做个修改，然后提交：

$ git add readme.txt
$ git commit -m "branch test"

然后切换到master分支：

$ git checkout master

这时你再查看readme.txt文件，发现刚刚的修改不见了，原因是刚刚是提交在dev分支上，而master分支此刻的提交点并没有变：在这里插入图片描述

再把dev分支的工作成果合并到mater分支上：

$ git merge dev
Updating 9ba8d4e..beb9771
Fast-forward
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

git merge命令用于合并指定分支到当前分支，合并后，再查看readme.txt的内容发现和修改时一样

合并完成后，删除dev分支：

$ git branch -d dev
Deleted branch dev (was beb9771).

switch: 实际上，切换分支这个动作用switch更科学，因此可以用git switch命令来切换分支：

创建并切换到新的分支：

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

直接切换已有的master分支：

git switch master

小结：

查看分支：git branch

创建分支: git branch <name>

切换分支: git checkout <name> or git switch <name>

创建+切换分支: git checkout -b <name> or git switch -c <name>

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

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

2.解决冲突

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

这里就口述一下具体实验过程，正好复习一下分支操作：

第一步：建立一个新的分支feature1,并且切换到该分支：
第二步：修改readme.txt内容，并且提交
第三步：切换到master分支
第四步：再次修改readme.txt的内容，然后提交
第五步：合并feature1到master分支上最后结果为：==出现冲突==

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

原因是master分支和feature1分支各自都分别有新的提交，变成了：这种情况下，Git无法执行"快速合并",只能试图把各自修改合并起来，但这种就可能有冲突，所以需要手动修改后再提交。

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

$ git log --graph --pretty=oneline --abbrev-commit
*   da7fd9b (HEAD -> master) conflict fixed
|\
| * 00d9550 (feature1) And simple
* | 9f7d6ef & simple
|/
* beb9771 (dev) branch test
* 9ba8d4e (origin/master) remove test.txt
* 247b872 add test.txt
* 778d61c modified
* e3d21bd hh
* 112a2ce git tracks changes
* dece174 understand how stage works
* db23b16 append GPL
* 75a5168 add distributed
* c571380 wrote a readme file

3.分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

第一步：创建并切换到dev分支
第二步：修改readme.txt文件，并提交一个新的commit
第三步：切换到master分支
第四步：准备合并dev分支,--no-ff参数，表示禁用Fast forward

$ git merge --no-ff -m "merge with no-ff" dev
Already up to date.

合并后，可以用git log查看分支历史：

$ git log --graph --pretty=oneline --abbrev-commit
*   a41e277 (HEAD -> master) hh
|\
| * 9a0c250 (dev) add merge
* |   da7fd9b conflict fixed
|\ \
| * | 00d9550 And simple
| |/
* / 9f7d6ef & simple
|/
...

在实际开发中,master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能再上面干活，干活都在dev分支上，它是不稳定的，比如发布1.0版本时，再把dev分支合并到master上，再master分支发布1.0版本；然后每个人都在dev分支上干活，每个人都有自己的分支，时不时往dev分支合并就行。

团队合作分支看起来就像这样：在这里插入图片描述

4.Bug分支

软件开发中，bug就像家常便饭一样，在Git中，每个bug都可以通过一个新的临时分支来修复，修复后合并分支，然后将临时分支删除。

当你突然接收到一个bug任务，然后你就想创建一个分支来修复它，但是当前正在进行dev上进行的工作还没有提交：

$ 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

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        hello.txt

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

但是这时候工作只进行到一半，还没法提交，但是必须要在两个小时内修复该bug，幸好的是，Git提供了一个stash功能，可以把当前工作现场“存储”起来，等恢复现场后继续工作：

$ git stash
Saved working directory and index state WIP on master: a41e277 hh

现在用git status查看工作区就是干净的(除非有没有被Git管理的文件),然后就创建分支来修复bug

首先确定在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

$ git switch master
$ git switch -c issue-101

现在修复bug，然后再提交

$ git add readme.txt
$ git commit -m "fix bug"

修复完成后，切换到master分支，并完成合并，删除bug分支

$ git switch master
$ git merge --no-ff -m "merge bug fix 101" issue-101

修复完成后，切换到dev分支继续干活,然后用git status查看工作区是干净的，那刚才的工作现场去哪里了？用git stash list命令看一下：

$ git stash list
stash@{0}: WIP on master: a41e277 hh
stash@{1}: WIP on master: a41e277 hh

工作现场还在，Git把stash存在某个地方了，恢复有两种方法：

用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除。
用git stash pop,恢复的同时把stash内容也删了

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

$ git stash list

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

$ git stash apply stash@{0}
$ git stash drop

小结：

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

5. Feature分支

软件开发中，总有很多新的功能会添加进来，但是肯定不想把主分支给搞乱，所以每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，后删除该feature分支。

现在，你接到一个任务：开发代号为vulcan的新功能。

第一步：创建一个新的分支并切换到该分支：

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

然后提交功能文件

$ git add vulcan.py
$ git commit -m "feature vulcan"

切回dev，准备合并：

$ git switch dev

如果顺利的话，feature分支和bug分支是类似的，合并然后删除。但是现在接到上级命令，因为经费不足，新功能必须取消！虽然白干了，但是又必须销毁这份机密：

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

销毁失败，Git提醒了feature-vulcan分支还没有被合并，如果删除，将丢掉修改，如果要强制删除，需要使用大写的-D参数。现在我们强行删除：

$ git branch -D feature-vulvan
Deleted branch feature-vulvan (was 1fe4e22).

开发一个新的feature，最好新建一个分支：如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除

6.多人协作

之前说过，可以用git remote -v查看远程库信息：

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

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

推送分支

推送分支，就是把该分支上的所有本地提交推送到远程库。

推送时，要指定本地分支：

$ git push origin master

若要推送到其他分支，就改成：

$ git push origin dev

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

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

抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改 git pull

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

首先，可以试图用git push origin <branch-name>,推送自己的修改
如果推送失败，则因为远程分支比你的本地更新,需要先用git pull试图合并
如果合并有冲突，则需解决冲突，并在本地提交
如果没有冲突，再用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，如有冲突，要先处理冲突。

7. Rebase

从上一节可以看的，多人在同一个分支上协作时，很容易形成冲突。即使没有冲突，后push的同学也不得不先pull，在本地合并然后才能push成功，然后次数多了，分支就变成了这样：所以引入了“变基”，命令为git rebase即把本地未push的分叉提交历史整理成一条直线，使得我们查看历史提交的变化时更容易。

三、标签管理

标签是版本库的一个快照，通常发布一个版本时，现在版本库中打个标签，它跟某个commit绑在以前。

1.创建标签

首先切换到需要打标签的分支上，然后敲命令git tag <name>就可以打一个标签：

$ git tag v1.0

可以用命令git tag查看所有标签

$ git tag
v1.0

默认标签是打在最新提交的commit上的，有时候如果忘了打标签，方法是找到历史提交的commit id，然后打上就行了:

$ git log --pretty=oneline --abbrev-commit
7da4ee1 (HEAD -> master, tag: v1.0) fix bug101
a41e277 hh
9a0c250 add merge
da7fd9b conflict fixed
9f7d6ef & simple
00d9550 And simple
beb9771 branch test
...

例如给add merge打标签，就敲入命令：

$ git tag v0.9 9a0c250

注意：标签顺序不是按时间顺序列出，而是按字母排序的，可以用git show <tagname>查看标签信息：

$ git show v0.9
commit 9a0c25067800db9391fb4a047d79d07648c22f52 (tag: v0.9)
Author: lh <1390734594@qq.com>
Date:   Wed Aug 3 10:19:51 2022 +0800

    add merge

diff --git a/readme.txt b/readme.txt
index a941b5d..abb633f 100644
...

还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字:

$ git tag -a v0.1 -m "version 0.1 released" c571380

用git show tagname可以看到文字说明.

注意:标签总是和某个commit挂钩i有，如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。

2. 操作标签

删除本地标签(创建的标签只存储在本地，不会自动推送到远程)：

$ git tag -d v0.1
Deleted tag 'v0.1' (was 89e5017)

推送某个标签到远程：

$ git push origin v1.0
Enumerating objects: 23, done.
Counting objects: 100% (23/23), done.
Delta compression using up to 8 threads
Compressing objects: 100% (21/21), done.
Writing objects: 100% (21/21), 1.92 KiB | 656.00 KiB/s, done.
Total 21 (delta 6), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (6/6), done.
To github.com:lgrdf/learngit.git
 * [new tag]         v1.0 -> v1.0

或者一次性推送全部尚未推送到远程的本地标签：

$ git push origin --tags

删除远程标签

先从本地删除标签：

$ git tag -d v0.9

从远程删除

$ git push origin :refs/tags/v0.9

总结

具体的Git操作可以参考文档Git命令详解

Git的使用 | 青训营笔记