关于 git 和 git workflow 的几个疑点请教下大家

[unco020511]

迫于目前团队 git 使用不是很规范,故有几个疑问想请教下

1. merge 和 rebase 有什么区别,实际使用中更推荐使用哪一个,为什么

2. 实际使用中应该使用哪种 workflow,好像 github/gitlab/git folw 这几种有不小的差异

3. github 的 pull request 其实就是 git 自带的 merge 或者 rebase 吗,为啥叫 pull request,这个好难理解

   • 延伸出问题 6

4. commit 的颗粒度如何把握,每个 commit 都应该保证代码能编译和 run 吗?还是只需要保证每一个 pr 能正常编译和 run 就行

5. 功能分支合并后应该立马删除吗,还是应该定期删除,又或者永久保留

6. 实际 git 工作流中,pull request 这个流程是必须的吗,直接 git 自带的 merge 不行吗

7. 最后,有没有推荐的 git 和 git workfow 相关的文档,最好是中文的,可视化的更佳

先谢谢大家了

[jinx930621]

先扔一个可视化 git 教程的链接在这 https://learngitbranching.js.org/?locale=zh_CN
我们现在在用的是 gitlab，gitlab 上就直接叫 merge request

[xlui]

1. 推荐 merge，rebase 会改写 commit 历史，导致所有合作者都需要处理冲突。
3. GitHub 的 PR 有多种形式，可以直接 merge，也可以把 PR 中所有的 commit 都 squash 为一个 commit 。
4. 个人习惯一个功能点一个 commit 。
5. 个人习惯合并后删除，因为合并后分支跟 master 已经没区别了。
6. PR 是必须的，master 分支禁止直接 push 。因为 master 要保证始终是稳定的。同时 PR 也会要求其他人去 review 你写的代码，对代码质量做一定的保障（虽然实际上大多数人不会去细看）。

[zdt3476]

仅供参考
首先是大致分为 release 线、dev 线、feature 线
1. feature 开发过程中，需要用到 dev 合入的其他线的代码，推荐 rebase 到当前的 feature 。当前 feature 要合入 dev 的时候用 merge
2. 这个没研究过
3. 我们项目用的 gitlab，然后是 merge request，和 github 的 pull request 应该没啥区别
4. commit 按我的习惯是，保证能编译能 run，然后粒度尽量细一点，这个需要自己把握
5. 功能分支我都是 git branch 觉得显示太多了，就回去删
6. 我们反正 feature 合入 dev 都是 merge request

[floyda]

## 1. merge 和 rebase 有什么区别,实际使用中更推荐使用哪一个,为什么

> 推荐使用 merge, 虽然容易冲突, 但是安全; rebase 虽然让分支树好看, 但是在断开与 Parent 的连接, 这个很危险

## 2. 实际使用中应该使用哪种 workflow,好像 github/gitlab/git folw 这几种有不小的差异

> 根据团队人数, 合作方式, 自己选择. 没有最好的, 只有最合适的.

## 3. github 的 pull request 其实就是 git 自带的 merge 或者 rebase 吗,为啥叫 pull request,这个好难理解

> 2 个不同的仓库, 请求你从我的仓库, pull 某些 commit

## 4. commit 的颗粒度如何把握,每个 commit 都应该保证代码能编译和 run 吗?还是只需要保证每一个 pr 能正常编译和 run 就行

> 建议使用 feature 分支, commit 的颗粒度无所谓, 包括提交信息都可以随意. finish feature 的是时候保证通过测试即可.

## 5. 功能分支合并后应该立马删除吗,还是应该定期删除,又或者永久保留

> 使用`git flow`, 会自动帮你处理.

## 6. 实际 git 工作流中,pull request 这个流程是必须的吗,直接 git 自带的 merge 不行吗

> 看团队的负责人是否想去做这个工作了.

## 7. 最后,有没有推荐的 git 和 git workfow 相关的文档,最好是中文的,可视化的更佳

> 推荐使用 `Sublime Merge`, 欢迎进群(不知道能不能放群号)

[floyda]

1. 推荐使用 merge, 虽然容易冲突, 但是安全; rebase 虽然让分支树好看, 但是在断开与 Parent 的连接, 这个很危险
2. 根据团队人数, 合作方式, 自己选择. 没有最好的, 只有最合适的.
3. 2 个不同的仓库, 请求你从我的仓库, pull 某些 commit
4. 建议使用 feature 分支, commit 的颗粒度无所谓, 包括提交信息都可以随意. finish feature 的是时候保证通过测试即可.
5. 使用`git flow`, 会自动帮你处理.
6. 看团队的负责人是否想去做这个工作了.
7. 推荐使用 `Sublime Merge`, 欢迎进群(不知道能不能放群号)

恢复居然不支持 Markdown

[Rwing]

