Branch

git branch // 查看本地分支git branch -a // 查看所有分支git branch -r // 查看远程分支git branch -vv // 查看本地分支与远程分支关联关系git checkout A // 切换本地分支（A：分支名，下同）git checkout -b // 创建本地分支并切换 （= git branch A + git checkout ） git push origin A:A // 推送本地分支到远程git branch --set-upstream electric origin/electric // 本地分支关联远程分支git push origin -d A // 删除远程分支 （用本地分支名，前面不加origin）git branch -d A // 删除本地分支快用你的项目练习一下吧！ （在项目.git -> config文件里，用代码同样可以实现上述操作：）

在开发新功能或修复 bug 时, 会从 master 上新建 branch 来处理, 当完成后会将这个 branch 推送到 origin 中, 如:git push origin <branch name>:<branch name>. origin 审核代码没有问题后就会 合并分支并删除, 但 本地 在 git pull 删除本地分支后, 仍能通过 git branch -a 看到这个 branch 的 origin ref.日积月累之下本地就会有很多这样无用的 branch ref, 很是让人厌烦, 遂在此记录清理的方法. GIT REMOTE 使用 git remote prune origin 就可以清除无用的 branch ref, 如果在命令后面加上 –dry-run 则可以看到哪些 branch 将被清除, 不会做清除动作.在检查无误后就可以执行 git remote prune origin 清除了. ...

书接上文在前一篇文章GIT 代码分支管理模型之一中，我们一起了解了一种叫做“成功的代码分支管理模型”。在这种模型中，我们确实可以很灵活地应对各种场景下的代码分支管理。理想总是那么美好，而现实偏偏那么蛋疼！要用好这种代码分支管理模型，需要全体开发人员对于GIT有比较深入的了解，比如merge, rebase,而且在每一次GIT的操作的时候要很清楚地知道自己正在开发的功能属于哪个分支的。对于同时开发多个功能点的同事来说，比如同时在开发一个下一版本的功能，以及进行产品线上细微改动的同事来说，确实要非常小心，稍不留神就容易怼错分支。历史背景在我们公司刚开始推行GIT的时候，领导下的指令是要让大家把精力全放在功能开发上，对于GIT只需要知道pull 跟push就可以了，经过一段历史时期的挣扎磨合，无形中我们形成了下面这种分支管理模型，称之为 “简单但啰嗦的分支管理模型"简单但啰嗦的分支管理模型主心骨这个模型主要有两种分支，一种叫DEV，一种叫REL。每一种后面都附加有对应版本号，比如DEV1.0, REL1.0RELx.0每个版本开始开发之前，都会从上一个版本的REL分支创建出一个新的REL分支，比如REL2.0是从REL1.0创建出来。当然第一个版本REL1.0就是从master分支创建出来的。这样就确保了每一个版本都是从上一个版本最新代码创建出来的。RELx.0神圣职责是作为每一个大版本发布的分支，并且是用来部署测试环境，准产品线以及产品线的分支。一般开发人员没有权限直接往RELx.0上面提交代码，只能从对应的DEV分支提交代码，再由集成人员合并到上面去。DEVx.0DEVx.0是与RELx.0对应的开发分支，所有开发人员默认都有权限往这个分支上提交代码。这也是开发人员所需要知道的分支，只需要从这上面pull最新的代码，然后把本地commit的代码push到上面去就可以了。小版本怎么办？在相当长的一段历史时期中，基本稳定在一个版本一个月左右。但有时会遇到有些小功能着急着上，等不及一个月上一次，所以就有了对应RELx.x以及DEVx.x (x > 0). 比如刚发布了REL3.0，这时有VIP客户需要上一个功能，改动不至于很大，但是也等不及下个月再上，于是我们就从REL3.0上面衍生出一条REL3.1的分支。按照之前的规则， REL分支是不允许直接修改代码的，所有对应的我们会创建DEV3.1的分支，给开发人员在上面进行开发。在这个过程中，下一版本4.0其实一直在同步进行开发的，但是这时REL4.0以及DEV4.0的分支上是没有DEV3.1的新功能的，所有在3.1的新功能上线之后，需要由持续集成人员DEV3.1的代码合并到DEV4.0上面去 （为什么不是直接REL3.1到REL4.0呢? 技术上是可行的，但是这样的话，REL4.0需要反向将代码合并会DEV4.0去，比较别扭），持续集成环境会自动将DEV4.0的新代码合并到REL4.0上面去，这样到时发布4.0的时候，才不会丢失了3.1新增的功能没bug的系统是不完整的有bug怎么办？不管是大版本还是小版本，总有可能产品线上有bug需要hotfix。在上次介绍的成功代码分支模型中，可以通过hotfix的分支进行代码修复。但在这个简单模型中，就不会新建hotfix的分支，而是在最新以上线的分支上进行修改。比如当前产品线上是REL3.0的代码，REL4.0是下一个大版本，REL3.1是准备上线的小版本，而这时产品上客户报了Level 1的case，按照SLA需要在三天内修复，我们是等不及REL3.1下周末上的，更不可能等REL4.0到下个月，所有我们要上到3.0的分支上：已上线的REL3.0以及对应的DEV3.0在上线之后就全被锁掉了，所以这时我们要找代码集成人员进行解锁然后在DEV3.0的分支上进行代码修复，直到测试通过后，合并代码分支到REL3.0进行紧急上线简单但啰嗦简单这种模型中，大部分开发人眼只需要记住版本的DEVx.x就可以了，其它REL什么的都可以不用管，不懂也没关系的。啰嗦每一个新版本开发前，管理人员都要新建对应的DEV分支，然后开发人员checkout对应分支进行开发。这样一来，一个版本，无论大小，都需要对应有两条分支，整个代码库看起来就有很多很多的分支，略显啰嗦。there is no free lunch!利弊关系上面已经做了一些简单的介绍，这种模型适合在项目比较大，团队人数较多的情况下使用，好处是开发人员不需要对GIT有过深的理解，只需会简单的pull / push，其它都由分支管理以及对应的权限管理搞定；其缺点也明显，就是整个代码库会有好多好多的分支，看起来比较啰嗦。

git常用命令1. branch分支文档api记录：分支的新建与合并常用git命令常用命令：// 新建一个 dev 分支，可以使用 git branch 命令git branch dev// 要切换到其他分支，可以执行 git checkout 命令git checkout dev// 新建并切换 [branch-name]git checkout -b iss53// 提交工作区自上次commit之后的变化，直接到仓库区git commit -a -m [message]// 提交时显示所有diff信息git commit -v// 推送到远程仓库git push [remote-name] [branch-name]// 将 master 分支推送到 origin 服务器时git push origin master// 将dev分支合并到mastergit checkout mastergit merge dev// 删除分支hotfixgit branch -d hotfix// git 删除远程分支git push origin –delete <BranchName>// 要看看哪些文件在合并时发生冲突，可以用 git status 查阅git status// git 打taggit tag -a v1.0.0 -m “1.0.0版本"git push origin v1.0.0// 在解决了所有文件里的所有冲突后，运行 git add 将把它们标记为已解决状态（译注：实际上就是来一次快照保存到暂存区域。）。// 因为一旦暂存，就表示冲突已经解决。如果你想用一个有图形界面的工具来解决这些问题，不妨运行 git mergetool，它会调用一个可视化的合并工具并引导你解决所有冲突 ...