- 前言
- Githug 安装和使用方法
- 关卡列表
- 第 1 关 init
- 第 2 关 config
- 第 3 关 add
- 第 4 关 commit
- 第 5 关 clone
- 第 6 关 clone_to_folder
- 第 7 关 ignore
- 第 8 关 include
- 第 9 关 status
- 第 10 关 number_of_files_committed
- 第 11 关 rm
- 第 12 关 rm_cached
- 第 13 关 stash
- 第 14 关 rename
- 第 15 关 restructure
- 第 16 关 log
- 第 17 关 tag
- 第 18 关 push_tags
- 第 19 关 commit_amend
- 第 20 关 commit_in_future
- 第 21 关 reset
- 第 22 关 reset_soft
- 第 23 关 checkout_file
- 第 24 关 remote
- 第 25 关 remote_url
- 第 26 关 pull
- 第 27 关 remote_add
- 第 28 关 push
- 第 29 关 diff
- 第 30 关 blame
- 第 31 关 branch
- 第 32 关 checkout
- 第 33 关 checkout_tag
- 第 34 关 checkout_tag_over_branch
- 第 35 关 branch_at
- 第 36 关 delete_branch
- 第 37 关 push_branch
- 第 38 关 merge
- 第 39 关 fetch
- 第 40 关 rebase
- 第 41 关 repack
- 第 42 关 cherry-pick
- 第 43 关 grep
- 第 44 关 rename_commit
- 第 45 关 squash
- 第 46 关 merge_squash
- 第 47 关 reorder
- 第 48 关 bisect
- 第 49 关 stage_lines
- 第 50 关 find_old_branch
- 第 51 关 revert
- 第 52 关 restore
- 第 53 关 conflict
- 第 54 关 submodule
- 第 55 关 contribute
- 附录 A Git 学习资源
- 附录 B Linux 常用命令
- 附录 C Vim 常用命令
第 40 关 rebase
We are using a git rebase workflow and the feature branch is ready to go into master. Let's rebase the feature branch onto our master branch.
我们使用了 git rebase 工作流,feature 分支准备合并到 master。rebase 这个 feature 分支到我们的 master 分支之上。
在第 28 关我们曾经使用过一次 git rebase
命令,现在我们再详细讲解一下。
git rebase
和 git merge
都是用来合并,各有优缺点,所以有些团队会约定合并时只能用 git merge
或只能用 git rebase
,如果约定只能用 git rebase
来合并,这种工作方式就被称为 'git rebase 工作流'。在用 git rebase
合并分支时,合并后的日志并非按各分支的提交时间排列,而是把一个分支的日志全部排列在另一个分支的日志之上,即使它们是并行开发的,在开发过程中交错提交,但看起来也好像是按先后顺序开发的一样。
以本题为例,master 是主线,从 master 创建出 feature 分支,此后,master 提交了一次,提交说明是 “add content”,feature 也提交了一次,提交说明是 “add feature”,这时在 master 上执行以下命令:
$ git rebase feature
那么 master 的日志就会变成 "add content" 在 "add feature" 之上。
而反过来,如果是在 feature 上执行以下命令:
$ git rebase master
那么 feature 的日志就会变成 "add feature" 在 "add content" 之上。
第 40 关过关画面如下:
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论