我针对 1 发表一下个人意见，其他的都和大家差不多。
merge 和 rebase 要分情况使用：
如果是从一个分支合并到另一个分支，要表达强烈的“合并”的意图，那么 merge 。
如果仅仅是从远端拉代码，要同步到当前的进度，并不是真的想“合并”，用 rebase 。

[unco020511]

@floyda 感谢解答

pull request 应该叫 push request 或者 merge request 是不是更直观一些呢,就好像我发现了你的一些 bug 并帮你修复了,我想向你的仓库(或者分支)push 一些最新的 bugfix 代码

[unco020511]

@jinx930621 谢谢,宝藏网站,不过这个网站我之前就学习过

[unco020511]

@xlui 一般 pr 这个动作是 feature 分支合并到 dev 吧,dev 合并到 master 是专人维护

[unco020511]

@Rwing 明白了,你和三楼说的一样

[SingeeKing]

commit 可以随便 commit，pr 之前把共性的 rebase 掉

[floyda]

@unco020511

Q: 432333235
欢迎讨论 Sublime Merge 的使用

[xlui]

@unco020511 #9 经验之谈，实际执行的时候都是直接从 feature 往 master 合，并没有专人维护 dev 分支。

当然开源项目按这个流程没问题。

[yeqizhang]

@Rwing 赞同啊，我就同步一下代码，不用 pull rebase 搞的时间轴很难看的

[yeqizhang]

@unco020511 他跟三楼说的不一样，他说的分支之间合并都用 merge，同步远程仓库代码 rebase

[otakustay]

PR 为什么叫 pull request：我请求（ request ）代码的负责人来拉（ pull ）我的代码到主干

[ryougifujino]

抽几条回答一下

1. 首先如果是一个私人分支的话，你要同步 master 的代码，这时候用 rebase 其实是最好的，因为不像 merge 可能会产生一个 merge commit，可以一定程度上保持提交历史的简洁。
如果是你的分支（假如 feature 分支）开发完毕了，想合入主分支，这时候用 merge 比较好，因为可以保留你的分支痕迹（--no-ff ）。但是有很多著名的开源项目合入主分支时也是用的 rebase （比如 angular ），这样主分支就是一条直线，很简洁。

3. 说到 pull request，直译过来就是拉取请求，这个怎么理解呢，就要说起在 GitHub 上的协助方式。在 GitHub 上有一个开源项目，它可能会收到来自其他人成千上万的贡献，如果大家都提交到一个 repo 的话，就可能会很混乱。所以非 member 的开发者是对主仓库没有提交权限的。这时候怎么做贡献呢？就要 fork 一份主仓库，这个 fork 的仓库是完全属于你的，你可以随意提交。当你想把你的提交贡献给主仓库时，就可以发起一个 pr （拉取请求，即“主仓库 member 拉取你代码的请求”）。然后主仓库的 member 拉取了你的代码 review 后决定要不要并入主干。所以 pr 机制就保证了，既可以保持主仓库的整洁，又可以方便的接受别人的贡献。

[msg7086]

1. Merge 会产生一个 Merge 节点，而 Rebase 会改变历史。实际使用中，该 Merge 的时候用 Merge，该 Rebase 的时候用 Rebase 。就我个人意见，一味 Merge 和一味 Rebase 都是错误的行为。
2. 几种 Workflow 其实都大同小异，本质上是一样的，在自己的小世界里随意玩耍，折腾完了再拿出去给别人看。然后还有一个 Release branch 。
3. Pull request 或者 Merge request 是拿来 code review 的过程。PR 是开源软件中用的，因为人与人之间互为不信任，所以每个人在自己的 Repo 里工作，跨 Repo 合并的过程就是请别人从你这里 Pull 。MR 一般是企业开发用得多，因为人与人之间互信，所以大家都在同一个 Repo 里工作，Repo 内合并就是 MR 了。本质上原理相同。
4. Commit 的粒度随意，只要发 PR/MR 之前把分支整理干净就可以了。
5. 合并时删除。
6. 如果没有人 Code review，那当然自己 Merge 就行了。有 Code review 就先提 PR/MR，等 approval 和 CI，然后再合并。

[msg7086]

关于 Merge 和 Rebase 的使用时机，原则上：
从主干更新代码到分支，用 Rebase，把分支 Rebase 到主干 HEAD 上；
从分支更新代码到主干，用 Merge，先按上一条 Rebase 后，再把分支 Merge 回主干。Merge 时可以附上这个分支所实现的功能，或者修复的 Bug 编号，或者完成的 Jira 编号等等。

[unco020511]

@ryougifujino 谢谢,说的很详细,基于此我的理解:其实 pr 已经脱离标准的 git 流程了,属于团队外协作,因为 pr 是仓库(repo)与仓库之间的合并.那么实际公司团队开发中,应该不存在 fork 这个操作吧,都是基于同一个 repo 的不同分支的,那当我们从 feature 合并到 dev 的时候,也会涉及 pull request 吗,这个 pr 和 repo 之间的 pr 又有什么区别呢