当要push代码到git时,出现提示: error:failed to push some refs to ... Dealing with “non-fast-forward” errorsFrom time to time you may encounter this error while pushing: $ git push origin master To ../remote/ ! [rejected]        master -> master (non-fast forwar

Git 很是强大,在体验过rebase的华丽之后,再次发现之前在TFS上遇到的问题一下都有解了.但也印证了Git深入并非易事.这篇就谈下一个容易迷糊的概念:Fast forward. Fast-Forward 当前分支合并到另一分支时,如果没有分歧解决,就会直接移动文件指针.这个过程叫做fastforward. 举例来说,开发一直在master分支进行,但忽然有一个新的想法,于是新建了一个develop的分支,并在其上进行一系列提交,完成时,回到 master分支,此时,master分支在创建d

快捷操作: 切换并创建分支: git checkout -b 分支名. git checkout -b some-change 然后我打开某个文件(index.html)修改一下标题. Commit之后查看历史纪录, 可以看到再some-change分支里, 修改了index.html的title. 如果我想要把这个commit合并到master分支. 首先要切换回到master分支: git checkout master 然后, 我需要知道发生了哪些变化, 也就是比较这两个分支: git d

github上上传了版本库https://github.com/ChuckGitMerge   包括merge和rebase 没时间画图,貌似也不太会用画图工具,先写了一个文字版本的 更新:2015年08月11日,使用了git for windows自带的git gui作为图片说明 一.Fast Forward,No Fast Forward 和 Squash的对比 1.fast forward 假设从master分支有三个节点C1,C2,C3 从C3切出develop分支,并在develop分

创建dev分支,并且修改readme.txt的内容,然后提交 使用git merge --no-ff -m "说明内容" 分支名称合并分支 使用git log --graph --pretty=oneline --abbrev-commit查看分支情况 不使用fast forward的分支情况示意图如下,此时可以看出分支信息!

1.每一个提交相当于一个版本,版本都有版本号与之对应.通常通过git commit -m "name"为每次提交命名. 2.融合:即将次分支的最后一个版本添加到主分支上.当融合冲突时,是通过手动改动版本至需要的版本然后再提交实现的. no fast forward 融合使得主分支与次分支每次提交都能够被记录下来,而不会让主分支覆盖次分支. 几个重要的命令: 1.根据版本号查看某个版本: git reset --hard versionID 2.查看版本之间的关系图 git log --

通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息. 如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit, 这样,从分支历史上就可以看出分支信息. 下面我们实战一下--no-ff方式的git merge -- 首先,仍然创建并切换dev分支: $ git checkout -b dev --- 修改readme.txt文件,并提交一个新的commit: ---- 现在,我们切换回master: -

git的fast-forward在之前的文章有介绍过,但是介绍的不细: http://www.cnblogs.com/charlesblc/p/5953066.html fast-forward方式就是当条件允许的时候,git直接把HEAD指针指向合并分支的头,完成合并.属于“快进方式”,不过这种情况如果删除分支,则会丢失分支信息.因为在这个过程中没有创建commit squash 是用来把一些不必要commit进行压缩,比如说,你的feature在开发的时候写的commit很乱,那么我们合并的

如果执行了 Fast Forward,开发者根本不会看到这个分支,就像在 master 直接 commit 一样.

多人协同开发,使用Git经常会看到警告信息包含术语:fast forward, 这是何义? 简单来说就是提交到远程中心仓库的代码必须是按照时间顺序的. 比如A从中心仓库拿到代码后,对文件f进行了修改.然后push到中心仓库. B在A之前就拿到了中心仓库的代码,在A push成功之后也对f文件进行了修改.这个时候B也运行push命令推送代码. 会收到一个类似下面的信息:fast-forwards' section of 'git push --help' for details. chenshu@

git merge --no-ff -m "msg" x-branch:禁用Fast forward的普通合并 通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息(即:原来这个分支的做了什么在log中体现不出来). 为了保留原来的分支,即:普通合并,这样的话,merge的时候会提交一个commit,就会输入-m参数,在log中体现的也更清晰! 前面我们解决冲突的时候发现,我们解决冲突之后,即使 是在master主分支上合并dev

添加一个分支, 并且换到该分支: git checkout -b add-text 然后我再index.html里面添加点文字, 并commit. 然后再修改README.md, 添加文字, commit. 现在在 add-text这个分支上, 有两个commit, 看下log: 然后把这个分支合并到master分支. 首先切换到master分支, 然后再进行git merge, 但是这一次, 我想把我这个分支的过程留下痕迹, 所以要禁用fast-forward 合并: git merge 要被

当前分支合并到另一分支时,如果没有分歧解决,就会直接移动文件指针.这个过程叫做fastforward. 举例来说,开发一直在master分支进行,但忽然有一个新的想法,于是新建了一个develop的分支,并在其上进行一系列提交,完成时,回到 master分支,此时,master分支在创建develop分支之后并未产生任何新的commit.此时的合并就叫fast forward. 可以看出这是一次式的合并,且合并完之后的视图为扁平状,看不出develop分支开发的任何信息. 使用–no-ff进行合

版本控制 版本控制是什么已不用在说了,就是记录我们对文件.目录或工程等的修改历史,方便查看更改历史,备份以便恢复以前的版本,多人协作... 一.原始版本控制 最原始的版本控制是纯手工的版本控制:修改文件,保存文件副本.有时候偷懒省事,保存副本时命名比较随意,时间长了就不知道哪个是新的,哪个是老的了,即使知道新旧,可能也不知道每个版本是什么内容,相对上一版作了什么修改了,当几个版本过去后,很可能就是下面的样子了: 二.本地版本控制 手工管理比较麻烦且混乱,所以出现了本地版本控制系统,记录文件每次的

一.前奏 1.凡是记忆性的问题都不是问题! 如果你曾大致了解了Git这一门技术,你会发现这是属于"记忆型"的,所以,这门技术对我们来说不是问题,是一门熟能生巧的哲学. 有了这个前奏之后,我想您比我更加知道该如何去掌握它. 以下内容纯属个人总结,为了不让这篇总结显得唐突,我会结合以下思维导图一一开展: 二.准备工作 1.git配置: [1].菜单的了解 windows下安装了msmygit,鼠标右键继承了Git客户端的一些命令选项,如下: (在非git仓库目录下鼠标右键的菜单栏) Git

Git 的使用感受 从开始工作到现在,在公司里面一直用 svn 来做版本管理.大约半年前听说了 Git,因为 Git 的光辉相当耀眼,作者是 Linus Torvalds,被大量的开源软件采用,如 jQuery, Perl, Qt, ROR, YUI, GNOME 等,所以决定学一学.比较庆幸的是,国内有一本较好的介绍 Git 的书:<Git 权威指南>.我大概花了一个月的周末时间来学习它.在这里总结一下使用 Git 的感受,主要是和 SVN 来做一些比较,以便突出 Git 的特点. 学习成本

关于版本控制 git是一种分布版本控制系统,每一主机都保存了完整副本.必杀技是分支. 在Windows可安装git客户端msysgit. git基础 第一次看progit觉得有点不懂,不懂版本控制,一条条命令写的觉得很麻烦没头绪.这次在看了向导guides.github.com之后,文章避免了一些细枝末节的命令,而是介绍工作流程,懂了一点工作大概流程再开始使用命令比较合适. 三种状态 工作目录.暂存区域.git目录 工作目录就是你打开文件夹看到可见目录.暂存区域含有添加(add)之后的文件.gi

1 Git详细教程 1.1 Git简介 1.1.1 Git是何方神圣? 1.1.2 重要的术语 1.1.3 索引 1.2 Git安装 1.3 Git配置 1.3.1 用户信息 1.3.2 高亮显示 1.3.3 忽略特定的文件 1.3.4 使用.gitkeep来追踪空的文件夹 1.4 开始操作Git 1.4.1 创建内容 1.4.2 创建仓库.添加文件和提交更改 1.4.3 diff命令与commit更改 1.4.4 Status, Diff 和 Commit Log 1.4.5 更正提交的信息

aaarticlea/png;base64,iVBORw0KGgoAAAANSUhEUgAAAykAAADuCAIAAACyDd+sAAAAA3NCSVQICAjb4U/gAAAgAElEQVR4Xuy9B5hd1XX3fe/00TT13oWEEAgkqsBUgU03dmwT7Dhxd+LEOPGbJ36SPEkefymO8/p1nOJesAMO4BjboRchujBFBYQEklDvmlGfXu7M91v7f++eM+dejUbSjDQz2gd0Zt99dl1n77X/e62110nW169OZK5UW

转自:http://www.cnblogs.com/angeldevil/archive/2013/11/26/3238470.html 注:非常推荐的一篇关于git的博文 目录: 版本控制 一.原始版本控制 二.本地版本控制 三.集中版本控制 四.分布式版本控制 GIT 一.获得GIT仓库 二.GIT中版本的保存 三.GIT文件操作 四.提交与历史 五.GIT分支 六.标签-tag 七.Git配置 八.其他 REPO 版本控制 版本控制是什么已不用在说了,就是记录我们对文件.目录或工程等的修改

查看分支:git branch 创建分支:git branch <name> 切换分支:git checkout <name> 创建+切换分支:git checkout -b <name> 合并某分支到当前分支:git merge <name> 删除分支:git branch -d <name> 一.git的简介 git是linux用两个月的时间用C语言写的一个分布版本控制系统. 版本控制系统主要有三种:本地版本控制系统.集中化版本控制系统.分布