g*****g
发帖数: 34805 | 1 rebase是你在支线上，别人的改动已经merge到了主线上，你在支线上做rebase就能把
别人的改动放入你的支线，而且在你改动的前头。这样
保证历史是干净的，你的改动在最后面。推荐的做法就是经常rebase，通过code
review之后，做一个squash然后merge到主线上。
如果你把主线merge到支线上, merge的部分就在你的修改后面了。这之后你发现你错了
想把你的revert，就做不了。 |
|
a******n
发帖数: 5925 | 2 Rebase 把时间顺序理顺了
Merge 不管这个
多人用的repo rebase一下比较好
因为别人可能也有commit
但注意不要在public branch (比如master)上rebase
楼主可能是自己一个repo 在玩吧？
你试试多建几个用户，把时间顺序打乱都commit一些东西
[在 convergence (Rex) 的大作中提到：]
：merge的效果是一样的啊。
：
：........... |
|
a9
发帖数: 21638 | 3 re
我一般是在push到remote前，rebase搞搞，比如调调顺序，有时候一个修改中间为了保
存进度，在提交工作前rebase一下，把他们合并成一个等。
还有提交到远程的时候，rebase一下远程。这样修改在最上面，省得以后合并不容易。
sha1 |
|
L***s
发帖数: 1148 | 4 我们这里（用github）的约定是：
在reviewer写第一条comment之前，推荐rebase支线onto主线；
一旦有了一条comment，就不允许rebase/squash了，只能merge主线into支线，
目的是保持整个review flow，方便reviewer看清楚你采取何种步骤
address他的comments。
关于merge之后的revert，只要diff出一个commit来就可以revert了。 |
|
|
t*****n
发帖数: 4908 | 6 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的机会。 |
|
a****i
发帖数: 1182 | 7 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
发帖数: 9628 | 8 看tutorial好像说rebase的话回重整history，不过我试了试根merge没任何不同啊。 |
|
c*********e
发帖数: 16335 | 9 rebase就是把它放到主线上，不再是branch.这个很少用。
一般是用merge. |
|
|
c*********e
发帖数: 16335 | 11 right. rebase是把你的branch并入master,这是不好的。 |
|
w**z
发帖数: 8232 | 12 每个公司规范不同，我们都是用rebase 的。 |
|
r***y
发帖数: 4379 | 13 要多于一个用户你才能看出rebase和merge区别 |
|
s**d
发帖数: 258 | 14 rebase 是能将分支的修改历史完整的插入到主线 |
|
s**d
发帖数: 258 | 15 rebase 并不是为了保证合并更容易，而是使修改历史更线性 |
|
c*********e
发帖数: 16335 | 16 rebase后应该是变成这样
D---E---F---G---A'---B'---C' master |
|
s***h
发帖数: 487 | 17 Rebase 确实不好用，我一般不 care 历史，不用 rebase。
: 破小公司啥毛病都有。俺现在work w/两个大陆，三个国家，四种版本控
制。GIT
都有三
: 种。完全相反的code style不说。三个不同domain的帐号。两台不同的编
程机器
/子网/
: 数据中心，因为无法打破防火墙。有些实在拿不到权限的让人帮忙偷。连
VP都不
知道算
: 不算侵权。毕竟在不同的国家。
: 歪楼了。Rebase这么好用就好了。不用俺一个merge request最多一次删
掉重新
创建
: commit branch 7次。赶火车就是这么惨。俩趟都没挤上去的都不是个事
。53的
老帮菜
: 说出来都是泪。63辣些直接就操娘了。现在连火车都开专列专刊分开挤了。
|
|
d********g
发帖数: 10550 | 18 fresh/entry level问git挂可以接受，experienced这就是基础知识
merge还是好的，他没问你rebase，还有啥时候merge啥时候rebase
merge相当于你当前branch和parent branch相交到一个点创建一个新的commit，如果两
条线有冲突就会在HEAD给你在文件里列出，手动解决后（也可自动解决，指定用哪一个
branch的，但一般手动更安全），重新add一下冲突文件然后再merge。这个merge会搞
出一个新的merge commit点，如果团队很多人一起开发会有大量无意义的merge log，
得分情况搞rebase。类似的还有--no-ff这个选项怎么用，为什么
这就是看你有没有正经的团队开发经验。要是用过git-flow这套流程，估计面试官得给
你跪了 |
|
k*******p
发帖数: 219 | 19 接触git很久了，入门的时候有点头大，用了这么久其实99%的时候用的以下的命令，
git commit --amend 把当前added 但没commit的内容贴到上个commit里
git rebase -i HEAD^ #N 这个是特别有用的命令，对当前N个commit进行Squash skip
edit等操作整合
git rebase --interactive #commit sha1 跳跃到以前的某个commit进行修改
git branch 创建local新的branch
git reset HEAD^ 这个我很喜欢， 就是把最当前的commit 解散
git checkout -b #remote branch name， checkout branch 到本地
git tag 每次release 最好tag起来以方便随后refer
git reflog 这个是最救命的命令。它显示所有commit过的记录，就算不小心删除了个
branch或者amend 或者rebase搞混乱了，照样可以从这个命令里找到以前的commit id
从而cherry pick 回来
gi... 阅读全帖 |
|
d*******s
发帖数: 65 | 20 1. git rebase --abort // discard whatever you have done in rebase
2. git update remote
3. git rebase origin/master // assume you are on master branch
4. git log
5. git revert |
|
w**z
发帖数: 8232 | 21 Make sure you understand
rebase vs merge
general rule is that
only rebase when you are on feature branch, never rebase when you are on
master |
|
e*******o
发帖数: 4654 | 22 https://www.youtube.com/watch?v=4XpnKHJAok8&feature=kp
大牛们别吵了。
回楼主，就几个命令学会了就行了。
git checkout -b branchname
commit, commit, commit...
git rebase -i HEAD~x x is commit times.
back to master
git pull
back to your brach
git rebase master
back to the master
git merge.
还能再简单？欢迎大牛们指点。（有时候会有conflict，麻烦一些，但这几个90% 的时
候够用） |
|
A*****i
发帖数: 3587 | 23 git rebase -i HEAD^ #N 这个是特别有用的命令，对当前N个commit进行Squash skip
edit等操作整合
对于这个我们一般不用rebase很容易出错，应为squash之后要和master force merge稍
有不慎就会把master毁了
我们的做法是
git reset
git stash
git merge --ff
git stash apply
git commit
git push -f |
|
i*****h
发帖数: 1534 | 24 已经push to remote了，看网上用git rebase -i 能删除，但是我自己试了一下结果不
一样
试了一下git rebase -i commit_id
然后看了下纪录，按视频上来看应该出现两条commits，但是现在出现很多 |
|
m******t
发帖数: 2416 | 25
Use 'git clone' to clone the repo.
For your local changes (assume you are on master):
$ git checkout -b local
Now you can make your local changes and commit them to
this new local branch. Also work on this branch all the time.
Now when you need to pull down new changes, do:
$ git fetch remote
$ git rebase remote/master master
$ git rebase master local
On the last step above you might have some conflicts
if your local changes involve the same files in the new
upstream changes. You'll need to r |
|
t****t
发帖数: 6806 | 26 you need to rebase your cygwin. google "cygwin rebase". it has nothing to do
with c++. |
|
m****a
发帖数: 2593 | 27 git 的命令行设计的一塌糊涂，简直就是业余的水平。
http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/
. Crazy command line syntax
The command line syntax is completely arbitrary and inconsistent. Some “
shortcuts” are graced with top level commands: “git pull” is exactly
equivalent to “git fetch” followed by “git merge”. But the shortcut for
“git branch” combined with “git checkout”? “git checkout -b”.
Specifying filenames completely changes the semantics of some commands (“
git commit” ignores local, unstag... 阅读全帖 |
|
|
发帖数: 1 | 29 lol
尼玛你这连revert rebase tag log 都没有 |
|
|
发帖数: 1 | 31 所难本性暴露了123457
: rebase，哈哈
|
|
s***h
发帖数: 487 | 32 悄悄地说，你就用 git rebase，不要用 git merge，谁也不知道你复杂的 merge 史。
: 俺们辣有位有洁癖的code reviewer一个merge的branch只允许有一次commit。历
史干净
: 。连德州来的PM都想拿枪毙了他。
|
|
发帖数: 1 | 33 破小公司啥毛病都有。俺现在work w/两个大陆，三个国家，四种版本控制。GIT都有三
种。完全相反的code style不说。三个不同domain的帐号。两台不同的编程机器/子网/
数据中心，因为无法打破防火墙。有些实在拿不到权限的让人帮忙偷。连VP都不知道算
不算侵权。毕竟在不同的国家。
歪楼了。Rebase这么好用就好了。不用俺一个merge request最多一次删掉重新创建
commit branch 7次。赶火车就是这么惨。俩趟都没挤上去的都不是个事。53的老帮菜
说出来都是泪。63辣些直接就操娘了。现在连火车都开专列专刊分开挤了。 |
|
c**u
发帖数: 14 | 34 【 以下文字转载自 USANews 讨论区 】
发信人: cimu (此木), 信区: USANews
标 题: Andrew Yang 的 UBI 确实很不错
发信站: BBS 未名空间站 (Thu Aug 1 12:35:11 2019, 美东)
其实是一个很理性的办法， 只是因为他没有强调增加税收而已， 他的办法是靠
value added tax, 好多国家都用。
这个办法其实很像 pure consumption based 的 tax system, it has a monthly
rebate as well, but not as much as Yang proposed.
basically:
1) get rid of IRS, no one need to pay any income taxes.
2) everyone pays 30% sales tax when you buy anything, that corresponding to
a flat 23% income tax
3) everyone get monthly reba... 阅读全帖 |
|
|
s******e
发帖数: 1751 | 36 有rebase的,jb不懂表瞎说。
先挣到1100万再说。 |
|
a*******e
发帖数: 181 | 37
建议拿 $1500 Rebase，然后自己找finance.
其实现在利率普遍很低，尤其象Credit Union，有的低到3.x% APR. |
|
l**********i
发帖数: 11748 | 38 你贴的这个是普通卤素灯泡的housing
HID的车灯有透镜的，透镜看起来就像一个大玻璃球嵌在车灯里
如果要装HID，要么rebase一下，要么DIY一下cutoff shield
不然你自己爽了，你前面的或者对面的车会非常不爽 |
|
b*******d
发帖数: 750 | 39 今天买了。
46700的MSRP，5400的off，
又有雇主公司的2500的rebase。
所以感觉还不错。GLK 350开着不错，推荐一下。 |
|
b*******d
发帖数: 750 | 40 今天买了。
46700的MSRP，5400的off，
又有雇主公司的2500的rebase。
所以感觉还不错。GLK 350开着不错，推荐一下。 |
|
b*******d
发帖数: 750 | 41 今天买了。
46700的MSRP，5400的off，
又有雇主公司的2500的rebase。
所以感觉还不错。GLK 350开着不错，推荐一下。 |
|
p********e
发帖数: 222 | 42 雇主的rebate是fleet吗？什么配置？是波士顿的dealer吗？谢谢。
今天买了。46700的MSRP，5400的off，又有雇主公司的2500的rebase。所以感觉还不错
。GLK 350开着不错，推荐一下。 |
|
W***o
发帖数: 6519 | 43 拿了它们的rebase，必须要从honda 贷，但是credit union的apr更好。
因为贷款的documents还没收到，所以想提前问问多久能refi ? |
|
k***a
发帖数: 1199 | 44 别瞎掰掰了,考数据并发访问/修改就直说就完了,问人git某个命令怎么用,纯粹扯淡
我们项目用git,perforce,用到的命令就几个,有冲突了,自己解决了提交,根本不会去用
rebase之类的高级用法,这玩意就是个工具,研究它做甚?大致原理,是个cs的都明白 |
|
d********g
发帖数: 10550 | 45 rebase是基础不是高级用法好吧……看你项目size，就几个人的小project可能没事，
你要上open source的，一群人不分青红皂白从upstream sync code的时候都merge会搞
死你的。正经项目都有严格coding style，这也勉强能算coding style的一种吧 |
|
d********g
发帖数: 10550 | 46 你没理解我的话。sync upstream code不是push是pull，要是本地有commit，merge会
产生一个废的commit，等你push回upstream的时候也许还有第二个废的commit。看你公
司代码库里有多少无意义的“Merge xxx”commit就知道了。这和解决冲突没有任何关
系，rebase设计就是用来干这个的，无脑merge那是没有人管coding style而已 |
|
d**********x
发帖数: 4083 | 47 re.
今天中午我还在跟老印侃这个。。。
我说这些搞软件工程的人需要rebase到2010年重新开始研究。。试图将软件工程化是好
的，但是他们研究的始点是上个世纪八九十年代，用来指导现在的生产问题太大。 |
|
d**********x
发帖数: 4083 | 48 re.
今天中午我还在跟老印侃这个。。。
我说这些搞软件工程的人需要rebase到2010年重新开始研究。。试图将软件工程化是好
的，但是他们研究的始点是上个世纪八九十年代，用来指导现在的生产问题太大。 |
|
s******c
发帖数: 1920 | 49 等code review的时候branching
review完了再rebase
git这个还是很方便的 |
|
