一品干货
1、初始化代码库
创建一个新的代码库（当前目录下）
$ git init
2、Clone到本地
$ git clone xxxx(url)
3、改动文件保存到缓存区
先add，此时没有commit，只是在缓存区
$ git add .
4、提交本地仓库
将缓存区的本次修改命名，并且提交到仓库区
$ git commit -m "change message"
5、提交本地缓存
将暂时没有提交到缓存区的代码保存到栈上，在更新代码时候使用，保存本地没有commit的内容
$ git stash
可以把储藏想象成一种剪贴板，它会获取你工作副本（working copy）中的所有改动，并且保存到一个新的剪贴板上。然后你就会得到一个“干净”的工作副本，也就是说一个不存在任何改动的工作目录。
之后你随时都可以重新调回那些保存在剪贴板中的改动到你的工作副本中来，从而继续你之前没有完成的工作。
你可以建立多个储藏单元，不仅仅局限于存储一组变化。同样，储藏也会不绑定在你所处的当前分支或是任何其它分支上，如果你想要调回任意一个储藏单元，它的改动将会被应用在你当前的 HEAD 分支上。
6、获取本地缓存列表
获取在栈上保存的代码列表
$ git stash list
7、还原缓存内容
$ git stash apply stash@{0}
(a) 使用 “git stash pop” 命令，它将调回最新的一个储藏单元，并且把它从剪贴板中删除掉。
(b) 使用 “git stash apply <stashname>” 命令，它将调回那个你所给出的储藏单元，而这个储藏单元还会保留在剪贴板中。你可以随时使用 “git stash drop <stashname>” 来删除它。
储藏的时机
储藏功能可以帮助我们得到一个干净的工作副本。当然，它还可以应用在很多不同的流程中，强烈推荐你在下列情况中储藏你的本地改动：
- 在切换到不同分支之前。
- 在获取（pulling）远程改动之前。
- 在合并（merging）或者衍合（rebasing）一个分支之前。
8、恢复、撤销对文件的修改
$ git checkout '文件名'
9、查看本地分支
$ git branch
10、查看远程分支
$ git branch -r
11、新建一个分支
$ git checkout -b 'xxxx'
执行后自动切换至该分支
12、切换分支
$ git checkout xxx
13、查看修改过的文件
$ git status
14、查看工作区和暂存区的差异
$ git diff
15、推送分支入远程仓库
$ git push origin 'xxxx'
16、拉取远程分支，合并到当前分支
$ git pull origin 'xxxx'
17、合并分支
合并至当前分支
$ git merge 'xxxx'
如果遇到冲突，无法自动合并，修改完冲突部分后，再次使用add和commit命令进行提交。
二品模式 - 简单Git-Flow
git-flow是对git的一个扩展，安装git-flow后可以使用扩展命令。git-flow把标准git命令用脚本进行组合。团队采用了简单的git-flow模式
git-flow会预设两个分支在仓库
master分支
只能用来包括产品代码。不要在此分支进行开发，这是产品的门面分支，代表产品最新最稳定的版本。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。
dev分支
是你进行任何新的开发的基础分支。这是功能最全，最前卫的分支，所有开发完成的功能，都会先推送至此分支，待充分测试和bug修复后并入master。
这两个分支被称作为长期分支它们会存活在项目的整个生命周期中。而其他的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的。它们是根据需要来创建的，当它们完成了自己的任务之后就会被删除掉。
在一般的情况下， “master” 分支可以有效地代表你的产品代码。所以，所有被合并到 “master” 分支的代码都必须保证质量，代码必须经过检验和确认。
这也意味着，开发工作不应该直接在 “master” 分支上进行，这也是一个最基本的准则。因此当你使用了 “git checkout master” 命令切换到 “master” 分支后并提交改动时，你就要问问自己，这样是否符合流程？这些改动是否能保证正确？
其他分支
每当开始着手开发一个新的功能的或是修复错误时，都要对应不同的主题建立一个新的分支。这是一种很通用的做法，并且也要成为一种习惯。
新建的主题分支都必须基于 “dev” 分支。当开发的功能完成后，或者错误被修复后，将修改的代码合并回 “dev” 分支。
在开发新功能的同时，团队的其他开发人员很可能已经把各自完成的改动整合回了 “dev” 分支。在这种情况下，就需要经常性地把那些在 “dev” 分支上的改动合并到自己的工作分支上来。这就确保了自己的工作分支一直处于最新的状态,并且当需要把已完成的改动整合回 “dev” 分支上时，可以减少可能出现的冲突和风险。
