Bitbucket & Git 学习笔记
1、安装Git
细节我就不说了，注意事项如下：
安装完成后，还需要最后一步设置，在命令行输入：
$ git config --global user.name "Your Name"
$ git config --global user.email "[email protected]"
因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。你也许会担心，如果有人故意冒充别人怎么办？这个不必担心，首先我们相信大家都是善良无知的群众，其次，真的有冒充的也是有办法可查的。
注意git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址
2、选择或者新建一个文件夹，将你要上传的文件放到该文件夹下面，在该文件夹下右键运行Git，输入命令：
git init
这时会在你的文件夹下生成一个隐藏的文件夹.git，有关本地操作的一些命令和之后需要用到的一些命令整理如下：
git add //将文件的修改提交到暂存区或者叫版本库中去
git commit -m "有关这次提交的描述" //将文件的修改生成一个提交点，有唯一的ID与之对应。
git status //查看当前的文件状态，我建议大家修改一个文件看看状态，add后再看看状态，commit后再看看他们的状态。
git diff //查看被修改的文件与被修改之前的差异
git log //查看每次的提交信息
git log --pretty=oneline //查看提交信息，但是只显示一条
git reset --hard HEAD^/HEAD^^/HEAD~100 //返回到上一个/2个/100个版本
git reset --hard 版本号 //回到所选的版本当中去，版本号可以用git log查看，版本号写前几位就行了。
git reflog //用来记录你的每一次命令：
git log --graph --pretty=oneline --abbrev-commit //列出分支合并详情
git diff HEAD -- filename //命令可以查看工作区和版本库里面最新版本的区别
git checkout -- filename //就是把filename文件在工作区的修改全部撤销，这里有两种情况:一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。总之，就是让这个文件回到最近一次git commit或git add时的状态。
git rm test.txt //删除文件之后必须提交
git checkout --filename //其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
ssh-****** -t rsa -C "[email protected]" //创建一个私钥和公钥
git clone [email protected]:WechaoHe/homomorphic-encryption.git //远程仓库clone
git checkout -b dev //创建并切换到dev分支
git branch //查看分支
git branch dev //创建分支
git checkout dev //查看分支
git merge dev//合并制定分支到现在所在的分支，这次合并是“快进模式”，
git tag v0.9 版本号//为相应的提交版本打上标签
git tag -d v0.1 //删除相应的标签
也就是直接把master指向dev的当前提交，若产生冲突则先手动改动，再提交git log查看
git branch -d dev //删除分支
git remote -v //显示远程信息
git branch --set-upstream dev origin/dev //git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置本地dev和origin/dev的链接：
git push -u origin master //将仓库里面的提交推到远程
在本地操作熟悉之后呢，我们再来看看远程连接操作。
3、现在我假设你已经掌握怎么使用Git，并且已经安装好了，同时拥有自己的bitbucket账号。
到目前为止，我们已经掌握了如何在Git仓库里对一个文件进行时光穿梭，你再也不用担心文件备份或者丢失的问题了。
由于你的本地Git仓库和bitbucket仓库之间的传输是通过SSH加密的，所以，需要一点设置：
第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，我的目录为C:\Users\admin\.ssh，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，Windows下打开Git Bash，创建SSH Key：
$ ssh-****** -t rsa -C "[email protected]"
你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。
如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
第2步：登陆bitbucket，打开“Account settings”，“SSH Keys”页面：
然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容，bitbucket设置如下：
为什么bitbucket需要SSH Key呢？因为bitbucket需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，bitbucket只要知道了你的公钥，就可以确认只有你自己才能推送。
当然，bitbucket允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到bitbucket，就可以在每台电脑上往bitbucket推送了。
最后友情提示，在bitbucket上免费托管的Git仓库，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放进去。
如果你不想让别人看到Git库，你可以创建自己的私有库。
4、现在的情景是，你已经在本地创建了一个Git仓库后，又想在bitbucket创建一个Git仓库，并且让这两个仓库进行远程同步，这样，bitbucket上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。
首先，登陆bitbucket，然后，创建一个新的仓库。
建好的仓库如上图。
这时点击我已经有了一个存在的项目。会看到如下图：
第一个命令行是要你进入所在项目文件，你可以直接在相应文件下右键启动Git，
第二个命令是建立本机与bitbucket的关联，添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。
第三步，就可以把本地库的所有内容推送到远程库上。
第四步是推送标签，我们可以先不管。
把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
推送成功后，可以立刻在bitbucket页面中看到远程库的内容已经和本地一模一样
从现在起，只要本地作了提交，就可以通过命令：
$ git push origin master
把本地master分支的最新修改推送至bitbucket，现在，你就拥有了真正的分布式版本库！
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.
这个警告只会出现一次，后面的操作就不会有任何警告了。
如果你实在担心有人冒充GitHub服务器，输入yes前可以对照GitHub的RSA Key的指纹信息是否与SSH连接给出的一致。
有关同步协作时常见的问题：
推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
git push origin master
如果要推送其他分支，比如dev，就改成：
git push origin dev
抓取分支
多人协作时，大家都会往dev分支上推送各自的修改。
当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看
现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支。
git checkout -b dev origin/dev
现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：
git push origin dev
你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送：
git push origin dev
推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
$ git pull
git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：
$ git branch --set-upstream dev origin/dev
再pull：
$ git pull
这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push
因此，多人协作的工作模式通常是这样：
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 branch-name origin/branch-name。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。