git merge rebase的区别及应用场景

  前两天和同事交流发现他在日常开发中跟上游保持同步每次都是用git pull操作,而我一直习惯git fetch然后rebase,发现这两种操作后的log是有些区别的。他每次pull操作之后都会自动生成一个merge记录,而使用fetch+rebase就没有。

  查了下发现其实就是git pull命令两种参数的区别:

  git pull --merge  默认参数,相当于:git fetch + git merge

  git pull --rebase 手动指定,相当于:git fetch + git rebase

  git fetch所做的只是把远程库的文件获取到本地,也就是git merge和git rebase的区别。

在Git文档里,关于两个参数的应用场景有个很经典的原则:

  

你可以用rebase来合并那些本地已经修改了但是还没push的提交以保持和上游同步,但从来不要rebase任何你已经push过的任何东西。

先记录一下,想到合适的例子再来补充~

时间: 2024-12-16 13:03:18

git merge rebase的区别及应用场景的相关文章

git merge / rebase 分支的新建与合并

merge https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E6%96%B0%E5%BB%BA%E4%B8%8E%E5%90%88%E5%B9%B6 关键指令 git checkout -b xxx       新建分支 git branch -d xxx       删除分支 git merge  xxx          合并分支 git checkout xxx 切换分支 关

Git----拉取远程分支,git pull,git rebase,git pull --rebase的区别

git pull 相当于自动的 fetch 和 merge 操作,会试图自动将远程库合并入本地库,在有冲突时再要求手动合并. git rebase 可以确保生产分支commit是一个线性结构,方便rollback.其实生产也可以选择打tag来发布. 注:通过rebase可以确保主分支commit history线性结构上每个commit点都是相对独立完整的功能单元.除了美感,这样做也有助于团队间的分工协作,比随便merge效果好. git pull --rebase(推荐用这个) 把本地 rep

git各种命令 & git merge和git rebase的区别

git merge 和 rebase的区别: http://blog.csdn.net/jollyjumper/article/details/24743751 对于两个分支而言,rebase和merge没有区别,但是rebase更干净,因为log hisitory是线性的,但commit不一定按日期先后排,而是local commit总在后面,merge之后history变得比较复杂,但是commit按日期排序,stackoverflow上有个图示很好: http://stackoverflo

Git: 聊聊Rebase命令,与Merge的区别

转帖自2015-12-02 lazybios 日拱一卒 相比Merge命令,大家对Rebase要相对陌生一些,Rebase这个命令在<Pro Git book>中被翻译为「衍合」,感觉好别扭,个人感觉无论是从音还是行(为)叫做「变基」要更佳恰当一些. Rebase的大致流程 Step1: 场景假定 你基于一个远程分支origin创建了一个mywork的分支 git checkout -b mywork origin Step2: 进行开发 创建好分支后,你就开始兢兢业业的在mywork分支上开

git merge和git rebase的区别(转)

Description git rebase 和 git merge 一样都是用于从一个分支获取并且合并到当前分支,但是他们采取不同的工作方式,以下面的一个工作场景说明其区别 场景:  如图所示:你在一个feature分支进行新特性的开发,与此同时,master 分支的也有新的提交. 为了将master 上新的提交合并到你的feature分支上,你有两种选择:merging or rebasing merge 执行以下命令: git checkout feature git merge mast

Git分支merge和rebase的区别

Git merge是用来合并两个分支的. git merge b # 将b分支合并到当前分支 同样 git rebase b,也是把 b分支合并到当前分支 原理 如下: 假设你现在基于远程分支"origin",创建一个叫"mywork"的分支. $ git checkout -b mywork origin 假设远程分支"origin"已经有了2个提交,如图 现在我们在这个分支做一些修改,然后生成两个提交(commit). $ vi file.t

闲谈 git merge 与 git rebase 的区别

前言 相信大部分使用 Git 的朋友都会遇见相同的疑问,并且也从网上搜索了不少资料.那么,为什么我还要写这篇文章呢?因为我想尝试从自己的角度解释这个问题,如果能给到大家灵光一闪的感悟,便善莫大焉啦.估计点进来的朋友也对 merge 和 rebase 有了一定了解,所以我也就不浪费篇幅再去详细介绍 merge 和 rebase,让我们直入主题吧. merge 与 rebase 的区别 merge 现在假设我们有一个主分支 master 及一个开发分支 deve,仓库历史就像这样:现在如果在 mas

Git merge 和 rebase的区别

原文地址:http://blog.csdn.net/hudashi/article/details/7664631 git rebase用于把一个分支的修改合并到当前分支. 假设你现在基于远程分支"origin",创建一个叫"mywork"的分支. $ git checkout -b mywork origin 假设远程分支"origin"已经有了2个提交,如图 现在我们在这个分支做一些修改,然后生成两个提交(commit). $ vi file

git merge 与 git rebase的区别

前言 其实这个问题困扰我有一段时间,相信也有人和我一样有这个困扰,网上已有很多这种解释了,但是要么就是无图,要么就是解释的很乱,没太看懂,经过自己对git的使用,加上向同事请教,算是理解了这个问题,所以写下来分享一下,我尽量详细说明merge与rebase的区别 假设我们有如下图一所示仓库,该仓库有master和develop两个分支,且develop是在(3.added merge.txt file)commit处从master拉出来的分支.图一 merge 假设现在HEAD在(6.added