git连接gitee远程仓库及使用

1远程仓库

1.1使用远程库

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

• github
• gitee

1. 使用SSH协议：

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

• 对称加密：密码本是一个
  • MD5
• 非对称加密，秘钥是一对(公钥/私钥)
  • rsa

第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa 和 id_rsa.pub 这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：
$ ssh-keygen -t rsa -C “2075782631@qq.com”
#用户宿主目录下.ssh c:\Users\Administrator.ssh\

如果一切顺利的话，可以在用户主目录里找到 .ssh 目录，里面有 id_rsa 和 id_rsa.pub 两个文件，这两个就是SSH Key的秘钥对， id_rsa 是私钥，不能泄露出去， id_rsa.pub 是公钥，可以放心地告诉任何人。

第2步：登录gitee，打开账号设置，从左边目录中找到ssh公钥：

2. HTTS协议
当然不配置公钥也可以使用HTTS协议。

3. 克隆

使用https协议

git clone https://gitee.com/zhao-yuchen_wanqui/learngit.git

使用ssh协议

git clone git@gitee.com:zhao-yuchen_wanqui/learngit.git

1.2 添加远程库

首先，登陆Gitee，然后，在右上角找到“新建仓库”按钮，创建一个新的仓库：


注意不要选择初始化仓库和模板，要创建一个空的仓库

点击创建会出现如下内容：
简易的命令行入门教程:
Git 全局设置:

git config --global user.name "xxx"
git config --global user.email "13191810+wanqui@user.noreply.gitee.com"

创建 git 仓库:

mkdir learngitq1
cd learngitq1
git init 
touch README.md
git add README.md
git commit -m "first commit"
git remote add origin git@gitee.com:xxxwanqui/learngitq1.git
git push -u origin "master"

已有仓库?

cd existing_git_repo
git remote add origin git@gitee.com:xxxwanqui/learngitq1.git
git push -u origin "master"

下一步，就可以把本地库的所有内容推送到远程库上：

$ git push -u origin master
Counting objects: 20, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (20/20), 1.64 KiB | 560.00 KiB/s, done.
Total 20 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To github.com:michaelliao/learngit.git
* [new branch] master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

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

• git push 提交代码
• git pull 拉取代码

推送成功后，可以立刻在gitee页面中看到远程库的内容已经和本地一模一样：

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

git push origin master

1.3从远程库克隆

打开另一个窗口模拟其他小伙伴下载远程库

1.4 分支管理

1.4.1 创建与合并分支

首先创建分支，我们刚开始都是只有个master分支，现在我需要创建一个dev1分支，然后对dev1分支中的内容进行更改，然后再将dev1与master合并。

1. 当前这是我们的一条分支，也就是我们的主分支，master分支，我们的HEAD也是指向这我们的master。
   
2. 当我们创建一个dev1分支，并切换到dev1分支，查看log，发现现在HEAD指向了dev1。dev1和master处于同一个版本中。
   
   分支情况：
   
3. 这个时候我们对文件进行操作还有进行提交就是对dev1的操作了，当我们进行了一次新的提交：
   
   分支情况就变成这样了：
   
   假如我们在 dev 上的工作完成了，就可以把 dev 合并到 master 上。Git怎么合并呢？最简单的方法，就是直接把 master 指向 dev 的当前提交，就完成了合并

4. 我们切换回master，然后查看刚刚修改的文件，发现刚刚添加的东西消失不见了：
   

5. 要想把刚刚对dev1的修改出现再master中，我们就需要进行合并，达成下面的样子：
   

Administrator@zyc MINGW64 /s/study/03git/learngit (master)
$ git merge dev1
Updating 8c94e5c64..37e774f05
Fast-forward
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

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

合并完成后，就可以放心地删除 dev 分支了,删除后我们查看一下分支：

总结：
总结：

• git checkout
  • git checkout – file：把版本库的文件重置到工作区（撤销工作区的修改）
  • git checkout master：切换到master分支
  • git checkout -b dev：创建dev分支，并且切换到dev分支
• git branch
  • git branch：列表分支分支，有*当前的分支
  • git branch dev：创建dev分支，如果切换需要git checkout dev
  • git branch -d dev：删除分支
• git merge dev：合并分支

1.4.2 版本冲突

1. 我们准备好新的分支，然后进行新的开发：
   

# 这里我们使用到了一个新的命令git checkout -b feature1
# 等同于：
git branch feature1 #创建分支
git checkout feature1 #切换分支

2. 然后我们对readme.txt进行修改：
   
   这里我对readme.txt进行了修改，在最后新增加的一行new feature1 simple 内容，并进行提交
3. 切换到 master 分支：
   
   Git还会自动提示我们当前 master 分支比远程的 master 分支要超前1个提交。
4. 这时，我们将master中的readme.txt最后添加一句 new master simple并提交：
   
   这个时候我们可以想到现在的分支情况如下：
   

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

果然冲突了！Git告诉我们， readme.txt 文件存在冲突，必须手动解决冲突后再提交。 git
status 也可以告诉我们冲突的文件

然后我们查看readme.txt的内容

Git用 <<<<<<< ， ======= ， >>>>>>> 标记出不同分支的内容，我们修改如下后保存：
new master and feature1 simple
再次提交：
现在， master 分支和 feature1 分支变成了下图所示：

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

最后删除分支feature1，并查看log：

就会变成如下分支：

1.4.3 分支管理策略

1. fast forward模式

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

首先，仍然创建并切换 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 ：

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

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

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

可以看到，不使用 Fast forward 模式，merge后就像这样：

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

• 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

#注意，只下载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

合并到master分支

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

到这里我们今天的学习就结束了，当然，我在学习中还和周围的小伙伴进行了更深入的测试，我们让其中一个人（A）负责使用dev对master进行版本更新，另外两个人（B）（C）克隆下载A的远程仓库learngit，然后并创建分支dev与远程仓库dev连接，并创建自己姓名的分支，对分支进行修改，然后B先再dev分支使用pull拉取最新的版本，然后和自己姓名的分支进行合并，然后使用push进行提交，这时候A从远程仓库使用pull拉取B最新提交的dev和远程仓库的master，然后在master合并dev并完成提交，实现对远程仓库master的版本更新。

有条件的朋友可以拉着自己的小伙伴进行测试。

1.4.4 分支实战

1. Bug分支
   软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除

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

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

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

​

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

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

现在修复bug并提交：

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

太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到dev分支干活了！回到dev分支，查看status没有显示，然后使用git strah pop恢复：

当然还可以用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除，你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

$ git stash apply stash@{0}

在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。
​ 同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。
​ 为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：

$ git branch
* dev
  master
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

2. Feature分支
   软件开发中，总有无穷无尽的新的功能要不断添加进来

当我们接到任务，需要给程序添加一个新功能，我们需要创建一个新的分支进行编写：

5分钟后，开发完毕：

切回dev，准备合并：

一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。但是！就在此时，接到上级命令，因经费不足，新功能必须取消！

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

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

强行删除：