Git远程仓库的连接与使用

1. Git远程仓库的连接

我们可以自己搭建一台运行Git的服务器，不过也可以使用现有的Git远程库，应用比较广泛的如下：
github
gitee

这里使用gitee中的ssh协议来在我们的仓库克隆halo

halo：开源博客系统，基于spring boot和vue

1.1. 使用SSH协议：

ssh基于非对称加密的免密登录原理

对称加密：密码本是一个

• MD5

非对称加密，秘钥是一对(公钥/私钥)

• rsa

1.2. 创建SSH Key

在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa 和 id_rsa.pub 这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Git Bash，创建SSH Key：

Administrator@MS-NFZEFOSAMOUJ MINGW64 /d/GitBash
$ ssh-keygen.exe -t rsa -C "2755469212@qq.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/Administrator/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /c/Users/Administrator/.ssh/id_rsa
Your public key has been saved in /c/Users/Administrator/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:DLZYN0ZXafTIwYz6EF3O5erA7763xGuKhw5I6A21kXE 2755469212@qq.com
The key's randomart image is:
+---[RSA 3072]----+
|      . E..B=..  |
|       =..o+=*   |
|      B +o .= o  |
|     * Ooo   .   |
|    + + Soo .    |
|   . + .  .+ .   |
|    . o .  .o o  |
|         ..o..o. |
|         .oo==o. |
+----[SHA256]-----+

Administrator@MS-NFZEFOSAMOUJ MINGW64 /d/GitBash
$ 

1.3. 添加公钥

进入gitee个人用户管理界面

1.4. 复制halo博客系统ssh的网址

1.5. 在本地仓库克隆halo

Administrator@MS-NFZEFOSAMOUJ MINGW64 /d/GitBash
$ git clong git@gitee.com:halo-dev/halo.git
Cloning into 'halo'...
remote: Enumerating objects: 75236, done.
remote: Counting objects: 100% (36460/36460), done.
remote: Compressing objects: 100% (15498/15498), done.
remote: Total 75236 (delta 21851), reused 27964 (delta 17015), pack-reused 38776
Receiving objects: 100% (75236/75236), 61.41 MiB | 1.13 MiB/s, done.
Resolving deltas: 100% (42368/42368), done.

完成克隆。

2. 分支管理

2.1. Git分支原理

每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。

截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即 master 分支。 HEAD 严格来说不是指向提交，而是指向 master ， master 才是指向提交的，所以， HEAD 指向的就是当前分支。

每次提交， master 分支都会向前移动一步，这样，随着你不断提交， master 分支的线也越来越长。
当我们创建新的分支，例如 dev 时，Git新建了一个指针叫 dev ，指向 master 相同的提交，再把HEAD 指向 dev ，就表示当前分支在 dev 上：

从现在开始，对工作区的修改和提交就是针对 dev 分支了，比如新提交一次后， dev 指针往前移动一步，而 master 指针不变：
我们在 dev 上的工作完成了，就可以把 dev 合并到 master 上，直接把 master 指向 dev 的当前提交：

此时，删除 dev 分支，把 dev 指针给删掉，删掉后，只剩下了一条 master 分支：

2.2. 实践练习

创建dev分支，然后切换到dev分支

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

#git checkout 命令加上 -b 参数表示创建并切换，相当于以下两条命令
$ git branch dev
$ git checkout dev
Switched to branch 'dev'

#查看当前分支
$ git branch
* dev
master

在分支dev下完成文件的添加以及提交工作

#创建并修改 readme.txt 
$ vim readme.txt
$ cat readme.txt
Creating a new branch is quick.

#添加并提交文件
$ git add readme.txt
$ git commit -m "branch test"
[dev b17d20e] branch test
1 file changed, 1 insertion(+)

切换到master分支

$ git checkout master
Switched to branch 'master'

切换回 master 分支后，再查看一个 readme.txt 文件，刚才添加的内容不见了！因为那个提交是在 dev 分支上，而 master 分支此刻的提交点并没有变：

