Git常用版本策略
1. Git常用命令
-
查看本地分支
git branch -
查看远程分支
git branch -a* dev feature1 master remote remotes/origin/HEAD -> origin/master remotes/origin/dev remotes/origin/master可以看到命令返回的结果中下面的几行前缀是remotes，这几行表示远程仓库的分支，origin可以理解成远程仓库的通用名称，后面的master、dev什么的表示远程仓库的分支名。
-
创建本地分支
git branch test该命令表示在本地创建一个名字叫test的分支。
-
删除本地分支
git branch -d test删除test本地分支。
-
切换分支
git checkout test
-
推送本地分支到远程仓库
git push origin test该命令表示将当前所在的本地分支push到远程仓库，并且分支命名为test。
-
本地分支与远程仓库分支关联
git push --set-upstream origin feature
-
本地分支pull
git pull origin dev直接git pull不加参数默认的是将当前分支对应的remote repo里的代码拉下来，如果加上origin dev表示将origin远程库中的dev分支代码拉下来。
-
代码merge
git merge dev将dev分支的代码merge到当前分支
-
merge冲突处理
如果在merge或者pull的时候发生conflict，这时需要手工将冲突的问题解决，解决后再commit代码。
2. Git版本策略
之前也写过一篇介绍版本策略的文章，可能是我语言表达的问题，反响不是很强烈，这几天正好也有朋友咨询git的版本策略，因为朋友的团队之前一直用的都是svn这类集中式统一版本管理，所以一直用svn的思路去理解git，导致团队最后把git使用成了svn，完全没有体现git版本管理的优势。在我的理解中git版本管理最大的方便之处是灵活的分支策略和分布式的版本管理。下面我就介绍下目前主流的git版本策略，如果大家有更好的版本策略希望大家能留言。
2.1 概念普及
这里介绍几个git中的基本概念，有些同学git用了一段时间但是对git还是没有实质的概念，这里我先把几个关键概念在这里做个解释.
wokspace工作区
index暂存区
local repository 本地仓库
-
remote repository 远程仓库
从上图中可以看到git的数据流：
1）开发者在本地通过add命令将工作区代码添加到暂存区；
2）通过cimmit命令提交代码到本地仓库，也可以直接通过commit －a来添加文件到暂存区并提交代码到本地仓库；
3）这时就可以通过push将本地仓库的代码推送到远程仓库，完成代码的服务器提交。
远程仓库为我们保存一份代码拷贝，类似svn的服务器统一托管，而工作区、暂存区和本地仓库都是在用户开发机本地，这就可以让我们在没有网络的情况下，照样可以提交我们的代码到本地的仓库，等有网络了再push到远程仓库。
2.2git版本策略
分支清单：master、dev、release、feature、bug
master分支用于发布版本，是比较稳定的发布版本，版本发布后都在master分支上打上tag。
dev分支用于日常开发，所有开发人员都将将remote repo的dev分支clone到本地，用于日常开发。
feature分支为开发人员拉的新功能开发分支，当开发人员功能开发完成后，切换到dev分支，将feature分支的代码merge到dev分支。
release分支为当dev分支版本稳定准备发版的时候，从dev拉一个release分支，后续发布前再测出的bug在dev开发修复完成后，直接merge到release分支，在测试全部结束后，将release分支的代码merge到master分支并打上发版标签。
bug分支主要是用于在日常运行过程中发现线上程序有紧急bug需要修复则从master分支找到发版的tag，新建一个bug分支从master分支拉取线上版本的tag代码，在bug分支对代码进行修改，修复问题后将代码merge至master分支，并把bug修复merge到dev分支。
在这个版本策略中，master、release、dev分支必须要有远程仓库，feature的两个开发分支可以没有远程仓库，开发人员在本地开发完后直接merge到dev分支，但还是建议有远程仓库，这样可以防止本地代码丢失后可以通过远程库找回，并且其他同学的电脑中也会分布式保存了版本。
这个gitflow的版本策略核心思想就是在自己的feature分支上进行新功能开发，开发完成后将代码merge到dev分支，等一个迭代的所有功能都开发完成后，小伙伴都将各自的feature分支的代码merge到dev分支后，就可以从dev分支打tag发布测试版本进行测试了，如果在测试过程中遇到bug，则开发同学在自己的开发分支修复bug后，提交代码并merge到dev分支，等测试工作基本结束准备发布版本的时候，需要单独拉一个release分支，用于最后的版本发布，如果在版本发布前还发现问题，那么就直接在开发分支上修复问题后直接提交到release分支，在最后发布正式版本的时候将release分支的代码merge到master分支，并且打上发版tag，至此一次从开发到版本发布的版本策略就全部结束了。
