windows安装git
windows 下载软件包: git for windows
安装完成之后，鼠标右键： "git"-->"Git Bash here", 会弹出命令行窗口
在命令行输入
$ git config --global user.name "sellsa" $ git config --global user.email "sellsa@qq.com"
注意：git config命令的--global参数，表示这台机器上的所有Git仓库都会使用这个配置，当然也可以对某个参数指定不同的用户名和Email地址
创建本地仓库
创建一个本地仓库，只要创建一个空目录（目录名不出现中文）,然后进入这个目录，在Git Bash窗口执行如下命令，就可以把这个目录变成git可以管理的仓库了
git init
创建完成后，这个目录下会多了一个.git的隐藏目录，它是来跟踪管理版本库的，不要手动修改这个目录的任何信息
生成SSH Key
在Git Bash创建下执行如下命令
$ ssh-keygen -t rsa -C 'sellsa@qq.com'
执行完成后会在当前用户的家目录下创建.ssh目录，该目录里面存放了私钥(id_rsa)和公钥(id_rsa.pub)
远程仓库
我在gitlab上已经创建了一个远程仓库demo
demo项目加入成员sellsa
sellsa登录gitlab--> 设置-->SSH密钥，把前面创建的公钥id_rsa_pub复制进来
然后，我们就可以在Windows上使用Git bash克隆远程仓库了
版本回退
查看提交过得版本
git log
信息如下：
commit ccc87133f8b19c6218a0074e32b8cdee66f3a821 (HEAD -> master) #这个提交ID可用于回退 Author: sellsa <sellsa@qq.com> Date: Fri Sep 28 18:57:53 2018 +0800
回退到上一个版本
git reset --hard HEAD^
回退到指定版本
git reset --hard <commit_id> #commit_id可以不写全，确保唯一性就行
我们写代码的地方就是工作区，我们仓库目录下还有个隐藏的目录.git，这个目录就是版本库了，版本库又有暂存区和分支
当我们在工作区修改了代码 git add <file> ---->会把修改存到暂存区 git commit -m 'xxxx'--->会把暂存区的修改提交到分支
如果我们修改了文件a.py，发现有问题，需要放弃修改， 可以如下：（工作区回退）
git checkout -- a.py
如果我们修改了文件a.py，并且已经git add a.py，发现有问题，想要放弃修改，可以如下（暂存区回退）
对于git rm 操作也是一样的
#第1步:回退暂存区的修改
git reset HEAD a.py
#第2步：回退工作区的修改
git checkout -- a.py
修改了a.py，经过了git add a.py, 并且已经git commit -m 'xxxx'提交到分支了，想放弃修改，可以如下（分支回退）
#直接回退到上1个版本
git reset --hard HEAD^
分支管理
创建 dev分支并切换到dev分支
git checkout -b dev
查看当前分支
git branch
切换到其他分支，如master
git checkout master
把dev 分支的工作成功合并到master分支
git merge dev
删除dev 分支
git branch -d dev
解决冲突
比如我在master分支有个文件a.py， 内容如下：
hello world...
然后我新建了分支dev,并且把a.py修改后并提交，修改后的内容如下：
hello world .... dev
我又回到master 分支修改a.py的内容并提交，修改后的内容如下：
hello world .... master
现在如果我们直接合并，会发生冲突
git merge dev
这种情况下，我们就需要手动解决冲突，git status也可以告诉我们冲突的文件，
找到冲突的文件，直接把文件内容修改成我们想要的内容，然后再提交，这样就完成合并了
分支策略
通常合并分支是，如果可能Git会使用Fast forward模式，这种模式下，删除分支后，会丢掉分支信息
我们可以强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息
git merge --no-ff -m "merge with no-ff" dev #因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
Bug分支
在Git中，每个bug都可以新建一个临时的分支来修复，修复后合并分支，然后将临时分支删除
当我们接到一个修复一个代号为 101的bug 的任务是，很自然的想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交
并不是你不想提交，而是工作只进行的一半，还没法提交，预计还需要1天完成时间，但是，必须在两个小时内修复该Bug,怎么办？
我们可以利用stash把当前工作现场程储藏起来，等以后恢复现场继续工作：
git stash
现在用哪个git status查看工作区就是干净的了，因此可以放心的创建分支修复bug
git checkout master git checkout -b issue-101
修复bug后提交并合并到master
git add . git commit -m "fix bug 101" git checkout master git merge --no-ff -m "merged bug fix 101" issue-101
现在，是时候接着回到dev分支干活了
git checkout dev
那么我们的之前的工作现场保存到哪去了呢，可以使用git stash list命令查看
因为上面我们只保存过一次现场，所以只需要如下恢复现场
git stash pop #恢复现场，并把保存的现场删除
如果我们有保存过多个stash，可以恢复指定的stash，用命令
git stash apply stash@{0}