[toc]
git
git是一个用于帮助用户实现版本控制的软件。
时光机穿梭
命令：
| 命令 | 解释 |
|---|---|
| git init | 初始化，表示即将对当前文件夹进行版本控制。 |
| git status | 查看Git当前状态： 红色文字：修改过的文件还未提交到暂存区 绿色：修改过的文件已提交到暂存区 |
| git diff | 查看文件修改了那些内容 |
| git add file | 将指定文件添加到版本库的暂存状态 |
| git add . | 对指定文件夹下的所有文件及子目录添加到版本库的暂存状态 |
| git commit -m '详细的描述信息' | 将暂存区的文件提交到版本库的分支。 执行后反馈： X file changed：X个文件被改动； X insertions：插入了X行内容 |
| git log | 历史版本记录 参数： --pretty=oneline 让log变得简洁 --graph 查看分支合并图 --abbrev-commit 简化commit 编号 |
| git reflog | 历史版本详细记录 |
| git reset --soft 版本号 | 提交后，回到暂存状态 |
| git reset --hard 版本号 | 提交后，回到修改过的内容 |
| git reset HEAD <file> | 把暂存区的修改回退到工作区 HEAD表示最新版本 |
| git diff HEAD -- file | 可以查看工作区和版本库里面最新版本的区别 |
| git check out 版本号 | 提交后，回到原始状态 |
| git rm | 用于删除一个文件 |
| --- | --- |
| git config user.name | 查看用户名 |
| git config user.email | 查看邮箱 |
| git config --global user.name "your name" | 修改用户名 |
| git config --global user.email "your email" | 修改邮箱 |
总结：
版本回退
-
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。 - 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
- 要重返未来，用
git reflog查看命令历史，以便确定要回到未来的哪个版本。
撤销修改
- 场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令
git checkout -- file。 - 场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令
git reset HEAD <file>，就回到了场景1，第二步按场景1操作。 - 场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考==版本回退==，不过前提是没有推送到远程库。
删除文件
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
分支管理 branch
命令
| 命令 | 解释 |
|---|---|
| git branch | 查看所有分支 |
| git branch <branch_name> | 创建分支 |
| git checkout <branch_name> | 切换分支 |
| git checkout -b <branch_name> | 创建并切换到指定分支 |
| git branch -m <branch_name> | 创建并切换到指定分支 |
| git branch -d <branch_name> | 删除分支 |
| git branch -D <branch_name> | 删除一个没有被合并过的分支 |
| git merge <branch_name> | 将指定分支合并到当前分支 参数： --no-ff -m "commit_name" dev 禁用Fast forward |
总结：
分支学习：branch称为分支，默认仅有一个名为master的分支。一般开发新功能流程为：开发新功能时会在分支dev上进行，开发完毕后再合并到master分支。
创建分支
合并分支
整体流程
分支管理策略
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：
因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
git merge --no-ff -m "merge with no-ff" dev
合并后，我们用git log看看分支历史：
git log --graph --pretty=oneline --abbrev-commit
可以看到，不使用Fast forward模式，merge后就像这样：
总结：
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并
Bug分支 stash：
有时候，你还没完成工作，不想提交，但又有新任务，必须切换到另一个分支，就用stash
命令
| 命令 | 解释 |
|---|---|
| git stash | 将当前工作区所有修改过的内容（红色文件）存储起来 将工作区还原到当前版本未修改过的状态 |
| git stash list | 查看存储的所有记录 |
| git stash clear | 清空存储 |
| git stash pop | 将第一个记录从存储区重新拿到工作区（可能有冲突） |
| git stash apply | 编号,将指定编号记录从“某个地方”重新拿到工作区（可能有冲突） |
| git stash drop | 编号，删除指定编号的记录 |
总结
- 修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
- 当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。
注意事项
需注意上面那句话所对作用范围的定义，如果你的文件没add，即没有“被跟踪”和“暂存”，stash是不会帮你保存的。例如，我增加了两个文件Readme，readme，我并没有git add这两个新文件，然后输入以下命令：
$ git stash
会提示：
No local changes to save
