如何避免 git 提交记录拧成麻花？

Question

感觉这样的提交记录让人看的头晕，这是好事还是坏事呢？我觉得不太好，看着很花，但是我们每天就是有很多人提 commit 做功能，怎么办？

优雅的提交记录管理和分支管理是什么样子的？

Answer 1

首先，非常肯定的告诉你，你这个git log没有任何问题，这就是正常的迭代历史。

git合并一共有两种方式，一种是merge,一种是rebase,你提出这个问题，是想要保持线性的提交历史，这种只有rebase能做到，但是从你现在的提交历史上看，提交非常频繁，这就是矛盾的，因为rebase能保持线性提交历史，但是频繁的提交会带来频繁的变基和重写git commitId，需要团队每个人深度理解rebase,减少commit的次数才行。

综上，还是merge更适合你们团队,但是呢你们团队可以做内部培训，规范一下大家的git操作，减少多人同时多分支开发的可能性，大概有以下措施：

1. 尚未push到公共分支之前，多次提交合并,减少提交次数，使用git commit --amend -m 'xxx'
2. 新建分支之前，确认变更基线，不要从过早的基线开始变更，小修小改的情况下，直接复制提交即可，尤其是hotfix场景，使用git cherry-pick commitId
3. 提交代码（commit）前，先从远程拉取拉取最新修改，再进行commit
4. 远程推送（push）代码前，可以将自己的提交变基到已有提交之后再推送,减去merge request的产生，使用git pull --rebase
5. merge操作尽量快进式合并，减少merge request的产生，使用git merge -ff

Answer 2

更新代码的几种方式

//拉取远程代码与本地分支合并,实际是fetch+merge
git pull

//会把远程仓库所有的更新拉取下来,不会合并
git fetch

// 可以确保生产分支commit是一个线性结构，方便rollback。其实生产也可以选择打tag来发布
// 注：通过rebase可以确保主分支commit history线性结构上每个commit点都是相对独立完整的功能单元。除了美感，这样做也有助于团队间的分工协作，比随便merge效果好。
git rebase

// 1、把本地 repo. 从上次 pull 之后的变更暂存 2、恢复到上次 pull 时的状态 3、.合并远端的变更到本地  4、最后再合并刚刚暂存下來的本地变更
git pull --rebase（推荐用这个）

# 确保工作目录干净
git stash

# 拉取远程代码并尝试 rebase
git pull --rebase origin main

# 如果遇到冲突，解决冲突后继续 rebase
git add .
git rebase --continue

# 完成 rebase 后，推送更改到远程仓库
git push origin main

# 如果之前保存了更改，现在恢复它们
git stash pop

Answer 3

理论上是可以避免的。假设从 A 分支创建 B 分支，A 就是 B 的上游。那么考虑下面三个原则：

1. B 分支不从除了 A 分支之外的其他分支合并内容。任何需要合并到 B 分支的，必须先合并到 A 分支。同理，B 的下游分支也只从 B 分支合并内容。
2. B 分支每次从 A 分支合并内容，都用 rebase。同理，B 的下游分支也用 rebase 来合并 B 分支的内容。
3. 仅当 B 分支没有子分支，或所有子分支都合并回 B 分支时，才能将 B 合并回 A 分支。

做到这三点，git 分支图绝对漂亮。难就难在没有哪个团队能做得到。

Answer 4

这个必须通过管理方式解决，而不是技术方式。

可以规定团队开发规范必须使用git pull --rebase拉取代码，对于基线代码要求必须rebase提交，这样分支树就是直直的一条

Answer 5

看了上面的各位回答，总结下就是约定规范。
定期拉取、提交前拉取，最后统一合并制定一个简单的流程才能达到你说的那种好看。