有没有办法一条命令可以快速 rebase？

[leonlh]

项目用 git 做版本管理，同步代码的时候用的是 git pull --rebase 来保证分支的整洁

然而 rebase 时如果当前有未提交的代码， git 会提示： Cannot rebase: You have unstaged changes.

所以我的操作流程是这样的：

1. git stash
2. git pull --rebase
3. (有冲突解决冲突，然后 git rebase --continue)
4. git stash pop stash

pull 一个代码，竟然要这么多步骤，简直令人发指。。。 考虑过用 alias 写个命令把这几个命令都加进去，但是如果 rebase 的时候出现冲突就跪了 所以 V2 大神有没有好的方案，能够便捷的 rebase 代码...

[xAx]

当团队有那么两个 git 用的不熟的人瞎 rebase,整个团队都要疯

[clino]

@owt5008137 看法相反 尽量用 rebase 而不是 merge

[owt5008137]

@msg7086 分支管理不仅仅是指可以建多个分支，而是在存在多个分支的时候的一整套工作流。多分支之间的 merge 就是最重要的组成部分

[owt5008137]

@msg7086 @clino
最简单地就是，如果尽量要 rebase ，为什么不用 svn ？而且 svn 原生就能版本精确到文件，不像 git 得拉取整个仓库，而且 rebase 的过程还巨慢无比（特别是变更多跨版本多的时候）。
难道仅仅是为了切分支不用换目录？@leonlh 合作开发需要设置多个 remote 的话想用 git 还勉强说得过去，但是也不是非要 rebase 啊。正常的 merge 完全可以。新版的 tortoisegit 为了提高 rebase 的速度，即便你选了 rebase ，在可以的情况也是用 merge 的。

另外回答下楼主的问题：高版本的（忘了哪个版本开始有的） git 的配置里，可以设置 automerge 和 autostash

我们这里除了非程序人员不会用 git ，为了让 git 尽量表现得像 svn 才给他们开 rebase ，程序一律走正常工作流，包括对外接入的东西。只是因为很多人已经被 svn 养成了习惯，不懂 git 的概念，导致很容易错误得 merge 才 rebase 的

[clino]

@owt5008137 看了第一句就没兴趣看下去了 svn 不是同一个时代的相比起来功能差多了
而且我是说尽量用 rebase,但有时候还是会用 merge 特别是有多个 remote 的时候 svn 有这个能耐吗?

[thuai]

git alias 可以办到，多个 git 命令命一个别名

[msg7086]

@owt5008137 rebase 和 merge 的用途本来就不同，不管是该 merge 的时候 rebase ，还是该 rebase 的时候 merge ，都不太合适。
我不知道你是怎么得出「不要 rebase 」这种结论的。
svn 的分支切换和 git 的分支切换差得太远了，所以我更不知道你怎么得出「为什么不用 svn 」这种结论的。
至于为了让 git 表现得像 svn 才开 rebase ，我就呵呵了。
是不是贵司觉得 history 太单调了不好看所以让大家多玩玩 merge 把 history graph 搞复杂点才好啊。

[xAx]

@msg7086
history 是单调好还是复杂好，这个要看贵司是要求能从 history 里看出各种变更信息，还是只要能看明白改了什么就行。
用不用 rebase 是和管理需求有一定联系的。
---

难道各位的团队里就没那么几个傻叉？用个 rebase 害整个团队都要各种调记录的？

虽然不用 rebase 提交历史不好看一点，但整个团队协作没有风险

[owt5008137]

赞同 @xAx
@msg7086 我从来没说不要 rebase ，只是说尽量少用 rebase 。 history graph 里分支多有什么关系？ github 上分支多的开源项目多了去了。你看有几个 PR 会用 rebase 的？而且特别是性能问题，只有当你碰上复杂的多端合作开发，测试完成后一次 push 要合并很多 commit ，并且里面包含资源，你才能感受到 rebase 的局限性在哪

[6v]

@leonlh 我一般是 commit 一个临时提交，然后之后开发再 commit --amend 就行。我觉得这样不影响 rebase 的节奏，比 stash 方便一丢丢。

[owt5008137]

@clino 所以我的回答里已经说了，每次拉取 rebase ，和 svn 相比优势也就剩下多分支了。缺点倒是多得一坨。

所谓 git 和 svn 的先进性相比，不是因为 git 比 svn 发明得晚，也不是它是 linus 发明的。而是它的工作方式和理念能解决实际的问题，这些实际的问题里，多分支 merge 是个比重比较高的点。只是多个 remote 的话用 svn 也不是很难解决，只是麻烦一点而已。

