关于 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 相关的文档,最好是中文的,可视化的更佳

先谢谢大家了

[unco020511]

@msg7086 谢谢,关于 pr 的回答感觉你这个是最好的,我之前一直会混淆 pr(repo 间协作)和 mr(repo 内协作),这样区分就很清晰了,开源项目与企业项目的协作方式是不同的,不能一概而论

[unco020511]

@msg7086 18# 但我去看了 github 和 gitlab 的文档,在 github 中,branch 间发起合并也叫 pull request,在 gitlab 中,repo 间发起合并也叫 merge request,看来只是名字不一样.只不过 github 多用于开源项目协作,gitlab 多用于私有部署,所以命名会不太一样?

[ryougifujino]

@unco020511 #20 首先你可以参考下这个链接，对 pr 有详细解释 https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests

pr 和 mr 其实是完全一样的，它们可以发生在不同的 repo，也可以发生在同一个 repo 。
在同一个 repo 时，需要指定 pr 的源分支和目标分支（必须是不同的分支）。
在不同的 repo 时可以分支的对应可以任意。比如我们要像一个开源项目提 pr 时，除了默认的 origin 指向我们 fork 的仓库，还需要一个 upstream （上游）指向主仓库。这时候我提一个 pr，就可以这样对应分支：origin/master （源）——>upstream/master （目标）。

[msg7086]

@unco020511 功能本质上是一样的，就是叫法不同，因为起源不同。
确实就是如你所说，GitHub 是社交网站性质更多，而 GitLab 是企业用更多，所以风格不太一样。

[ryougifujino]

@unco020511 #20 说 pr 脱离了 git 流程其实不太准确，因为所谓的“git 流程”其实指的就是 git 工作流。git 工作流有很多种，涉及到 pr 的叫 GitHub flow，涉及到 mr 的是 GitLab flow，它们都是 git 工作流的一种。在实际公司的开发者，也可能会 fork，也可能没有，这主要是由公司使用哪种 git flow 决定的。

[unco020511]

@ryougifujino
@msg7086 现在我完全弄明白了,谢谢

[miyuki]

其实是 request 对方去 pull 你的代码🐶

[LuckyLight]

1. 本地分支拉取当前分支最新代码，使用 rebase
本地分支拉取主干分支最新代码，使用 rebase
本地分支合并到主干分支，使用 merge
4. 细粒度 commit，防止多人开发时冲突太多
5. 一般合并到主干分支上线打 tag 之后，可以立即删除

[icylogic]

两个 rebase 适用场景：
你的 private branch 在准备提交 pr 前，用 rebase -i 整理好，为 merge 提供一个干净清晰的历史。
你在 local branch 上工作，然后主分支有了更新，你需要这些更新或者有了冲突需要解决，你可以选择 rebase 到最新主分支上。

rebase 会改变历史，而 git repo 里需要遵守的是“不要修改公开历史”，rebase 就是给非公开历史准备的工具。

可以看看 Linus on git rebase and merge:
https://www.mail-archive.com/[e-mail]/msg39091.html

[icylogic]

People can (and probably should) rebase their _private_ trees (their own
work). That's a _cleanup_. But never other peoples code. That's a "destroy
history"

[wisetc]

没有推之前放肆 rebase，推了之后 rebase 会和远程冲突，而冲突其实就是 commit 历史不一致，而远程往往是公用的，至少是两个端，两个以上就容易冲突。用 merge 以示尊重，不要随便变更他人的分支。