Git的优点
分布式，本地包含远程仓库所有源码，可以离线操作
便捷的分支功能，可以很方便的进行团队合作和版本控制
Git flow
- Git flow 是前人经过探索总结出来的一套Git分支管理规范和流程，来保证我们在开发过程少踩一些坑。
首先，项目存在两个长期分支，前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。
主分支master ：
主分支 , 产品的功能全部实现后 , 最终在master分支对外发布；
该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 , 不能在此分支修改；
另外所有在master分支的推送应该打标签做记录,方便追溯；
开发分支develop ：
主开发分支 , 基于master分支克隆；该分支为只读唯一分支 , 只能从其他分支合并；
包含所有要发布到下一个release的代码； feature功能分支完成 , 合并到develop(不推送而是merge)；
develop拉取release分支 , 提测； release/hotfix 分支上线完毕 , 合并到develop并推送；
其次，项目存在三种短期分支。
功能分支（feature branch）：
功能开发分支 , 基于develop分支克隆 ；
功能开发完毕后合到develop分支；主要用来开发新功能，每个功能新开一个feature，保证功能的独立性；
feature分支可同时存在多个 , 用于团队中多个功能同时开发 , 属于临时分支 , 功能完成后可选删除；
（未正式上线之前不推送到远程中央仓库!!!）
分支命名: feature/ 开头的为特性分支， 命名规则: feature/user_module、 feature/cart_module
补丁分支（hotfix branch）：
补丁分支 , 基于master分支克隆 , 主要用于对线上的版本进行BUG修复；
修复完毕后合并到develop/master分支并推送 , 打Tag；
属于临时分支 , 补丁修复上线后可选删除；
分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似；
预发分支（release branch）：
测试分支 , 基于feature分支合并到develop之后 , 从develop分支克隆；
属于临时分支 , 功能上线后可选删除
主要用于提交给测试人员进行功能测试 , 测试过程中发现的BUG在本分支进行修复 ,
修复完成上线后合并到develop/master分支并推送(完成功能) , 打Tag；
分支命名: release/ 开头的为修复分支；
易错操作：
1、feature分支一旦合并到develop后不能再再该feature上修改了，
如果要改的话只能在合并后的develop上拉release进行修改，
这就是为什么未正式上线之前不推送到远程中央仓库!!!
2、在release合并到develop分支前，不能把feature2合并到develop，这样会造成混乱。
常用命令：
1、 创建功能分支
(develop)$: git checkout -b feature/xxx # 从dev建立特性分支
(feature/xxx)$: blabla # 开发
(feature/xxx)$: git add . #添加到暂存区
(feature/xxx)$: git commit -m 'blabla' #提交备注
2、功能完成，把功能合并到develop
(feature/xxx)$: git checkout develop # 切换至develop分支
(develop)$: git pull #一定要先更新develop，再去merge代码
(develop)$: git merge feature/xxx
(develop)$: git push #建议再编辑器里查看冲突文件，解决后再push
git branch -d feature/xxx #功能分支代码合并到develop后就没用了，如果接下来还要修改问题到对应到release分支进行修改
3、功能准备发布
(develop)$: git checkout -b release/xxx #这个分支专门用于发布前的准备，包括一些清理工作、全面的测试、文档的更新以及任何其他的准备工作。它与用于功能开发的分支相似，不同之处在于它是专为产品发布服务的。
4、发布完成
(release/xxx )$: git checkout master
(master)$: git merge release-0.1
(master)$: git push
(master)$: git checkout develop
(develop)$: git merge release-0.1
(develop)$: git push
(develop)$: git branch -d release-0.1
发布分支扮演的角色是功能开发（develop）与官方发布（master）之间的一个缓冲。无论什么时候你把一些东西合并入master，你都应该随即打上合适的标签。
(master)$: git tag -a Verson1.0 -m"Initial public release" #一般在提交的时候打标签
(master)$: git push --tags
5、线上bug修复
线上产生bug，新建hotfix分支进行修复，步骤和创建feature分支相同
(master)$: git checkout -b hotfix/xxx
(hotfix/xxx)$: # Fix the bug
(hotfix/xxx)$: git checkout master
(master)$: git merge hotfix/xxx
(master)$: git push
(master)$: git checkout develop
(develop)$: git merge hotfix/xxx
(develop)$: git push
(develop)$: git branch -d hotfix/xxx
Git Flow使用：
初始化:
这个命令会进行一些默认的配置，可以自动创建上面介绍的所有分支：master、develop、feature、relase、hotfix等分支。完成后当前所在分支就变成 develop. 任何开发都必须从 develop 开始
git flow init开始新Feature:
git flow feature start some_awesome_feature发布新特性分支到远程服务器(也就是push到远程):
git flow feature publish some_awesome_feature取得其它用户发布的新特性分支，并签出远程的变更:
git flow feature pull origin some_awesome_feature完成一个Feature:
该命令将会把feature/some_awesome_feature合并到develope分支，然后删除功能(feature)分支。
git flow feature finish feature/some_awesome_feature开始一个Release:
当你的功能点都完成时（需要发布新版本了），就基于develop创建一个发布(release)分支。
你可以选择提供一个 [BASE]参数，即提交记录的 sha-1 hash 值，来开启动 release 分支. 这个提交记录的 sha-1 hash 值必须是'develop' 分支下的
git flow release start RELEASE [BASE]Publish一个Release:
git flow release publish RELEASE发布Release:
别忘了git push --tags，标签打在release分支上
git flow release finish RELEASE开始一个Hotfix:
git flow hotfix start VERSION [BASENAME]发布一个Hotfix:
git flow hotfix finish VERSION
Git WorkTree应用：
1、应用场景：
a)我在 feature 分支开发得多些，但总时不时被高优先级的 BUG 打断需要临时去 develop 分一个分支出来解 BUG。
b)不同分支依赖的node_module包可能不同，打包发布时，可能因为切换分支但是包没有及时更新（被ignore），导致打包不成功
2、解决方法：git 2.6 以上开始提供了 worktree 功能，可以解决这样的问题
3、使用方法：
git worktree add -b <新分支名> <新路径> <从此分支创建>
git worktree add -b myNewBranch ../testDir master
这样，原本的仓库文件夹的同级目录下会出现一个 testDir文件夹。这个仓库里只有一个 .git 文件用来记录这是主仓库的一个工作目录。
相比于克隆多个仓库，使用这种方法创建的多个目录，有诸多好处：
只有一个仓库会占用版本库的空间，其它只占用工作目录的空间，对大型项目而言非常节省空间。
因为所有工作目录共享一个仓库，所以一个更新意味着整个更新（A 目录里对分支做的改动，B 目录里切到此分支也是改动后的；避免到时候找不到某个未推送的改动改到了哪个仓库）
4、删除方法：
如果要删除其中一个工作目录，直接删除文件夹即可。随后使用命令清除多余的已经被删的工作目录：
git worktree prune
5、本地git树清除缓存：
git remote prune origin
我的Git 常用命令：
1、 tag标签
- 显示所有的tag标签
git tag - 查看某个版本系列的缩略tag
git tag -l 'v1.0.*' - 查看某个版本系列的详细tag
git show v0.0.6可以看到你commit的内容 - 创建标签
git tag -a v1.0.0 -m "内容：v1.0.0" - 推送标签
git push origin v1.0.0 - 删除标签 删除本地：
git tag -d v1.0.0删除远程：git push origin :refs/tags/v1.0.0
2、 删除node_modules并清除缓存
- 删除node_module
rm -rf node_modules - 清除缓存
npm cache clear --force - 重新安装依赖
npm install --no-shrinkwrap --update-binary
3、 回滚
- 查看提交节点
git log - 本地强制回滚到某个节点
git reset --hard 12asddf123fsd34fsdfdf - 远程强制回滚
git push -f
4、git删除远端文件/文件夹（因为github/gitlab没有直接删除文件夹的操作）
- 先到你需要修改的文件下
- 删除远端对应的文件夹，本地不会删除
git rm -r --cached '文件名/文件夹名' -
git commmit -m '提交'、git push...
5、git 开启/关闭文件大小写鉴别（默认关闭，不推荐一直开启，可以在修改文件需要提交的时候开启，提交后再关掉）
- 开启区分大小写：
git config core.ignorecase false - 关闭区分大小写：
git config core.ignorecase true
6 、修改本地文件名大小写并推送到远端（不要跟我说你可以直接修改文件夹名字然后push）
举个例子：把Add文件夹改成add文件夹，由于window或者在一些开发工具里不支持把Add直接改成同名只是大小写不一样的文件，所以需要先改成add_，然后在改成add
- 按照上一步的操作打开git的区分大小写
- cd进入到需要修改的文件夹的上一级
- 把
Add文件夹改成add_:git mv Add add_ - 再把
add_文件夹改成add:git mv add_ add -
git commmit -m '提交'、git push...
7 、报错：似乎另外一个 git 进程在这个仓库中运行，例如：'git commit' 命令打开了一个编辑器...
rm -f ./.git/index.lock