把dev分支的工作成果合并到master分支上

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

删除 dev 分支

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

#查看分支
$ git branch
* master

2.3. 版本冲突

准备新的 feature1 分支

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

git branch feature1 #创建分支
git checkout feature1 #切换分支
git branch #查看分支

修改 readme.txt

$ vim readme.txt
$ cat readme.txt
Creating a new branch is quick AND simple.

在 feature1 分支上提交

$ git add readme.txt
$ git commit -m "AND simple"
[feature1 14096d0] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)

切换到 master 分支

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)

在master分支上修改readme.txt

$ vim readme.txt
$ cat readme.txt
Creating a new branch is quick & simple.

在 master 分支上提交

$ git add readme.txt
$ git commit -m "& simple"
[master 5dc6824] & simple
1 file changed, 1 insertion(+), 1 deletion(-)

现在， master 分支和 feature1 分支各自都分别有新的提交

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突

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

查看readme.txt

Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

修改readme.txt并提交

$ vim readme.txt
$ cat readme.txt
Creating a new branch is quick and simple.

$ git add readme.txt
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed

现在， master 分支和 feature1 分支变成了下图所示

查看分支的合并情况

$ git log --graph --pretty=oneline --abbrev-commit
* cf810e4 (HEAD -> master) conflict fixed
|\
| * 14096d0 (feature1) AND simple
* | 5dc6824 & simple
|/
* b17d20e branch test

删除 feature1 分支

$ git branch -d feature1
Deleted branch feature1 (was 14096d0).

3. 分支策略

3.1. 多分支管理

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

• master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
• 干活都在 dev 分支上，也就是说，dev 分支是不稳定的，到某个时候，比如1.0版
  本发布时，再把 dev 分支合并到 master 上，在 master 分支发布1.0版本；
• 每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

#创建本地dev分支
git checkout -b dev

#提交dev给服务器
git push origin dev

#创建bob的本地分支
git checkout -b bob

#创建env.txt
touch env.txt

#提交
git add .
git commit -m "add env bob"

#回到dev，合并bob分支
git checkout dev
git merge bob

#上传dev到远程
git push origin dev

#进入mickey目录
cd f:\mickey
git clone git@gitee.com:xxx/learngit.git

#注意，只下载master分支，其他分支不会被clone
git checkout -b dev
git branch --set-upstream-to=origin/dev dev
#等价于
git checkout -b dev origin/dev

#拉取dev分支
git pull origin dev

#创建mickey分支
git checkout -b mickey

#修改env.txt增加内容"mickey env"
vim env.txt

#提交
git add .
git commit -m "update env by mickey"

#合并到dev
git checkout dev
git merge mickey

#上传
git push origin dev

#拉取最新代码
git pull origin master
git pull origin dev
git checkout master
git merge dev

#上传
git push origin master

完成工作

3.2. fast forward模式

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

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

修改readme.txt文件，并提交一个新的commit

$ git add readme.txt
$ git commit -m "add merge"
[dev f52c633] add merge
1 file changed, 1 insertion(+)

切换回 master

$ git checkout master
Switched to branch 'master'

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

#以为--no-ff参数使得git merge生成了一个新的commit，因此添加注释
$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)

git log 查看分支历史

$ git log --graph --pretty=oneline --abbrev-commit
* e1e9c68 (HEAD -> master) merge with no-ff
|\
| * f52c633 (dev) add merge
|/
* cf810e4 conflict fixed

不使用 Fast forward 模式，merge后就像这样

相比与单纯的git merge合并命令，添加了–no-ff参数之后，合并操作不再是让master同步到dev的版本，而是为master进行了一次提交，因此master与dev不再处于同一版本下，而是各自处于不同的版本。

4. Bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
当我们接到一个修复一个代号101的bug的任务时，我们想创建一个分支 issue-101 来修复它，但是当前 dev 上进行的工作由于没有完成还不能提交，此时我们可以使用stash 功能，把当前工作现场“储藏”起来，等以后恢复现场后继续工作。

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

