master(主分支) 存在一条主分支(master).所有用户可见的正式版本,都从master发布(也是用于部署生产环境的分支,确保master分支稳定性).主分支作为稳定的唯一代码库,不做任何开发使用.master 分支一般由develop以及hotfix分支合并,任何时间都不能直接修改代码 develop(开发分支) 存在一条开发分支(develop).这个分支维护了当前开发中代码的主线,始终保持代码新于master以及bug修复后的代码.持续集成.最新隔夜版本的生成等都是基于这个分支.由

code reviewer之后,需要把dev分支的代码merge到master分支.通过在azkaban的服务器上git pull,最终将代码上线. git dev 分支merge到master # 检出到dev分支 git checkout dev # 拉取dev最新代码到当前文件夹 git pull # 检出到master分支 git checkout master # 将dev分支合并到master git merge dev # 将本地的master分支推送到origin主机 git p

aa@aa-PC MINGW64 /f/online-center/cloud/server-functions_services (master)                                                               $ git branch -a  #先查看下当前的本地和远程分支* master  remotes/origin/HEAD -> origin/master  remotes/origin/dev  remotes/origi

1.本地dev新建/切换本地master 新建 git checkout -b master 切换 git checkout  master 2.本地dev与本地master合并 git merge dev 3.新建的本地master与远程仓库master合并(如切换master忽略该条) git branch --set-upstream-to=origin/master master 4.将线上dev与线上master合并 git push

英文原文: http://nvie.com/posts/a-successful-git-branching-model/ 中文版: 在这篇文章中,我提出一个开发模型.我已经将这个开发模型引入到我所有的项目里(无论在工作还是私人)已经一年有余,并且它被证明是非常成功的.我打算写这些已经很久了,但我一直找不到时间来做,现在终于有时间了.我不会讲任何项目的具体细节,仅是关于分支策略和释放管理相关内容. 它主要体现了Git对我们源代码版本的管理. 为何是Git? 对于Git与其他集中式代码管理工具相比

一. 切换到被copy的分支(master),并且从远端拉取最新版本 $git checkout master $git pull 二.从当前分支拉copy开发分支 $git checkout -b dev Switched to a new branch 'dev' 三. 把新建的分支push到远端 $git push origin dev 四.拉取远端分支 $git pull There is no tracking information for the current branch. P

从master拉取新分支并push到远端 开发过程中经常用到从master分支copy一个开发分支: 1.切换到被copy的分支(master),并且从远端拉取最新版本 $git checkout master $git pull 2.从当前分支拉copy开发分支 $git checkout -b dev Switched to a new branch 'dev' 3.把新建的分支push到远端 $git push origin dev 4.关联 $git branch --set-upstr

应用场景:开发过程中经常用到从master分支copy一个本地分支作为开发分支 步骤: 1.切换到被copy的分支(master),并且从远端拉取最新版本 $git checkout master $git pull 2.从当前分支拉copy开发分支 $git checkout -b dev Switched to a new branch 'dev' 3.把新建的分支push到远端 $git push origin dev 4.关联 $git branch --set-upstream-to=

maven发布项目到私服-snapshot快照库和release发布库的区别和作用及maven常用命令 在日常的工作中由于各种原因,会出现这样一种情况,某些项目并没有打包至mvnrepository.如果采用原始直接打包放到lib目录的方式进行处理,便对项目的管理带来一些不必要的麻烦.例如版本升级后需要重新打包并,替换原有jar包等等一些额外的工作量和麻烦.为了避免这些不必要的麻烦,通常我们会通过Nexus搭建私有的仓库.下面着重介绍下怎么通过mvn命令将程序打包并发布到私有仓库Nexus中.

在使用webhook自动部署时测试出现此问题,通过以下方法粗暴解决: vim .git/config 文件,在remote "origin"  url中加入帐号密码,如图所示,格式为 https://username:password@git.dev.tencent.com/xxx/xxx.git

如何解决failed to push some refs to git Administrator@PC-20150110FGWU /K/cocos2d/yc (master) $ git push -u origin master To git@github.com:yangchao0718/cocos2d.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'git@g

背景: 一般开发自己的分支都是从最新的master上拉取,但中间master会有改动,此时需要将最新的master合到自己的分支中 命令: 1. 查看当前的分支,星号标识为当前分支:(如果查询结果有master分支,则跳到第4步) git branch 2.查看该工程所有的分支,星号标识为当前分支 git branch -a 3.copy一个master分支(步骤1中,本地没有master分支,需要copy一个) git branch -c master 4.切到master分支 git che

