git flow 使用规范

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

把功能合并到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测试通过后合并到master和develop

(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分支相同

hotfix

(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使用：

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