[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"	修改邮箱

总结：

版本回退

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

撤销修改

• 场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。
• 场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD <file>，就回到了场景1，第二步按场景1操作。
• 场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考==版本回退==，不过前提是没有推送到远程库。

删除文件

命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

image

分支管理 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分支。
创建分支

image

合并分支

image

整体流程

image

分支管理策略

通常，合并分支时，如果可能，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后就像这样：

image

总结：

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

image

合并分支时，加上--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