今天完成的事情：git仓库的使用，详情见收获。
明天计划的事情：SVN又是什么？

遇到的问题：

Question_1：

git日志过多最后显示end无法输入命令。

Answer_1：

按一下q就可以直接退出。

Question_2:

error: The branch 'dev' is not fully merged.

Answer_2:

提示这一条分支线未合,合并提交后请重试。或者你确定这条线是不需要了,那就运行 git branch -D dev 的指令吧。

收获：Git作为全球最大同性交友网站程序员的公用仓库，交流基地，立志于It行业的人都应该有一个属于自己的GitHub！

今天已经把github的常用指令都试了个遍，了解了多分支开发策略，bug分支修复合并，标签管理，如何解决分支冲突，协同开发流程，以及如何更快的从GitHub上clone仓库。

初始化一个Git仓库，使用git init命令。

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

1. 使用命令git add      <file>，注意，可反复多次使用，添加多个文件；
2. 使用命令git commit -m      <message>，完成。

• 要随时掌握工作区的状态，使用git status命令。
• 如果git status告诉你有文件被修改过，用git      diff可以查看修改内容。
• HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git      reset --hard commit_id。
• 穿梭前，用git      log可以查看提交历史，以便确定要回退到哪个版本，主要用来查找commit_Id。
• 要重返未来，用git      reflog查看命令历史，以便确定要回到未来的哪个版本。
• 文件每次修改，如果不用git      add到暂存区，那就不会加入到commit中。
• 查看远程库信息，使用git remote -v。

工作区文件修改错误时：

1. 当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git      checkout -- file。
2. 当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git      reset HEAD <file>，就回到了1.，第二步按1.操作。
3. 已经提交了不合适的修改到版本库时，想要撤销本次提交，需要进行版本回退，不过前提是没有推送到远程库。

• 命令git      rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
• 添加github远程仓库需要添加ssh key，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH      Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。

如果在电脑里面没有找到这两个文件，说明这台机器之前没有添加过。按以下操作步骤添加：

1. 打开Shell（Windows下打开Git Bash），创建SSH Key：
2. $ ssh-keygen -t rsa -C      "youremail@example.com"
3. 邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可(无特殊需求,密码可以无需设置).
4. 登陆GitHub，打开“Account settings”，“SSH      Keys”页面：
5. 然后，点“Add SSH      Key”，填上任意Title(比如家、公司)，在Key文本框里粘贴id_rsa.pub文件的内容：

添加远程仓库:

1. 在本地的test仓库下运行命令关联远程GitHub仓库：
2. $ git remote add origin      git@github.com:(我的GitHub名称)/test.git
3. 添加后，远程库的名字就是origin，这是Git默认的叫法，

• 要关联一个远程库，使用命令git remote add origin      git@server-name:path/repo-name.git；
• 关联后，使用命令git push -u origin      master第一次推送master分支的所有内容；
• 此后，每次本地提交后，只要有必要，就可以使用命令git push      origin master推送最新修改；

远程仓库克隆:

• 从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆。

1. 首先，登陆GitHub，创建一个新的仓库，名字叫gittest：
2. 我们勾选Initialize this repository      with a README，这样GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件：
3. 现在，远程库已经准备好了，下一步是用命令git      clone克隆一个本地库：
4. git clone      git@github.com:(我的GitHub名称)/gittest.git

• GitHub给出的地址不止一个，还可以用https://github.com/(我的GitHub名称)/gittest.git这样的地址。实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。
• 使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

Git分支操作：

• 查看分支：git branch
• 创建分支：git branch <name>
• 切换分支：git checkout <name>
• 以上两条命令可以合并为 git checkout -b <name>  //表示创建分支<name>并切换
• 切换分支：git checkout      <name>或者git switch <name>  //不知道教程的版本问题还是我这边的安装问题，switch是不能使用的,提示没有这个命令
• 创建+切换分支：git checkout -b      <name>或者git switch -c <name>  //不知道教程的版本问题还是我这边的安装问题，switch是不能使用的,提示没有这个命令。
• 合并某分支到当前分支：git merge <name>
• 删除分支：git branch -d(-D) <name>   //教程中写的-d,但是有时候会删除不掉，提示要用大写的-D，强行删除。注意删除的时候不可以在这个分支上。

解决分支冲突：

• 当Git无法自动合并分支时，就必须首先解决冲突。解决冲突（解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容）后（Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容），再提交，合并完成。
• 用git log --graph命令可以看到分支合并图。

分支管理策略：

• 团队合作时应使用分支进行管理，Master分支应作为最终发布的版本，属于最稳定的。
• 平时可以在dev分支上工作。
• 如果有多人共同协同工作的话，需要再创建新的个人分支，然后定期汇总到dev分支上，测试通过后再汇总到Master上。

BUG分支：

• 修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

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

$ git checkout master     //切换到master分支上

$ git checkout -b issue-101   //生成bug分支

2. 修复bug然后提交:

$ git add README.md    //添加修改的文件
$ git commit -m "fix bug 101"    //提交修改

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

$ git checkout master       //切换回master分支

$ git merge --no-ff -m "merged bug fix 101"    //合并

$ git branch -D issue-101     //删除bug分支

• 当手头工作没有完成时，首先把工作现场git      stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

$ git stash    //将手头的工作暂时存储

$ git stash list    //查看存储空间当中的内容

$ git stash apply stash@{0}    //恢复特定序号的内容

$ git stash drop stash@{0}    //删除特定序号的内容

$ git stash pop    //以上两条指令也可以用这一条代替，在你的仓库里只有一条确定的待恢复的内容时。

• 在master分支上修复的bug，想要合并到当前dev分支，可以用git      cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

$ git checkout dev     //切换到dev分支上

$ git log     //查找之前提交的commit-id

$ git cherry-pick <commit-id>   //把之前修bug提交的内容，再提交到当前分支上

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

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>。

抓取、推送分支：

• 当从远程库clone时，默认情况下，只能看到本地的master分支。要在dev分支上开发，就必须创建远程origin的dev分支到本地。

$ git checkout -b dev origin/dev

• 修改完后把修改的本地dev分支，push到远程dev分支

$ git push origin dev

• 需要修改的时候先从远程PULL回来。

$ git branch --set-upstream-to=origin/dev dev    //绑定本地的dev分支，到远程origin的dev分支

$ git pull //拉取内容

• 如有提示冲突，需要将冲突解决后再提交详情见上面的 《解决分支冲突》。

标签管理：

$ git tag    //查看tag

$ git show <tagname>    //查看标签信息

• 标签主要是给人们对于日后的查找时候提供方便，commit-id实在是太反人类了，版本号v1.2之类的不香吗？

$ git branch     //查找分支

$ git checkout master    //跳转到master分支上

$ git tag v1.2    //给当前master分支的最新commit打上tag：v1.2

• 如果需要给特定commit打上tag的话：

$ git log --pretty=oneline --abbrev-commit    //找到历史提交的commit-Id

$ git tag v1.2 <commit-id>

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

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

• 如果标签打错了，也可以删除：

$ git tag -d v0.1    //删除v0.1的标签

• 如果要推送某个标签到远程，使用命令git push origin      <tagname>：

$ git push origin v1.0

$ git push origin --tags    //一次性推送全部尚未推送到远程的本地标签

• 命令git push origin      :refs/tags/<tagname>可以删除一个远程标签。

$ git tag -d v0.9    //先从本地删除

$ git push origin :refs/tags/v0.9    //再从PUSH指令当中删除远程的标签