完成保存操作后，我们现在可以放心地创建分支来修复bug
要在 master 分支上修复，就从 master 创建临时分支

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git checkout -b issue-101
Switched to a new branch 'issue-101'

修复bug，需要把“Git is free software …”改为“Git is a free software …”，然后提交

$ git add readme.txt
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)

切换到 master 分支，并完成合并，最后删除 issue-101 分支

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
readme.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

接着回到 dev 分支继续完成工作

$ git checkout dev
Switched to branch 'dev'
$ git status
On branch dev
nothing to commit, working tree clean

用 git stash list 命令查看保存

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

恢复保存
一是用 git stash apply 恢复，但是恢复后，stash内容并不删除，你需要用 git stash drop 来删除；
另一种方式是用 git stash pop ，恢复的同时把stash内容也删了；

$ git stash pop
On branch dev
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: hello.py
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)

由于dev在master上创建，dev分支也拥有bug，因此我们可以把 4c805e2 fix bug 101 这个提交所做的修改“复制”到dev分支来进行bug在dev上的修复工作。

5. Feature分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
但由于意外，新功能必须取消！虽然白干了，但是这个包含机密资料的分支还是必须就地销毁。

$ 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'.

feature-vulcan 分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的 -D 参数。

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

6. Git标签管理

6.1. 创建标签

在Git中打标签非常简单，首先，切换到需要打标签的分支上

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

打一个新标签

$ git tag v1.0

#查看标签
$ git tag
v1.0

为以前的版本打标签

$ git log --pretty=oneline --abbrev-commit
12a631b (HEAD -> master, tag: v1.0, origin/master) merged bug fix 101
4c805e2 fix bug 101
e1e9c68 merge with no-ff
f52c633 add merge
cf810e4 conflict fixed
5dc6824 & simple
14096d0 AND simple
b17d20e branch test
d46f35e remove test.txt
b84166e add test.txt
519219b git tracks changes
e43a48b understand how stage works
1094adb append GPL
e475afc add distributed
eaadf4e wrote a readme file

#对 add merge 这次提交打标签，它对应的commit id是 f52c633
$ git tag v0.9 f52c633

用 git show 查看标签信息

$ git show v0.9
commit f52c63349bc3c1593499807e5c8e972b82c8f286 (tag: v0.9)
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 21:56:54 2018 +0800
add merge
diff --git a/readme.txt b/readme.txt

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

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

6.2. 操作标签

删除标签

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

推送某个标签到远程

$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
* [new tag] v1.0 -> v1.0

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

$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
* [new tag] v0.9 -> v0.9

删除远程标签

#先从本地删除
$ git tag -d v0.9
Deleted tag 'v0.9' (was f52c633)

#从远程删除
$ git push origin :refs/tags/v0.9
To github.com:michaelliao/learngit.git
- [deleted] v0.9

总结

• 命令 git push origin 可以推送一个本地标签；
• 命令 git push origin --tags 可以推送全部未推送过的本地标签；
• 命令 git tag -d 可以删除一个本地标签；
• 命令 git push origin :refs/tags/ 可以删除一个远程标签。

7. 自定义Git

7.1. git config自定义配置

让Git显示颜色，会让命令输出看起来更醒目

$ git config --global color.ui true

7.2. 忽略特殊文件

有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们,这时我们可以在Git工作区的根目录下创建一个特殊的 .gitignore 文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。
不需要从头写 .gitignore 文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore
忽略文件的原则是：

1. 忽略操作系统自动生成的文件，比如缩略图等；
2. 忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那
   自动生成的文件就没必要放进版本库，比如Java编译产生的 .class 文件；
3. 忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。

有些时候，你想添加一个文件到Git，但发现添加不了，原因是这个文件被 .gitignore 忽略了,可以用 -f 强制添加到Git

$ git add -f App.class

用 gitcheck-ignore 命令检查 .gitignore

$ git check-ignore -v App.class
.gitignore:3:*.class App.class

7.3. 配置别名

将status设置简写为st

$ git config --global alias.st status