大家的 git log 看起来也是这么乱吗？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› Pro Git

› Atlassian Git Tutorial

› Pro Git 简体中文翻译

› GitX

这是一个创建于 3380 天前的主题，其中的信息可能已经有所发展或是发生改变。

最近在团队里面普及 GIt ，但是人比较多。感觉 git log 看起来有点乱

我们的 git log 看起来是这样

是不是应该是这样?

另外一个问题，合并冲突的 merge branch 应该 push 吗？

合并不是发生在本地吗，那自动 merge 需不需要被 push ？

27 条回复 • 2015-08-22 14:24:46 +08:00

lightening

2015-08-21 19:37:25 +08:00

你们的工作流程是怎么样的？有多少人？每个人是开自己的 branch 还是在 master 上工作？

cxq

2015-08-21 19:38:42 +08:00

@lightening 在 master 上工作的，每个人改完直接 push 上 master.

xiaket

2015-08-21 19:40:29 +08:00

要科普 rebase

ooxxcc

2015-08-21 19:41:00 +08:00

git merge --no-ff

lightening

2015-08-21 19:41:32 +08:00

@cxq 那如果没有冲突，图形看起来应该是很漂亮的直线。如果有冲突，可以： git pull --rebase
把自己开发的新功能 rebase 到最新的 master 上，然后再 push 上去，应该是一条直线。

cxq

2015-08-21 19:50:43 +08:00

@lightening 好的谢谢

wuming2015

2015-08-21 19:52:07 +08:00

假如有个分支叫 branch-new,在该分支完成后 git checkout master (切换到主分支)，然后在本地合并分支（ git merge branch-new ），就会自动合并了，遇到冲突不能自动合并的话，由每个程序员手动合并，合并后再 push 到远程仓库就可以了
至于合并冲突的 merge branch 和自动 merge 需不需要 push 要看你自己的情况而定了，合并冲突后，你本地代码库就是最新的啦，一般来说是在远程库之前的，如果需要，可以直接 push 上去的，也可以继续开发，只你你在开分支的时候已经 git pull 过就行

cxq

2015-08-21 19:54:22 +08:00

@lightening @xiaket rebase 我一直只知道用, 把某个我不想要的 commit 删除。或者 rebase master.但是不知道原理是什么一直。

zealot0630

2015-08-21 20:06:26 +08:00

随便贴一点

* f3bd2f1
|\
| * 63ca407
| * 3994ded
| * e193935
| * 1f0b882
| * e3806c0
* | fdd5ee1
* | cce0862
* | d6c944
|\ \
| |/
|/|
| * e9eed5b
| | * 79cfe4
| |/
|/|
* | f46b8c
|\ \
| * | e74f1f
* | | 739cdd
* | | e263
|\ \ \
| * | | 2b71
* | | | 45
|\ \ \ \
| * | | | 6e
| | |/ /
| |/| |
* | | | e2
|\ \ \ \
| |_|_|/
|/| | |
| * | | 3d1c
| |/ /
* | | efded6
* | | b48790
|/ /
* | 8f2dd1
|\ \
| * | ebcb48
* | | 3cd51e
|/ /
* | faa78a1
* | 73a731
|\ \
| * | a16531
* | | 1feb
|\ \ \
| |/ /
:

ljbha007

2015-08-21 20:27:01 +08:00

人多就专门一个人负责用服务器来 pull 其他人的代码然后合并

lightening

2015-08-21 21:48:20 +08:00

@cxq Rebase 就是把你每个 commit 的 diff 取出来，再一个个 patch 到新的 branch 上。
在你的情况下，就是把你在旧 master 上的 commit 一个个取 diff ，然后再一个个 patch 到新的 master 上。

cxq

2015-08-21 22:29:23 +08:00

@lightening 原来是这样，我之前这么手动做过，真是太傻啦现在想起来哈哈哈

yangmls

2015-08-21 22:39:12 +08:00

应该普及 git merge --squash git cherry-pick 和 git rebase 的用法。。。

huawuya

2015-08-21 22:46:29 +08:00

我们也刚换 Git ，比你这个还乱，解决方法就是 5 楼的 pull rebase ，打算等大家对 git 都比较熟了，再让他们用 rebase ，免得出问题。

kisnows

2015-08-21 22:48:34 +08:00

@cxq 每个人都直接到 master 上太恐怖了 ba

xavierchow

2015-08-21 23:50:50 +08:00

> 在 master 上工作的，每个人改完直接 push 上 master.

先不论这个工作流程需要改善的地方（利用分支，或者采用 pull request 等等），
并不是 git log 是线性的就是好的，这个是 case by case 的。

原则：
需要追踪或者保持历史上下文（ historical context ）的场合下，用 git merge,
反之，**可以**使用 git rebase 来清理 log 来保持线性整洁。
⚠：此处用“可以”而不是“必须”是因为使用 git rebase 有一个黄金原则：
由于 git rebase 改变了 branch 的 history ，永远不要在别的开发伙伴可以 fetch 或准备 fetch 的 branch 上作 rebase.

具体能使用 rebase 的场景有：
1.没 push 之前，你可以在你的 feature branch 上针对 master 作 rebase 以获取别人在 master 上的修改并保持你的历史整洁。
2.pull request 被 review 过后，决定要 merge 到 master 之前，可以通过 rebase 整理历史。（因为这个分支一旦被合并将会被删掉，不存在别的开发者再 fetch 它的情况）

参考：
http://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge
https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview
https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/

PS: 关于 rebase 的原理 http://git-scm.com/docs/git-rebase 已经讲的很清楚了，花点时间去看看，理解概念胜过硬记流程，磨刀不误砍柴功，不是么？

hilenlai

2015-08-21 23:57:22 +08:00

推荐 git flow https://github.com/nvie/gitflow

happywowwow

2015-08-22 00:02:27 +08:00

rebase -i squash 多个 commit 为一个 commit
然后 cherry-pick 到 dev 分支
测试过了再合并为一个 cherry-pick 到 master

leefly

2015-08-22 00:09:57 +08:00

团队协作开发你需要的是 Git FLow [A successful Git branching model]( http://nvie.com/posts/a-successful-git-branching-model/)

cxq

2015-08-22 01:35:28 +08:00

@leefly @hilenlai 谢谢，之前都是两三个人用，没什么感觉, 团队多人以后真要每个人都认真学习一下 git flow

@happywowwow 恩，言简意赅，感觉最适合先采用这种流程。谢谢

@xavierchow 太有用了，谢谢。提到用到 pull request, 其实我之前有这么想过，主要想用来在 merge 时用审核代码，但是好像只有 github 上可以 fork 吧?

@kisnows 是啊之前没考虑太多，之后还是要改过来。

@lightening 这个我之前做过类似的。前一段时间的一个项目，为了维持线性，我是让其他人都打 patch 给我，我来审核，再做 push 。但这样负责合并的人会非常累。我已经多次在地铁和公交车上做合并，然后 push 了。哎真是心酸。

@zealot0630 看了半天，隐隐约约觉得有点意思，但是最后还是没看懂啊

lightening

2015-08-22 02:32:47 +08:00

@cxq 那就好好学一下 git flow 吧，找个托管网站(GitHub, GitCafe, etc )，用 pull request 的方法会很方便。
听说遥远的 SVN 时代，有种职位叫 SVN 管理员……