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

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

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

要科普 rebase

git merge --no-ff

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

@lightening 好的 谢谢

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

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

随便贴一点

* 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
|\ \ \
| |/ /
:

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

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

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

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

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

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

> 在 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 已经讲的很清楚了，花点时间去看看，理解概念胜过硬记流程，磨刀不误砍柴功，不是么？

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

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

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

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

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

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

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

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

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

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

第一张图是 git ，第二张是 svn

@lightening 嗯 之前没研究过 pull request 上午看了下 . bitbucket 也可以用 准备做下实验最近用起来. 感觉前一段时间 我一直在做 git 管理员 主要是团队里的其他人都不懂. 还都只会 push pull 。 要花时间普及

你需要 了解 rebase

pull 的时候选择 rebase, 感觉你们没有使用 rebase 的原因

不觉得乱啊。

论 rebase 的重要性……