git log master..origin/master --oneline | wc -l 怎么知道本地仓库是不是最新的 git fetch   # 一定要先 fetch git log master..origin/master --oneline | wc -l 如果得出的结果是 0,代表本地仓库是最新的

git diff 你可以用 git diff 来比较项目中任意两个版本的差异. $ git diff master..test 上面这条命令只显示两个分支间的差异,如果你想找出 master , test 的共有父分支和 test 分支之间的差异,你用3个‘.'来取代前面的两个'.' . $ git diff master...test 哪些内容会被提交(commit) 通常用git diff来找当前工作目录和上次提交与本地索引间的差异.(最简单快捷) $ git diff 上面的命令会显示在当

Git常用命令速查表 & Git Basics  & github : release  发布! Git常用命令速查表: 1 1 1 1 1 http://git-scm.com/book/en/v2/Git-Basics-Tagging Git Basics 2.6 Git Basics - Tagging Tagging Like most VCSs, Git has the ability to tag specific points in history as being impo

使用场景 理解rebase 操作步骤 1 git切换至当前开发版本 2 查找需要变基到的branch,不一定是master 3 执行rebase变基 没有冲突的情况 存在冲突的情况 解决冲突 标记冲突已解决 继续rebase 操作 提交到远程分支 使用场景 以master为准创建分支dev_A 开发,开发过程中,master主分支有新的功能被提交进来,需要将这部分代码align到dev_A的版本. 这里仅列举这一个场景,rebase 还可以修改commit message 请参照我的另一篇文章

VC下Debug和Release区别 最近写代码过程中,发现 Debug 下运行正常,Release 下就会出现问题,百思不得其解,而Release 下又无法进行调试,于是只能采用printf方式逐步定位到问题所在处,才发现原来是给定的一个数组未初始化,导致后面处理异常.网上查找了些资料,在这 罗列汇总下,做为备忘- 一.Debug 和 Release 的区别         Debug 通常称为调试版本,它包含调试信息,并且不作任何优化,便于程序员调试程序.Release 称为发布版本,它往往

如果你在读这篇文章,说明你跟大多数开发者一样对GIT感兴趣,如果你还没有机会来试一试GIT,我想现在你就要了解它了. GIT不仅仅是个版本控制系统,它也是个内容管理系统(CMS),工作管理系统等.如果你是一个具有使用SVN背景的人,你需要做一定的思想转换,来适应GIT提供的一些概念和特征.所以,这篇文章的主要目的就是通过介绍GIT能做什么.它和SVN在深层次上究竟有什么不同来帮助你认识它. 那好,这就开始吧… 1.GIT是分布式的,SVN不是: 这是GIT和其它非分布式的版本控制系统,例如SVN

SSH1.首先需要检查你电脑是否已经有 SSH key cd ~/.sshls12.ssh表示ssh文件是个隐藏文件查看是否存在 id_rsa.pub 或 id_dsa.pub 文件,如果文件已经存在,那么可以跳过步骤2,直接进入步骤3.2.创建一个 SSH key ssh-keygen -t rsa -C "your_email@example.com"1-t 指定密钥类型,默认是 rsa ,可以省略.-C 设置注释文字,比如邮箱.-f 指定密钥文件存储文件名. 以上代码省略了 -f

本文主要包含如下内容: 1. Debug 和 Release 编译方式的本质区别 2. 哪些情况下 Release 版会出错 3. 怎样“调试” Release 版的程序 Debug 和 Release 编译方式的本质区别 Debug 通常称为调试版本,它包含调试信息,并且不作任何优化,便于程序员调试程序.Release 称为发布版本,它往往是进行了各种优化,使得程序在代码大小和运行速度上都是最优的,以便用户很好地使用.     Debug 和 Release 的真正秘密,在于一组编译选项.下面

[参考]:maven pom.xml加载不同properties配置[转] 首先 看看效果: 点开我们项目中的Maven projects 后,会发现右侧 我们profile有个可勾选选项.默认勾选localhost.localhost对应项目启动后,会加载配置左侧localhost文件夹下面的jdbc.perperties 和 redis.properties. 对于项目中存在测试数据库或者运行数据库的区分的时候 我们可以通过勾选快速切换.那么我们是如何实现的呢 一:在左侧文件目录项目 配置相