这是一个创建于 4349 天前的主题，其中的信息可能已经有所发展或是发生改变。
不知道这里有没有稍大规模（10人+）使用 git 的团队成员，最近和一个长期使用svn，尝试迁移到git的团队成员沟通，发现他们在现实中遇到的问题：
1 他们还是比较习惯在一个分支里面开发，减少了 merge 的过程，因为他们开发时候交互比较多，这样遇到一个问题，那就是类似交叉提交 commit，形成 "Merge branch 'master'"，就是在 git pull 的时候自动合并了，这样的话历史记录非常的不好，没有形成干净的历史记录，对比较查看很不友好。
2 如果分开使用分支，因为他们的开发交互非常多，比如一个人更新了一个文件，然后另外一个人需要立刻获取到这个开发结果，这样频繁的merge branch，本质上和 1 是没有太多区别的，还有提高了merge的代价。
其他不适应的问题和git分布式概念相关，换一下思路就能解决，上面的问题有点矛盾，我想确实是一个问题。
目前看来git比较适合模块化，程序员能非常独立的项目，如果交叉非常多，需要频繁协同（比如前端，后端，提供ajax接口然后要立刻用到），要怎么办呢？
1 他们还是比较习惯在一个分支里面开发，减少了 merge 的过程，因为他们开发时候交互比较多，这样遇到一个问题，那就是类似交叉提交 commit，形成 "Merge branch 'master'"，就是在 git pull 的时候自动合并了，这样的话历史记录非常的不好，没有形成干净的历史记录，对比较查看很不友好。
2 如果分开使用分支，因为他们的开发交互非常多，比如一个人更新了一个文件，然后另外一个人需要立刻获取到这个开发结果，这样频繁的merge branch，本质上和 1 是没有太多区别的，还有提高了merge的代价。
其他不适应的问题和git分布式概念相关，换一下思路就能解决，上面的问题有点矛盾，我想确实是一个问题。
目前看来git比较适合模块化，程序员能非常独立的项目，如果交叉非常多，需要频繁协同（比如前端，后端，提供ajax接口然后要立刻用到），要怎么办呢？
 | 1 cloudzhou OP svn 为什么没有遇到这样的问题呢，因为 svn 是以 file 为单位，git 以 commit 为单位，对冲突的概念也不是一个定义。svn 只有在 file 同时修改才是冲突，而 git 是不允许 push fast forward，所以这就频繁合并了。 |
 | 2 ShadowStar 2013-11-12 18:31:49 +08:00 git config pull.rebase true |
 | 3 czheo 2013-11-12 19:39:58 +08:00 1 可以用git pull --rebase解决 你说的问题确实存在，但git是鼓励多分branch多merge，必然造成merge commit。 要解决你的问题，可以尝试小修正在master上直接做，用git pull --rebase。大修正开branch，正常做merge。 或则用github/gitlab的pull request来协同作业，管理历史纪录。就不会这么在意过多的merge commit了。git的团队协作实践可以看看github flow和git-flow/hub-flow的资料。 |
| 4 cloudzhou OP |
 | 5 gonefish 2013-11-12 22:44:00 +08:00 当采用多开branch的场景下，你应该经常把master的更新合并到你的branch中，但这种情况最好保证不要把不完整的branch合并到master中，另外merge时是不要采用fast forward，添加--no-ff。 |
 | 6 wxm4ever 2013-11-12 23:15:10 +08:00 请使用`git rebase`.并且谨记分支与master同步永远用rebase,master与分支合并用merge --no-ff.当然这并不是定律，还得根据具体的应用场景来区分。 |
 | 7 dancercl 2013-11-13 00:17:33 +08:00 git的最佳实践，记住2点就行了： 1. 同一个分支内，用rebase （产生干净的历史） 2. 不同分支之间，用merge 更追求完美的话，还有额外的一点： * merge的时候如果来源分支是个短期临时分支，merge完就会删掉的，可以先squash再merge，同样可以让历史看起来干净点 |
 | 8 clino 2013-11-13 09:13:30 +08:00 git config --global --replace-all branch.autosetuprebase always 强制在git pull的时候使用rebase方式,相当于 git pull --rebase |
 | 9 standin000 2013-11-13 09:22:44 +08:00 用git cherry-pick可以merge指定commit http://stackoverflow.com/questions/881092/how-to-merge-a-specific-commit-in-git 另外虽然git是以commit为单位，但每个commit中尽量不要包含跨模块（文件）代码。 |
 | 10 williamx 2013-11-13 09:35:22 +08:00 我好像并不在意 merge commit 的消息，能说说你们在意的原因吗？ |
 | 11 coolcfan 2013-11-13 10:50:50 +08:00 公司产品至今源码有数万个文件，主repo上的master分支有7万5千多条commit。 我们是采取开源项目的方式（其实本来也是开源的）大家各自fork主repo，然后建新的分支开发，master则保持跟上游一致；要做的事情完成的时候就发pull request给老大，让老大merge到他的repo里，再push到主repo中。 |
 | 12 charlestang 2013-11-13 10:57:43 +08:00 推荐使用git rebase。我所在的一个团队，要求每个人都使用git rebase，这样所有的commit都会记住。另外：我个人还有个习惯，就是commit merge，就是学习成本挺高，需要比较高的自觉。我每次开发某功能，随时commit，最后push之前，使用交互式 rebase，将所有的commit merge成一个commit，然后再push，这样主干上我的提交记录就会比较整洁。当然这样很容易误操作，所以也没有推广，谁会谁用。不会的也不要求了。 |
 | 13 HowardMei 2013-11-13 11:02:29 +08:00 git cherry-pick +1 各自更新很快的时候，其实可以不Commit，先拿过来用着，等到别人稳定后再拿一次 git cherry-pick -n firstcitag git reset <files not stable> .... do your own business .... git cherry-pick firstcitag^..lastcitag 这样Merge的时候一般不会有冲突 个人感觉git cherry-pick 比 git rebase 更灵活，后者是比较大的操作 |
 | 14 msg7086 2013-11-13 13:53:22 +08:00 一句话： git-flow |
| 15 msg7086 2013-11-13 13:58:13 +08:00 如果是单个功能上的频繁交互开发的话，可以考虑楼上几位的建议，在branch上做squash或者cherry-pick (其实道理一样的，就是把commit给合并起来) 等单个功能开发完了，把branch整理的好看点，然后做pull-request，review完merge回主线。 |
Select Language