This topic created in 4629 days ago, the information mentioned may be changed or developed.
不知道这里有没有稍大规模（10人+）使用 git 的团队成员，最近和一个长期使用svn，尝试迁移到git的团队成员沟通，发现他们在现实中遇到的问题：
1 他们还是比较习惯在一个分支里面开发，减少了 merge 的过程，因为他们开发时候交互比较多，这样遇到一个问题，那就是类似交叉提交 commit，形成 "Merge branch 'master'"，就是在 git pull 的时候自动合并了，这样的话历史记录非常的不好，没有形成干净的历史记录，对比较查看很不友好。
2 如果分开使用分支，因为他们的开发交互非常多，比如一个人更新了一个文件，然后另外一个人需要立刻获取到这个开发结果，这样频繁的merge branch，本质上和 1 是没有太多区别的，还有提高了merge的代价。
其他不适应的问题和git分布式概念相关，换一下思路就能解决，上面的问题有点矛盾，我想确实是一个问题。
目前看来git比较适合模块化，程序员能非常独立的项目，如果交叉非常多，需要频繁协同（比如前端，后端，提供ajax接口然后要立刻用到），要怎么办呢？
15 replies • 1970-01-01 08:00:00 +08:00
 |
|
1
cloudzhou Nov 12, 2013
svn 为什么没有遇到这样的问题呢，因为 svn 是以 file 为单位，git 以 commit 为单位，对冲突的概念也不是一个定义。svn 只有在 file 同时修改才是冲突，而 git 是不允许 push fast forward，所以这就频繁合并了。
|
 |
|
2
ShadowStar Nov 12, 2013
git config pull.rebase true
|
 |
|
3
czheo Nov 12, 2013
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的资料。
|
 |
|
5
gonefish Nov 12, 2013
当采用多开branch的场景下，你应该经常把master的更新合并到你的branch中，但这种情况最好保证不要把不完整的branch合并到master中，另外merge时是不要采用fast forward，添加--no-ff。
|
 |
|
6
wxm4ever Nov 12, 2013
请使用`git rebase`.并且谨记分支与master同步永远用rebase,master与分支合并用merge --no-ff.当然这并不是定律，还得根据具体的应用场景来区分。
|
 |
|
7
dancercl Nov 13, 2013
git的最佳实践，记住2点就行了：
1. 同一个分支内，用rebase （产生干净的历史）
2. 不同分支之间，用merge
更追求完美的话，还有额外的一点：
* merge的时候如果来源分支是个短期临时分支，merge完就会删掉的，可以先squash再merge，同样可以让历史看起来干净点
|
 |
|
8
clino Nov 13, 2013
git config --global --replace-all branch.autosetuprebase always
强制在git pull的时候使用rebase方式,相当于 git pull --rebase
|
 |
|
10
williamx Nov 13, 2013
我好像并不在意 merge commit 的消息，能说说你们在意的原因吗？
|
 |
|
11
coolcfan Nov 13, 2013
公司产品至今源码有数万个文件，主repo上的master分支有7万5千多条commit。
我们是采取开源项目的方式（其实本来也是开源的）——大家各自fork主repo，然后建新的分支开发，master则保持跟上游一致；要做的事情完成的时候就发pull request给老大，让老大merge到他的repo里，再push到主repo中。
|
 |
|
12
charlestang Nov 13, 2013
推荐使用git rebase。我所在的一个团队，要求每个人都使用git rebase，这样所有的commit都会记住。另外：我个人还有个习惯，就是commit merge，就是学习成本挺高，需要比较高的自觉。我每次开发某功能，随时commit，最后push之前，使用交互式 rebase，将所有的commit merge成一个commit，然后再push，这样主干上我的提交记录就会比较整洁。当然这样很容易误操作，所以也没有推广，谁会谁用。不会的也不要求了。
|
 |
|
13
HowardMei Nov 13, 2013
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 Nov 13, 2013
一句话： git-flow
|
|
|
15
msg7086 Nov 13, 2013
如果是单个功能上的频繁交互开发的话，可以考虑楼上几位的建议，在branch上做squash或者cherry-pick (其实道理一样的，就是把commit给合并起来)
等单个功能开发完了，把branch整理的好看点，然后做pull-request，review完merge回主线。
|
Select Language