Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: cloudyan/learn-git
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: master
Choose a base ref
...
head repository: cloudyan/learn-git
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: dev
Choose a head ref

There isn’t anything to compare.

master and dev are entirely different commit histories.

Showing with 17 additions and 0 deletions.
  1. +1 −0 docs/git-branch.md
  2. +2 −0 docs/git-workflow.md
  3. +4 −0 docs/readme.md
  4. +10 −0 docs/rebase-vs-merge.md
1 change: 1 addition & 0 deletions docs/git-branch.md
Original file line number Diff line number Diff line change
@@ -5,3 +5,4 @@
参考：

- https://www.ruanyifeng.com/blog/2012/07/git.html
- https://nvie.com/posts/a-successful-git-branching-model/
2 changes: 2 additions & 0 deletions docs/git-workflow.md
Original file line number Diff line number Diff line change
@@ -13,6 +13,7 @@ Git 作为一个源码管理系统，不可避免涉及到多人协作。
下面是三种广泛使用的工作流程：

- 最早诞生、并得到广泛采用的一种工作流程，就是 [Git flow](https://nvie.com/posts/a-successful-git-branching-model/)。
- 此文作者 2020-03-05 反思时，提到推荐使用更简单的工作流程 [GitHub flow](https://guides.github.com/introduction/flow/)
- Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支，非常烦人。
- 这个模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。
- 不适用于网站项目的"持续发布"，代码一有变动就部署一次。此时，master分支和develop分支的差别不大，没必要维护两个长期分支。
@@ -198,3 +199,4 @@ git | feature| -| start -| name
- [分布式-Git-分布式工作流程](https://git-scm.com/book/zh/v2/分布式-Git-分布式工作流程)
- [Git分支管理策略](http://www.ruanyifeng.com/blog/2012/07/git.html)
- [高效git工作流](https://juejin.im/post/5b2b76e251882574934c388d)
- [GitHub flow](https://guides.github.com/introduction/flow/)
4 changes: 4 additions & 0 deletions docs/readme.md
Original file line number Diff line number Diff line change
@@ -22,6 +22,10 @@
- [**强烈推荐**]中文版 [https://git-scm.com/book/zh/v2/](https://git-scm.com/book/zh/v2/)
- [Learn Version Control with Git](https://www.git-tower.com/learn/git/ebook/cn/command-line/introduction)

### gerrit

gerrit 用于审查和交付集成

Git详解教程列表：

更新下面的链接到官网中文版（2017-02-17）
10 changes: 10 additions & 0 deletions docs/rebase-vs-merge.md
Original file line number Diff line number Diff line change
@@ -10,7 +10,17 @@
建议先读一遍 [Git详解-目录](https://git-scm.com/book/zh/v2/)

- 什么时候我应该用 git merge?
- fast-forward 时
- 什么时候使用 git merge --no-ff
- 什么时候我应该使用 rebase?
- rebase 用于使历史记录中的分支路径更清晰，存储库结构是线性的
- 什么时候使用 rebase --onto?

rebase和merge之间的唯一区别是：

- 生成的历史树结构（通常只在查看提交图时才会显着）是不同的（一个将具有分支，另一个将不具有）。
- 合并通常会创建一个额外的提交（例如树中的节点）。
- 合并和rebase将以不同方式处理冲突。 Rebase将一次提交一个提交的冲突，其中merge将同时呈现它们。

## rebase黄金定律