一、把本地代码提交到github上面
1、在 github 创建一个代码仓库（在github网站按照提示一步步操作即可）；
2、如果想以文件夹(eg: file)包含本地代码的方式上传到github上，则在和本地代码文件夹所在同一目录下右键点击“Git Bash Here”（如果是想直接上传文件，则双击进入文件夹，再右键点击“Git Bash Here”），然后在出现的命令行界面中执行“git init”初始化本地代码仓库；
3、添加远程仓库地址：git remote add origin 远程地址
4、git add file/*
5、git commit -m "comments"
6、git push origin master:master
按照上面几步操作下来通常会有如下错误产生，原因是远程仓库有本地仓库没有的修改。
要消除上面的错误，需要执行下面的命令：
git pull origin master --allow-unrelated-histories
建议创建好远程仓库后，先利用git clone方式将远程仓库内容克隆到本地，然后在这基础上进行提交，就不会有上面的错误了。
有时候，我们会在上一次提交中忘记提交了某个文件（a.c），以下面的例子说明。上一次提交完情况：
这时，如果想补提交一个a.c文件，同时又不产生新的log，可以利用下面的命令方法：git add a.c, git commit –amend –no-edit.
注意，虽然log内容没有增加，但是commit ID变化了。
二、从github上克隆指定版本到本地
1、创建一个文件夹，用于保存代码仓库
2、bash下执行：git clone git@github.com:xxx.git
3、如果要下载远程某个非master分支（假设为dev分支）代码到本地，则通常在本地也创建一个同名的分支，可以用下面的命令一次完成：
git checkout -b dev origin/dev
4、此时本地代码仓库的版本是最新的，如果想要回退到某个特定的版本号，可以执行git log，取commit后面一长串数字的前7位，如a0eb7f6，然后git checkout a0eb7f6，即将本地代码仓库的版本回退到了a0eb7f6版本。但是这样有一个问题，即进入了detached HEAD状态。
- detached HEAD state指的是什么
正常情况下，HEAD指向一个branch，而branch又指向一个commit。detached HEAD state指的是HEAD指针没有指向任何的branch，比如说它指向了一个commit。比如我在某次commit处设置了一个tagXXX，然后我git checkout tagXXX，这个时候，我的HEAD就会指向这个commit。
- detached HEAD state时能做什么
可以提交，这个时候，commit链就在git checkout这个commit的基础上展开，但是如果直接离开到一个branch上的话，这些commits就会被当成garbage，被git garbage collection routine所回收。
此时，可以通过git branch b1在这个detached HEAD上面建立个分支，让HEAD和b1建立关系。
利用git checkout b1切换到b1后，进行修改。然后此时如果直接将master（master分支要比b1分支新，实际上b1分支是基于master分支的前某个版本创建的）上的修改同步到b1上，会有问题，如下所示（也即下面第三部分中提到的情况一这种冲突类型）。
此时需要先将修改通过add和commit提交，然后merge，如下。
上面Auto-merge是成功的。这时如果git push origin b1:master，就能把修改提交到远程仓库。
再切换回master分支，则master分支已经落后于远程代码仓库了，可以通过git pull更新。
三、处理冲突与上传更新
如果在本地更改了代码，而别人又在远程代码仓库中提交了新的更新，而这部分更新有没有被及时更新到本地，此时是不能直接将本地的更改上传到远程代码仓库的。需要：
1、git fetch origin 将本地的远程跟踪分支更新到与远程代码仓库一致的最新状态。注意，这步操作不会影响到本地的工作区代码。
2、git diff origin/master 比较本地工作区代码和最新的远程代码仓库代码的差异，也即比较工作区代码和更新后的本地远程跟踪分支代码的差异。
3、将最新的远程代码仓库代码的修改合并进自己的本地工作区中，git merge origin/master，此时如果存在冲突，会报错。
上面这种报错方式表示压根儿没有进行merge，通常发生在本地的修改还没有commit的情况下（这里称之为情况一）。而下面这种先将本地的修改commit后再merge的方式，则会出现下面的错误，即git给你执行了Automatic Merge，但是出现了冲突，需要你处理冲突，然后再commit（这里称之为情况二）。
冲突文件的情况：
另外，具体是哪几个文件冲突了，可以通过git status命令来看，Unmerged paths下面列出的就是全部冲突文件。
4、处理冲突，再合并
如果是上面情况一的冲突，先将本地的修改commit后再merge，如果merge成功，如下图，则转到第5步。
如果merge失败，则转换成上面情况二。此时，手动修改Unmerged paths中的所有冲突文件，直到冲突解决。然后再add并commit，结束。
5、将本地代码修改上传到远程代码仓库
git push
四、撤销误删的文件
如果从远程仓库上面下载代码后不小心删掉了某个文件，以a.c为例，则可以利用下面的命令重新从远程代码库下载一份：
git checkout a.c
五、下载指定的tag版本
如下图所示，想要克隆1.9.4版本的代码。
可以利用命令：
git clone --branch 1.9.4 git@github.com:RoundBridge/jsoncpp.git
注意：这样克隆后，会进入detached HEAD状态。如果只是利用tag下面的代码编译出来的库，而不是开发代码，那么进入了detached HEAD状态也没关系。否则，可以参考文章前面的介绍进行相应处理。
