git基础入门（二）

1 远程仓库

  本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，设置如下：
第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

ssh-keygen -t rsa -C “youremail@example.com”

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

第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面

然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容：

点“Add Key”，你就应该看到已经添加的Key：

为什么GitHub需要SSH Key呢？
  因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。
  当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。

2 添加远程库

登陆GitHub，在右上角找到“New repository”按钮，创建一个新的仓库：
填写相关信息

在本地目录仓库中运行，比如：

git remote add origin git@github.com:123llc/repository_test.git

基本格式：it remote add origin git@github.com:GitHub账户名/仓库名.git
远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

把本地库的所有内容推送到远程库上

git push -u origin master

可能出现的错误：
1 不小心写错信息，在进行git remote add origin git@github.com:123llc/repository_test.git时，出现如下错误：

说明已经存在，删除即可，运行

git remote rm origin

2 推送出现错误，具体如下：

这个问题是因为github中的README.md文件不在本地代码目录中，解决方法：
先运行

git pull --rebase origin master

在push一次

如果在创建的时候没有勾选

也就不会出现上面这种情况

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

推送成功一下如下：

SSH警告
第一次使用Git的clone或者push命令连接GitHub时，会得到一个警告：

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

  因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。

  Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：

 Warning: Permanently added 'github.com' (RSA) to the list of known hosts.

克隆仓库
用命令git clone克隆一个本地库

git clone git@github.com:123llc/repository_test.git

注意：
  git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。

3 分支管理

创建与合并分支
每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。目前为止，只有一条时间线叫主分支，即master分支。HEAD指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

合并完分支后，可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，就剩下了一条master分支：

具体操作

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

git branch dev
git checkout dev

git branch命令会列出所有分支，当前分支前面会标一个*号。
然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：

Creating a new branch is quick.

然后提交：

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

换回master分支

此时在查看readme.txt文件发现新添加的文件已经不见了。

因为那个提交是在dev分支上，而master分支此刻的提交点并没有变，把dev分支的工作成果合并到master分支上，在查看。
git merge命令用于合并指定分支到当前分支。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

当然，也不是每次合并都能Fast-forward，合并完成后，就可以放心地删除dev分支了：

git branch -d dev

4 解决冲突

创建新分支

git checkout -b feature1

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

Creating a new branch is quick AND simple.
在feature1分支上提交：

提交

$ git add readme.txt

$ git commit -m "AND simple"

切换到master分支：

git checkout master

Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。

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

Creating a new branch is quick & simple.

提交

git add readme.txt 
git commit -m "& simple"

master分支和feature1分支各自都分别有新的提交，变成了这样：

此时快熟合并，出现冲突。

readme.txt文件存在冲突，必须手动解决冲突后再提交。

查看readme.txt文件内容

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：

Creating a new branch is quick and simple.

再提交：

git add readme.txt 
git commit -m "conflict fixed"

master分支和feature1分支变成了下图所示：

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

删除feature1分支：

git branch -d feature1

5 标签

标签是版本库的一个快照，指向某个commit的指针与分支不同的是，分支可以移动，标签不能移动。
创建标签

git tag 标签

git tag

查看所有标签
git tag 标签 commitid 可以指定某一个版本的标签号