Git学习、Git命令
第一阶段:Git整体性概念&原理的掌握
第二阶段:Git常用命令的掌握
第三阶段:通过IDEA内置Git插件，模拟日常开发的分支合并场景，掌握使用IDEA插件支持日常开发
第四阶段:熟悉&掌握GitFlow的工作流程，并将GitFlow的应用到工作的应用之中
第一阶段
Git是分布式版本管理工具，它的优势是本地仓库&具备完善的分支管理，便于多人开发。
Git的工作区和暂存区，当前工作的目录如/learning就可以当作一个工作区。
版本库，每个Git项目都有一个.git文件，这个文件就是Git的版本库，Git版本库里存了很多东西，其中最重要的就是stage(或者叫index)暂存区，Git默认会自动创建一个Master分支，以及指向Master分支的Head指针。
Git版本库添加东西，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
管理修改
为什么Git比其他版本控制系统设计的优秀，因为Git跟踪并管理的是修改，而非文件。
Git每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。HEAD严格来说不是指向提交的，而是指向master,master是指向提交的，所以HEAD指向的是当前分支。
git merge用于合并指定分支到当前分支，默认使用的是Fast Forward，这种模式被称为快进模式，也就是把master直接指向dev的当前提交，所以合并速度非常快。
在出现master分支和dev分支都有新提交的情况下，在进行merge的话会出现冲突的情况，如果出现冲突的情况下，需要手动自己修改冲突的文件才能够进行合并提交。
通过，合并分支Git会用FastForward模式,但是这种模式下,删除分支后,会丢掉分支信息。通过git merge --no-ff -m 'message' branch表示禁用FastForward模式,这样不会丢到branch的提交历史
多人在用一个分支协作时，很容易出现冲突。即使没有冲突，后push的童鞋也需要先pull，在本地merge后，然后在push到origin，但是如果直接merge会导致git提交的历史节点很乱.Git有一种叫做Rebase的操作，它可以本地的提交历史变成一条直线，rebase操作前后，最终提交的内容是一致的，可以让master分支变成一条直线。
第二阶段
#git branch
查看分支(本地):git branch
查看分支(远端):git branch -a
创建分支:git branch <dev-name>
切换分支:git checkout <dev-name>
创建+切换分支:git checkout -b <dev-name>
在本地基于其他分支创建分支: git checkout -b newBranch originBranch
拉取远程分支到本地:git checkout -b local-branch origin/remote-branch
合并某分支到当前分支:git merge <dev-name>
删除本地分支:git branch -d <dev-name>
#git merge分支
1.首先切换到master分支上
git checkout master
2.如果是多人开发的话，需要把远程master上的代码pull下来
git pull orgin master
3.然后把dev分支的代码合并到master上
git merge dev
4.然后查看状态
git status
5.执行进行push
git push origin master
#本地新建分支推到远端，并建立关联
git checkout -b <dev-name>
git push origin <dev-name>:<remote-name>
#在本地删除远端分支
git push origin [空格]:<branch-name>
or
git push origin --delete<brach-name>
#从远程获取最新版本到本地，不会自动合并分支
git fetch
#暂存stash
git stash save 'comment'
git stash list
//从git栈中获取最近一次stash进去的内容，恢复工作区的内容。获取以后会删除栈中对应的stash
git stash pop
//将缓存区进行应用到工作区
git stash apply
//删除最近的stash
git stash drop
//删除全部的stash
git stash clear
#查看远端的信息
git remote show origin
#删除本地但是远端已经不存在的分支
git remote prune origin
or
git fetch -p
#git rebase
以dev和master举例
1.dev:
git pull --rebase
2.master:
git pull --rebase
3.dev:
git rebase master
4.解决冲突:
git rebase --continue
5.master合并dev
git merge dev
git push
6.然后删除这个deb分支
git branch -d dev
tips:
git rebase --skip（是高风险的操作，引起冲突的commits会被丢弃，这部分代码修改会丢失）
git rebae --abort（是无风险的操作，会回到rebase操作之前的状态，2个分支的commits毫发无损）
#更新远程分支
git remote update origin --prune
#用远程分支覆盖本地分支
git fetch --all
git reset --hard orgin/dev
git pull
#git revert
git revert HEAD 撤销前一次commit
git revert HEAD^ 撤销前前一次commit
git revert commit-id(撤销指定的版本,撤销也会作为一次提交进行保存)
tips:git revert是提交一个新的版本，将需要revert的版本内容再方向修改回去，版本会递增，不影响之前提交的内容
工作区的修改撤销到最近一次git add 或 git commit时的内容
git checkout -- .
git从当前分支的某一个commit开始创建新分支
git checkout commitId -b 本地新branchName
git 文档
git help
git help fetch
git 分支重命名
git branch -m old_name new_name
git 查看分支的创建时间
git reflog show --date=iso <branch name>
git 显示日志
git log -[length]
例如：git log --oneline -2
-[length]参数用于指定显示多少条日志。
--oneline参数可以将每条日志的输出为一行，如果日志比较多的话，用这个参数能够使结果看起来比较醒目。
git log --graph
git log --graph --oneline
--graph参数会绘制提交的线索，如果有合并的话，也会更清晰地显示出来
git 合并多个commit节点记录
1.查看日志：
git log --abbrev-commit --oneline
2.找到要合并的commit值，copy下来（复制的commitId不包含在合并范围内，最好用 “origin/buriedP, buriedP” 这个点对应的id）
3.合并节点
git rebase -i commitId（复制的那个commitId,或者把commitId替换成HEAD~n,n是指针向前移动的步数）
4.解决冲突
如果有冲突正常解决，如果没有应该直接跳到下一步了；
5.强制覆盖 origin/master（需要覆盖远端记录的时候才用到这步操作，正常本地分支不用这个命令）
git push -f
tips：
q 退出 wq 写退出
git tag 打标签
1.查看tag:（vim 中 q 退出）
git tag
2.打tag，并添加注释
git tag -a v1.4 -m 'my version 1.4'
译注：-a 取 annotated 的首字母，指定标签名字即可; 而 -m 选项则指定了对应的标签说明
3.推tag
git push --tags
4.查看相应标签的版本信息:
git show v1.6
5.删除标签
git tag -d v0.1.2
6.补打标签
git tag -a v0.1.0 49e0cd22f6bd9510fe65084e023d9c4316b446a6
注释：打标签不必要在HEAD之上，也可在之前的版本上打，这需要你知道某个提交对象的commit id，通过git log命令获取。
---
注释，打轻量级标签，也就是tag的简略写法，没有备注：
git tag vx.x.x
git commit -- amend （修改上一次的提交内容）
git add . （先提交到暂存区）
git commit --amend --no-edit （与上次提交合并）
ps:在commit后，还没有push前，修改刚刚提交的这次commit,编辑器会弹出上一次提交的信息，加入--no-edit标记会修复提交但不修改提交信息。需要的话你可以修改，不然的话就像往常一样保存并关闭文件。完整的提交会替换之前不完整的提交.
github 的 Contributions 的提交记录是与email相关联的，因此需要修改config里的默认邮箱
查看项目提交用的邮箱和姓名，如果全局查看需要添加--global：
git config user.email
git config user.name
修改所在项目：
git config user.email "你的邮件地址"
git config user.name "你的Github用户名"
修改全局：
git config --global user.email "你的邮件地址"
git config --global user.name "你的Github用户名"
git 常用撤销
# 撤销 git add 操作
git reset HEAD # 取消add操作并保留修改
git checkout -- . # 会删除掉刚刚的修改内容
# 撤销 git commit 操作
git reset --soft <commit_id> #可以回退到某个commit并保存之前的修改 <commit_id>从git log中取，取前7位即可
git reset --hard <commit_id> #回退到某个commit不保留之前的修改
# 撤销 git push 操作
git revert <commit_id> #这是git最安全、最基本的撤销场景，因为它并不会改变历史,所以你现在可以 git push 新的“反转” commit 来抵消你错误提交的 commit。
git log 与 git reflog
1.git log 命令可以显示所有提交过的版本信息;
2.git reflog 可以查看所有分支的所有操作记录（包括已经被删除的 commit 记录和 reset 的操作）
git reset 三种用法
1. git reset (–-mixed) HEAD~1
回退一个版本,且会将暂存区的内容和本地已提交的内容全部恢复到未暂存的状态,不影响原来本地文件(未提交的也
不受影响);
2. git reset –-soft HEAD~1
回退一个版本,不清空暂存区,将已提交的内容恢复到暂存区,不影响原来本地的文件(未提交的也不受影响);
3. git reset –-hard HEAD~1
回退一个版本,清空暂存区,将已提交的内容的版本恢复到本地,本地的文件也将被恢复的版本替换;
其他
1. git checkout -- <文件名> 撤销对尚未暂存文件的修改，该操作不可逆，慎用。
2. git reset HEAD <文件名> 将已经暂存的文件进行撤销，回到未暂存的状态。（git add . 之前的样子）；
3. git status 查看当前仓库中文件的状态；
4. git status -s 文件状态的简写（M - 修改， A - 添加， D - 删除， R - 重命名，?? - 未追踪）；
5. git diff 不加参数即默认比较工作区与暂存区(https://www.cnblogs.com/qianqiannian/p/6010219.html)
第四阶段
版本管理带来的挑战
1.如何开始一个Feature的开发，而不影响别的Feature
2.很容易创建分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？
3.哪些分支已经回到了主干？
4.如何进行Release的管理?开始一个Release的时候如何在Prepare Release的时候，开发人员可以继续开发新的功能。
5.线上出现Bug了，如何迅速恢复？而且修复的代码要包含到开发人员的分支以及下一个Release
GitFlow
就像代码规范一样，代码同样需要一个清晰的流程和规范
GitFlow常用分支
1.Master分支
也就是我们经常使用的Prod分支，包含所有要发布到下一个Release的代码，这个主要合并只能从其他分支合并，不能在这个分支直接修改。
2.Develop分支
这个分支是我们的主要开发分支，包含所有要发布到下一个Release的代码，这个主要合并其他分支，比如Feature分支
3.Feature分支
这个分支主要用来开发一个新功能，一旦开发完成，我们合并回Develop分支进入下一个Release
4.Release分支
当我们需要发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成后，我们合并到Master和Develop分支
5.Hotfix分支
当我们在Production发现Bug时候，我们需要创建一个Hotfix,完成Hotfix后，我们合并到Master和Develop分支，所以Hotfix的改动会进入下一个Release
#初始分支
所有在Master分支上的Commit应该Tag
#Feature分支
Git-Flow-Graph
