d********t
发帖数: 9628 | 1 看tutorial好像说rebase的话回重整history，不过我试了试根merge没任何不同啊。 |
c*********e
发帖数: 16335 | 2 rebase就是把它放到主线上，不再是branch.这个很少用。
一般是用merge.
【在 d********t 的大作中提到】
: 看tutorial好像说rebase的话回重整history，不过我试了试根merge没任何不同啊。
|
d********t
发帖数: 9628 | 3 不一定啊，可以指定branch名。
【在 c*********e 的大作中提到】
: rebase就是把它放到主线上，不再是branch.这个很少用。
: 一般是用merge.
|
c*********e
发帖数: 16335 | 4 对呀，就是并入主线，成了base,不再是个分支。
【在 d********t 的大作中提到】
: 不一定啊，可以指定branch名。
|
g*****g
发帖数: 34805 | 5 rebase是你在支线上，别人的改动已经merge到了主线上，你在支线上做rebase就能把
别人的改动放入你的支线，而且在你改动的前头。这样
保证历史是干净的，你的改动在最后面。推荐的做法就是经常rebase，通过code
review之后，做一个squash然后merge到主线上。
如果你把主线merge到支线上, merge的部分就在你的修改后面了。这之后你发现你错了
想把你的revert，就做不了。
【在 d********t 的大作中提到】
: 看tutorial好像说rebase的话回重整history，不过我试了试根merge没任何不同啊。
|
c*********e
发帖数: 16335 | 6 http://www.chilsonwilcox.com/autocheck.php?vin=4T1BK46K97U04518
【在 g*****g 的大作中提到】
: rebase是你在支线上，别人的改动已经merge到了主线上，你在支线上做rebase就能把
: 别人的改动放入你的支线，而且在你改动的前头。这样
: 保证历史是干净的，你的改动在最后面。推荐的做法就是经常rebase，通过code
: review之后，做一个squash然后merge到主线上。
: 如果你把主线merge到支线上, merge的部分就在你的修改后面了。这之后你发现你错了
: 想把你的revert，就做不了。
|
t**r
发帖数: 3428 | |
c*********e
发帖数: 16335 | 8 right. rebase是把你的branch并入master,这是不好的。
【在 t**r 的大作中提到】
: don't ever use rebase.
|
w**z
发帖数: 8232 | 9 每个公司规范不同，我们都是用rebase 的。
【在 c*********e 的大作中提到】
: right. rebase是把你的branch并入master,这是不好的。
|
c*********e
发帖数: 16335 | 10 merge的效果是一样的啊。
【在 w**z 的大作中提到】
: 每个公司规范不同，我们都是用rebase 的。
|
|
|
L***s
发帖数: 1148 | 11 我们这里（用github）的约定是：
在reviewer写第一条comment之前，推荐rebase支线onto主线；
一旦有了一条comment，就不允许rebase/squash了，只能merge主线into支线，
目的是保持整个review flow，方便reviewer看清楚你采取何种步骤
address他的comments。
关于merge之后的revert，只要diff出一个commit来就可以revert了。
【在 g*****g 的大作中提到】
: rebase是你在支线上，别人的改动已经merge到了主线上，你在支线上做rebase就能把
: 别人的改动放入你的支线，而且在你改动的前头。这样
: 保证历史是干净的，你的改动在最后面。推荐的做法就是经常rebase，通过code
: review之后，做一个squash然后merge到主线上。
: 如果你把主线merge到支线上, merge的部分就在你的修改后面了。这之后你发现你错了
: 想把你的revert，就做不了。
|
q*c
发帖数: 9453 | 12 i use it All. the time.
otjerwise it is incredibly dirty when local and remote both commit
frequantly.
【在 t**r 的大作中提到】
: don't ever use rebase.
|
d********t
发帖数: 9628 | 13 为啥不好
【在 c*********e 的大作中提到】
: right. rebase是把你的branch并入master,这是不好的。
|
d********t
发帖数: 9628 | 14 也可以主线并入质线啊
【在 c*********e 的大作中提到】
: 对呀，就是并入主线，成了base,不再是个分支。
|
a******n
发帖数: 5925 | 15 Rebase 把时间顺序理顺了
Merge 不管这个
多人用的repo rebase一下比较好
因为别人可能也有commit
但注意不要在public branch (比如master)上rebase
楼主可能是自己一个repo 在玩吧？
你试试多建几个用户，把时间顺序打乱都commit一些东西
[在 convergence (Rex) 的大作中提到：]
：merge的效果是一样的啊。
：
：........... |
d********t
发帖数: 9628 | 16 对啊我是一个人搞了两个branch在玩哈哈
【在 a******n 的大作中提到】
: Rebase 把时间顺序理顺了
: Merge 不管这个
: 多人用的repo rebase一下比较好
: 因为别人可能也有commit
: 但注意不要在public branch (比如master)上rebase
: 楼主可能是自己一个repo 在玩吧？
: 你试试多建几个用户，把时间顺序打乱都commit一些东西
: [在 convergence (Rex) 的大作中提到：]
: ：merge的效果是一样的啊。
: ：
|
a******n
发帖数: 5925 | |
t*****n
发帖数: 4908 | 18 rebase会改变sha1 id，merge不会。
比如公司的软件1.0发布了。有bug，需要打补丁。所以在1.0 release branch的基础上
，建立一个"bug_fix"branch。这样的好处是master branch还在继续开发过程中。同时
可以在master branch的基础上，自建一个feature branch，玩玩各种新玩具。
现在bug修复了。补丁也给客户了。接下来就可以把bug_fix merge到master。这样的好
处是同一commit，在bug_fix和master下都是同一sha1 id。如果你用git blame，sha1
id就很重要。当然也可以merge到feature branch。
在feature branch上的东西，只是自己工作。当master有新的commit，可以用git
rebase。这样自己的工作总是在最上面。同时可以融入别人的工作，并减少以后遇到
merge conflict的机会。 |
t*****n
发帖数: 4908 | 19 开100个都无所谓。看你怎么用。基本一个bug就对应一个branch。
【在 d********t 的大作中提到】
: 对啊我是一个人搞了两个branch在玩哈哈
|
d********t
发帖数: 9628 | |
|
|
d********t
发帖数: 9628 | 21 啥叫sha1id
sha1
【在 t*****n 的大作中提到】
: rebase会改变sha1 id，merge不会。
: 比如公司的软件1.0发布了。有bug，需要打补丁。所以在1.0 release branch的基础上
: ，建立一个"bug_fix"branch。这样的好处是master branch还在继续开发过程中。同时
: 可以在master branch的基础上，自建一个feature branch，玩玩各种新玩具。
: 现在bug修复了。补丁也给客户了。接下来就可以把bug_fix merge到master。这样的好
: 处是同一commit，在bug_fix和master下都是同一sha1 id。如果你用git blame，sha1
: id就很重要。当然也可以merge到feature branch。
: 在feature branch上的东西，只是自己工作。当master有新的commit，可以用git
: rebase。这样自己的工作总是在最上面。同时可以融入别人的工作，并减少以后遇到
: merge conflict的机会。
|
a9
发帖数: 21638 | 22 re
我一般是在push到remote前，rebase搞搞，比如调调顺序，有时候一个修改中间为了保
存进度，在提交工作前rebase一下，把他们合并成一个等。
还有提交到远程的时候，rebase一下远程。这样修改在最上面，省得以后合并不容易。
sha1
【在 t*****n 的大作中提到】
: rebase会改变sha1 id，merge不会。
: 比如公司的软件1.0发布了。有bug，需要打补丁。所以在1.0 release branch的基础上
: ，建立一个"bug_fix"branch。这样的好处是master branch还在继续开发过程中。同时
: 可以在master branch的基础上，自建一个feature branch，玩玩各种新玩具。
: 现在bug修复了。补丁也给客户了。接下来就可以把bug_fix merge到master。这样的好
: 处是同一commit，在bug_fix和master下都是同一sha1 id。如果你用git blame，sha1
: id就很重要。当然也可以merge到feature branch。
: 在feature branch上的东西，只是自己工作。当master有新的commit，可以用git
: rebase。这样自己的工作总是在最上面。同时可以融入别人的工作，并减少以后遇到
: merge conflict的机会。
|
a9
发帖数: 21638 | 23 就是commit id
础上
同时
的好
【在 d********t 的大作中提到】
: 啥叫sha1id
:
: sha1
|
r***y
发帖数: 4379 | 24 要多于一个用户你才能看出rebase和merge区别
【在 d********t 的大作中提到】
: 对啊我是一个人搞了两个branch在玩哈哈
|
d********t
发帖数: 9628 | 25 为啥啊
【在 r***y 的大作中提到】
: 要多于一个用户你才能看出rebase和merge区别
|
s**d
发帖数: 258 | 26 rebase 是能将分支的修改历史完整的插入到主线
【在 d********t 的大作中提到】
: 看tutorial好像说rebase的话回重整history，不过我试了试根merge没任何不同啊。
|
s**d
发帖数: 258 | 27 rebase 并不是为了保证合并更容易，而是使修改历史更线性
【在 a9 的大作中提到】
: re
: 我一般是在push到remote前，rebase搞搞，比如调调顺序，有时候一个修改中间为了保
: 存进度，在提交工作前rebase一下，把他们合并成一个等。
: 还有提交到远程的时候，rebase一下远程。这样修改在最上面，省得以后合并不容易。
:
: sha1
|
a****i
发帖数: 1182 | 28 rebase和merge完全不是一个概念啊
A---B---C topic
/
D---E---F---G master
rebase以后变成了
A'--B'--C' topic
/
D---E---F---G master
base就是master上的最最后的push，没merge什么事
【在 d********t 的大作中提到】
: 看tutorial好像说rebase的话回重整history，不过我试了试根merge没任何不同啊。
|
c*********e
发帖数: 16335 | 29 rebase后应该是变成这样
D---E---F---G---A'---B'---C' master
【在 a****i 的大作中提到】
: rebase和merge完全不是一个概念啊
: A---B---C topic
: /
: D---E---F---G master
: rebase以后变成了
: A'--B'--C' topic
: /
: D---E---F---G master
: base就是master上的最最后的push，没merge什么事
|
a****i
发帖数: 1182 | 30 不会，A'---B'---C'还是在另外的branch，没有在master上
【在 c*********e 的大作中提到】
: rebase后应该是变成这样
:
:
: D---E---F---G---A'---B'---C' master
|
|
|
W*********y
发帖数: 481 | 31 re
sha1
【在 t*****n 的大作中提到】
: rebase会改变sha1 id，merge不会。
: 比如公司的软件1.0发布了。有bug，需要打补丁。所以在1.0 release branch的基础上
: ，建立一个"bug_fix"branch。这样的好处是master branch还在继续开发过程中。同时
: 可以在master branch的基础上，自建一个feature branch，玩玩各种新玩具。
: 现在bug修复了。补丁也给客户了。接下来就可以把bug_fix merge到master。这样的好
: 处是同一commit，在bug_fix和master下都是同一sha1 id。如果你用git blame，sha1
: id就很重要。当然也可以merge到feature branch。
: 在feature branch上的东西，只是自己工作。当master有新的commit，可以用git
: rebase。这样自己的工作总是在最上面。同时可以融入别人的工作，并减少以后遇到
: merge conflict的机会。
|
