如果一个文件被删除了，可以使用切换版本号进行恢复。恢复方法：
先确定需要恢复的文件要恢复成哪一个历史版本(commit)，假设那个版本号是： commit_id，那么
git checkout commit_id -- path_to_file
就可以恢复。
还有一个方法是：
你直接从本地把文件checkout出来就可以了，用不着从远程服务器上pull下来，因为，所以的历史版本你的本地都有的。
具体做法 git checkout file 同时恢复多个被删除的文件.
3.在本地仓库添加一个远程仓库,并将本地的master分支跟踪到远程分支
1 software@debian:~/yafeng$ git remote add origin ssh://software@172.16.0.30/~/yafeng/.git
2 software@debian:~/yafeng$ git push origin master
3 software@172.16.0.30's password:
4 Everything up-to-date
5 software@debian:~/yafeng$
命令注释:
第1行:在本地仓库添加一个远程仓库,当然ssh后面的地址是我们本地仓库的地址.
第2行:将本地master分支跟踪到远程分支,在git仓库建立之初就会有一个默认的master分支,当然你如果建立了其他分支,也可以用同样的方法去跟踪.
对于分支的事情,我们会在以后细细的讲述.
做到拉这一步了吗?我告诉你,你已经完成目的了哦,现在的git仓库已经是一个远程仓库了,
不相信吗?我们来测试一次阿:
4.测试
现在本机上看看:
1 software@debian:~/yafeng$ git remote show origin
2 software@172.16.0.30's password:
3 * remote origin
4 Fetch URL: ssh://software@172.16.0.30/~/yafeng/.git
5 Push URL: ssh://software@172.16.0.30/~/yafeng/.git
6 HEAD branch: master
7 Remote branch:
8 master tracked
9 Local ref configured for 'git push':
10 master pushes to master (up to date)
11 software@debian:~/yafeng$
代码注释:
第1行:显示远程信息
很多看见这还是会不以为然的,这又能说明什么呢?好,那就来点实际的:
在另一个机子上,远程clone
1 root@yafeng-VirtualBox:~# ls
2 bin gittest read_temp
3 root@yafeng-VirtualBox:~# git clone ssh://software@172.16.0.30/~/yafeng/.git
4 Cloning into yafeng...
5 software@172.16.0.30's password:
6 remote: Counting objects: 9, done.
7 remote: Compressing objects: 100% (3/3), done.
8 remote: Total 9 (delta 0), reused 0 (delta 0)
9 Receiving objects: 100% (9/9), done.
10 root@yafeng-VirtualBox:~# ls
11 bin gittest read_temp yafeng
12 root@yafeng-VirtualBox:~# cd yafeng/
13 root@yafeng-VirtualBox:~/yafeng# ls
14 file
15 root@yafeng-VirtualBox:~/yafeng#
代码注释:
第3行:就是远程clone仓库.很明显的对比可以知道多了yafeng目录,而这个yafeng目录里的内容和我们另外一台机子上的内容一样
至此,一个简单的git远程仓库就建好了,简单不,试试吧!!
http://www.cnblogs.com/xiaoya901109/archive/2012/08/03/2620664.html
git merge 用来做分支合并，将其他分支中的内容合并到当前分支中。比如分支结构如下：
master
/
C0 ---- C1 ---- C2 ---- C4
C3 ---- C5
issueFix
当前分支是master
$ git checkout master//切换到master分支
把issueFix中的内容Merge进来：
$ git merge issueFix
如果没有冲突的话，merge完成。有冲突的话，git会提示那个文件中有冲突，比如有如下冲突：
<<<<<<< HEAD:test.c
printf (“test1″);
=======
printf (“test2″);
>>>>>>> issueFix:test.c
可以看到 ======= 隔开的上半部分，是 HEAD（即 master 分支，在运行 merge 命令时检出的分支）中的内容，下半部分是在 issueFix 分支中的内容。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：
printf (“test2″);
这个解决方案各采纳了两个分支中的一部分内容，而且删除了 <<<<<<<，=======，和>>>>>>> 这些行。
在解决了所有文件里的所有冲突后，运行 git add 将把它们标记为已解决（resolved）。因为一旦暂存，就表示冲突已经解决。
如果你想用一个有图形界面的工具来解决这些问题，不妨运行 git mergetool，它会调用一个可视化的合并工具并引导你解决所有冲突：
$ git mergetool merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff Merging the files: index.html
Normal merge conflict for ‘test.c’: {local}: modified {remote}: modified Hit return to start merge resolution tool (kdiff3):
合并后的分支图如下：
master
/
C0 ---- C1 ---- C2 ---- C4 ---- C6
/
C3 ----C5
issueFix
注意，这次合并的实现，由于当前 master 分支所指向的 commit (C4)并非想要并入分支（issueFix）的直接祖先，Git 不得不进行一些处理。就此例而言，Git 会用两个分支的末端（C4 和 C5）和它们的共同祖先（C2）进行一次简单的三方合并。对三方合并的结果作一新的快照，并自动创建一个指向它的 commit（C6）
退出合并工具以后，Git 会询问你合并是否成功。如果回答是，它会为你把相关文件暂存起来，以表明状态为已解决。然后可以用 git commit 来完成这次合并提交。
[转] http://blog.microsuncn.com/?p=2000
http://www.cnblogs.com/longdouhzt/archive/2012/11/14/2770342.html
摘自《Git权威指南》
检出命令git checkout是git最常用的命令之一，同时也是一个很危险的命令，因为这条命令会重写工作区。检出命令的用法如下：
用法一：git checkout [-q] [<commit>] [--] <paths>...
用法二：git checkout [<branch>]
用法三：git checkout [-m] [[-b]--orphan] <new_branch>] [<start_point>]
上面列出的第一种用法和第二种用法的区别在于，第一种用法在命令中包含路径<paths>。为了避免路径和引用（或者提交ID）同名而发生冲突，可以在<paths>前用两个连续的短线（短号）作为分隔。
第一种用法的<commit>是可选项，如果省略则相当于从暂存区（index）进行检出。这和上一章的重置命令大不相同：重置的默认值是HEAD，而检出的默认值是暂存区。因此重置一般用于重置暂存区（除非使用--hard参数，否则不会重置工作区），而检出命令主要是覆盖工作区（如果<commit>不省略，也会替换暂存区中相应的文件）。
第一种用法（包含了路径<paths>的用法）不会改变HEAD头指针，主要是用于指定版本的文件覆盖工作区中对应的文件。如果省略<commit>，则会用暂存区的文件覆盖工作区的文件，否则用指定提交中的文件覆盖暂存区中和工作区中对应的文件。
第二种用法（不使用路径<paths>的用法）则会改变HEAD头指针。之所以后面的参数会写作<branch>，是因为只有HEAD切换到一个分支才可以对提交进行跟踪，否则仍然会进入“分离头指针”的状态。在“分离头指针”状态下的提交不能被引用关联到，从而可能丢失。所以用法二最主要的作用就是切换到分支。
如果省略<branch>则相当于对工作区进行状态检查。
第三种用法主要是创建和切换到新的分支（<new_branch>），新的分支从<start_point>指定的提交开始创建。
新分支和我们熟悉的master分支没有什么实质的不同，都是在refs/heads命名空间下的引用。
下图所示的版本库模型图描述了git checkout实际完成的操作。
下面通过一些示例具体看一下检出命令的不同用法。
$ git checkout branch
检出branch分支。要完成图中的三个步骤，更新HEAD以指向branch分支，以及用branch 指向的树更新暂存区和工作区。
$ git checkout
汇总显示工作区、暂存区与HEAD的差异。
$ git checkout HEAD
同上
$ git checkout -- filename
用暂存区中filename文件来覆盖工作区中的filename文件。相当于取消自上次执行git add filename以来（如果执行过）的本地修改。
$ git checkout branch -- filename
维持HEAD的指向不变。用branch所指向的提交中filename替换暂存区和工作区中相 应的文件。注意会将暂存区和工作区中的filename文件直接覆盖。
$ git checkout -- . 或写作 git checkout .
注意git checkout 命令后的参数为一个点（“.”）。这条命令最危险！会取消所有本地的 修改（相对于暂存区）。相当于用暂存区的所有文件直接覆盖本地文件，不给用户任何确认的机会！
http://www.cnblogs.com/craftor/archive/2012/11/04/2754147.html
http://www.cnblogs.com/longdouhzt/archive/2012/11/14/2770348.html
用git有一年了，下面是我这一年来的git使用总结，覆盖了日常使用中绝大多数的场景。嗯，至少是够用一年了，整理出来分享给大家，不明白的地方可以回复交流。
创建和使用git ssh key
首先设置git的user name和email：
git config --global user.name "xxx"
git config --global user.email "xxx@gmail.com"查看git配置：
git config --list然后生成SHH密匙：
查看是否已经有了ssh密钥：cd ~/.ssh 如果没有密钥则不会有此文件夹，有则备份删除
windows下，~是指用户当前目前，windows下用户当前目录的查看：echo %USERPROFILE%
一般情况下,
winxp:C:Documents and Settings当前用户名
win7:
生存密钥：
ssh-keygen -t rsa -C "xxx@gmail.com"按3个回车，密码为空这里一般不使用密钥。 最后得到了两个文件：id_rsa和id_rsa.pub 注意：密匙生成就不要改了，如果已经生成到~/.ssh文件夹下去找。
git变更项目地址
git remote set-url origin git@192.168.6.70:res_dev_group/test.git
git remote -v查看某个文件的修改历史
git log --pretty=oneline 文件名 # 显示修改历史 git show 356f6def9d3fb7f3b9032ff5aa4b9110d4cca87e # 查看更改
git push 时报错 warning: push.default is unset;
'matching'参数是 Git 1.x 的默认行为，其意是如果你执行 git push 但没有指定分支，它将 push 所有你本地的分支到远程仓库中对应匹配的分支。而 Git 2.x 默认的是 simple，意味着执行 git push 没有指定分支时，只有当前分支会被 push 到你使用 git pull 获取的代码。 根据提示，修改git push的行为: git config --global push.default matching 再次执行git push 得到解决。
git submodule的使用拉子项目代码
开发过程中，经常会有一些通用的部分希望抽取出来做成一个公共库来提供给别的工程来使用，而公共代码库的版本管理是个麻烦的事情。今天无意中发现了git的git submodule命令，之前的问题迎刃而解了。 添加
为当前工程添加submodule，命令如下：
git submodule add 仓库地址 路径
其中，仓库地址是指子模块仓库地址，路径指将子模块放置在当前工程下的路径。 注意：路径不能以 / 结尾（会造成修改不生效）、不能是现有工程已有的目录（不能順利 Clone）
命令执行完成，会在当前工程根路径下生成一个名为“.gitmodules”的文件，其中记录了子模块的信息。添加完成以后，再将子模块所在的文件夹添加到工程中即可。
删除submodule的删除稍微麻烦点：
首先，要在“.gitmodules”文件中删除相应配置信息。然后，执行git rm –cached命令将子模块所在的文件从git中删除。 下载的工程带有submodule
当使用git clone下来的工程中带有submodule时，初始的时候，submodule的内容并不会自动下载下来的，此时，只需执行如下命令：
git submodule update --init --recursive
即可将子模块内容下载下来后工程才不会缺少相应的文件。
git add文件取消
在git的一般使用中，如果发现错误的将不想提交的文件add进入index之后，想回退取消，则可以使用命令：git reset HEAD <file>...，同时git add完毕之后，git也会做相应的提示。
git删除文件：
删除文件跟踪并且删除文件系统中的文件file1git rm file1 提交刚才的删除动作，之后git不再管理该文件git commit
删除文件跟踪但不删除文件系统中的文件file1git rm --cached file1 提交刚才的删除动作，之后git不再管理该文件。但是文件系统中还是有file1。git commit
版本回退
版本回退用于线上系统出现问题后恢复旧版本的操作。 回退到的版本git reset --hard 248cba8e77231601d1189e3576dc096c8986ae51 回退的是所有文件，如果后悔回退可以git pull就可以了。
历史版本对比
查看日志git log 查看某一历史版本的提交内容git show 4ebd4bbc3ed321d01484a4ed206f18ce2ebde5ca，这里能看到版本的详细修改代码。 对比不同版本git diff c0f28a2ec490236caa13dec0e8ea826583b49b7a 2e476412c34a63b213b735e5a6d90cd05b014c33
分支的意义与管理
创建分支可以避免提交代码后对主分支的影响，同时也使你有了相对独立的开发环境。分支具有很重要的意义。 创建并切换分支，提交代码后才能在其它机器拉分支代码git checkout -b new_branch 查看当前分支git branch 切换到master分支git checkout master 合并分支到当前分支git merge new_branch，合并分支的操作是从new_branch合并到master分支，当前环境在master分支。 删除分支git branch -d new_branch
git冲突文件编辑
冲突文件冲突的地方如下面这样
a123
<<<<<<< HEAD
b789
=======
b45678910
>>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dcc
c冲突标记<<<<<<< （7个<）与=======之间的内容是我的修改，=======与>>>>>>>之间的内容是别人的修改。 此时，还没有任何其它垃圾文件产生。 你需要把代码合并好后重新走一遍代码提交流程就好了。
不顺利的代码提交流程
在git push后出现错误可能是因为其他人提交了代码，而使你的本地代码库版本不是最新。 这时你需要先git pull代码后，检查是否有文件冲突。 没有文件冲突的话需要重新走一遍代码提交流程add —> commit —> push。 解决文件冲突在后面说。
git顺利的提交代码流程
查看修改的文件git status；
为了谨慎检查一下代码git diff；
添加修改的文件git add dirname1/filename1.py dirname2/filenam2.py，新加的文件也是直接add就好了；
添加修改的日志git commit -m "fixed:修改了上传文件的逻辑"；
提交代码git push，如果提交失败的可能原因是本地代码库版本不是最新。
理解github的pull request
有一个仓库，叫Repo A。你如果要往里贡献代码，首先要Fork这个Repo，于是在你的Github账号下有了一个Repo A2,。然后你在这个A2下工作，Commit，push等。然后你希望原始仓库Repo A合并你的工作，你可以在Github上发起一个Pull Request，意思是请求Repo A的所有者从你的A2合并分支。如果被审核通过并正式合并，这样你就为项目A做贡献了。
一些错误处理
"pathspec 'branch' did not match any file(s) known to git."错误
git checkout master
git pull
git checkout new_branch使用git提交比较大的文件的时候可能会出现这个错误
error: RPC failed; result=22, HTTP code = 411 fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly Everything up-to-date
这样的话首先改一下git的传输字节限制
git config http.postBuffer 524288000 然后这时候在传输或许会出现另一个错误
error: RPC failed; result=22, HTTP code = 413 fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly Everything up-to-date
这两个错误看上去相似，一个是411，一个是413
下面这个错误添加一下密钥就可以了
首先key-keygen 生成密钥
然后把生成的密钥复制到git中自己的账号下的相应位置
git push ssh://192.168.64.250/eccp.git branch
http://www.cnblogs.com/pyer/p/4752770.html