现在，其实很多人已经习惯了 svn ，经常容易拿 svn 的模式套在 git 上，导致很难理解这些理念，并且容易误操作。我的理念是，如果这些容易产生的误操作带来的解决问题的时间已经大于用 git 替换 svn 所节省的时间。那何必用 git 。难道只是很多人说 git 先进？先进的 scm 多了去了，和 git 相近的就有 hg ，为什么不用？还有 p4 ，为什么不用？

[clino]

@owt5008137 没发现 git 有你说的那么多缺点 另外我最早先学的 hg,用了好一段时间还不得要领,再学 git 的时候很快就用得很好了,我为什么要用 hg? 何况 git 性能碾压 hg 更不要说 svn 了

[msg7086]

@xAx 我司的 Merge 乱的不行，要 Revert 或者 Blame 的时候蛋疼无比。
不过你说的没错，这主要是团队管理上的需求。

@owt5008137 GitHub 上 Rebase 上游才是标准做法吧？我倒是很少见到 PR 要 Merge update 的。
至于你提到 hg 我就觉得更好玩了。
我觉得 hg 最为人诟病的地方就是开分支有代价而且不能随便 Rebase 。
我之前维护 hg 版的 x265 mod ，需要自己维护一个补丁串，最后只能在 bitbucket 上开一个 Patch series 项目，每次上游更新了，本地就要弹出所有补丁， update 到 tip ，然后再把补丁一个一个打回去，打出问题了还要被 mq 恶心一通然后去处理合并冲突。然后每一个想 fork 和想贡献代码的人都跑来问我这货到底要怎么用在官方 repo 上，要怎么 fork ，要怎么 pr 。
我很想知道你用 hg 的时候是怎么解决这些问题的。
反正我是醉得不行，维护了几个月实在受不了了，老老实实切到他家的 Git 镜像上开分支 Rebase 了。

最后上一张我司的 History 。三五人的小团队的项目。作为处女座我忍不了 Merge 。然而 YMMV 。

[owt5008137]

@clino 按你们喜欢的方式来吧。本来这些个功能就是针对不同场景提供的。我不建议 rebase 是因为我以前也是默认开 rebase 的，但是碰到好几次一个 commit 要 rebase 好几次，而且 commit 数量稍微多一点就要我等好久，再加上碰到过好几次相同类型的冲突要解决好几次。不甚其烦，自从去掉 rebase 以后天下太平。而且如果不 rebase 首先就没有了 @leonlh 提的这个问题。只是个人建议而已。

@msg7086 我说的很多人不理解 git 工作流的理念的结果就是你说的很多人“跑来问我这货到底要怎么用”。所以我才说默认开 rebase 是妥协的结果。其他的不想浪费时间争论了，用你喜欢的方式吧，最顺手的才是最高效的。随便贴一个 github 上的项目的图吧。

[clino]

@owt5008137 我们内部用的是 gerrit, 确实有 code review 过程当中又有别人的提交先合入,此时 gerrit 默认的行为是 merge 的,当然如果历史差太多 gerrit 会出 path conflict 错误强制你 rebase, 当然 web 界面上也有 rebase 按钮可以直接 rebase
在用 gerrit 的情况下习惯 rebase 并不会带来多少负担
即使在 github 上,如果别人给你提交了 pr,一般你也会希望他 rebase 到最新的上面修改这样比较清楚利于 review 所以我要是给别人提交 pr 我的习惯是一定 rebase 到最新的再提,这样对别人比较友好

[owt5008137]

@clino 我刚刚看了一下是有些项目用 rebase 合并 PR 的，但是自动的是没有 rebase 的。考虑到 code review 的话可能 rebase 的确会让分支看起来简单一些吧。其实比如上面我发的那个图， code review 的时候只看“与第 2 个父节点比较差异”的部分就可以了。因为“与第 1 个父节点比较差异”的内容是之前 review 过的（当然前提是如果每次 merge 都被 review 过）。不过我猜 gerrit 会强制你 rebase 可能是为了减少分支数。

[clino]

@owt5008137 我之前说了 gerrit 默认的方式是 merge 只有新 patch 基于的版本实在太旧才会出 path conflict

[msg7086]

@owt5008137
1. 你这张图里我只看到一个 Merge 。
2. 冲突要解决很多次所以才选择 Merge 听上去像是为了偷懒而选择 Merge 一样？

[hantsy]

rebase 太太痛苦了。。。 conflict 会特别多。

我们项目只会用 Github Flow ，用 Merge 合并，保留每个 Branch 真实开发 line ， rebase 完全将提交重排了。

[hantsy]

@clino 其实用 Github ， 经常同步 master 到 fork 中的 branch, 几乎不会有冲突产生，如果直接 Git rebase ， commit 次数太多的话， 10 次 8 次会产生冲突。