git 代码管理工具，很不错，值得推荐

不错的教程

远程仓库

Test 连接

 ssh -vT git@github.com

远程仓库初始化

制作patch 和 patch

教程

安装 git

sudo apt-get install git ( 安装)

git 命令

git init （通过git init命令把这个目录变成Git可以管理的仓库）
git add readme.txt (用命令git add告诉Git，把文件添加到仓库：)
git commit -m "wrote a readme file" filename (命令git commit告诉Git，把文件提交到仓库,-m后面输入的是本次提交的说明)

git status (命令可以让我们时刻掌握仓库当前的状态)

git diff readme.txt （看看具体修改了什么内容）
git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别

git log： 版本控制系统肯定有某个命令可以告诉我们历史记录，在Git中，我们用git log命令查看
git log --pretty=oneline

git reset :当前版本append GPL回退到上一个版本add distributed，就可以使用git reset命令
git reset --hard HEAD^ (回退到上一个版本库)
git reset --hard 1094a(commit ID) （回退到指定ID的版本库）
当你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？在Git中，总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到add distributed版本时，再想恢复到append GPL，就必须找到append GPL的commit id。Git提供了一个命令git reflog用来记录你的每一次命令
git reflog
Notes：

1. HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id；
2. 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本；
3. 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本；

git checkout -- readme.txt (Git会告诉你，git checkout -- file可以丢弃工作区的修改)
git reset HEAD (同样告诉我们，用命令git reset HEAD 可以把暂存区的修改撤销掉（unstage），重新放回工作区)

一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了：
$ rm test.txt
这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：
现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：
git rm test.txt
git commit -m "remove test.txt"
另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：
$ git checkout -- test.txt

我们创建dev分支，然后切换到dev分支
git checkout -b dev
创建与合并分支
Reads: 999267
在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

git-br-initial

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长：

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

git-br-create

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

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

git-br-dev-fd

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

git-br-ff-merge
所以Git合并分支也很快！就改改指针，工作区内容也不变！

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

git-br-rm
真是太神奇了，你看得出来有些提交是通过分支完成的吗？

下面开始实战。

首先，我们创建dev分支，然后切换到dev分支：

$ git checkout -b dev
Switched to a new branch 'dev'
git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
$ git branch dev
$ git checkout dev
$ git branch然后，用git branch命令查看当前分支

现在，dev分支的工作完成，我们就可以切换回master分支：
$ git checkout master

$ git merge dev我们把dev分支的工作成果合并到master分支上
$ git branch -d dev 就可以放心地删除dev分支了
$ git branch 查看分支
冲突解决：
$git merge feature1
果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：
我们可以直接查看readme.txt的内容：
用带参数的git log也可以看到分支的合并情况：
$ git log --graph --pretty=oneline --abbrev-commit
$ git merge --no-ff -m "merge with no-ff" dev准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

Bug分支
你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：
$ git stash list
stash@{0}: WIP on dev: f52c633 add merge
工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了：

你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
$ git stash apply stash@{0}

删除没有被合并的分支：
销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。。
现在我们强行删除：
$ git branch -D feature-vulcan

忽略某些文件时，需要编写.gitignore
配置别名：敲一行命令，告诉Git，以后st就表示status：
$ git config --global alias.st status