这是一个创建于 2494 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们主线一个分支，开发一个分支，太多人一起上代码，然后开发分支差主分支好多。现在我大晚上的还将开发分支代码合到主分支，一行行对。你们有我这边折腾吗？求解啊
 |
1
likuku 2018-01-23 21:40:45 +08:00  1
定时定期，别拖，别积攒。
再多要点人帮你合并 |
 |
2
missdeer 2018-01-23 21:41:01 +08:00
我们直接 double commit
|
 |
3
StevenTong 2018-01-23 21:45:22 +08:00
无解吧
|
 |
4
btcking 2018-01-23 21:49:22 +08:00
公式机制被破坏了，哈哈哈。。
|
 |
5
miketeam OP 8000 多行代码，真是日狗了
|
 |
6
nciyuan 2018-01-23 21:51:21 +08:00 via Android
一行一行？
直接看文件，一样的直接略，开发分支优先 |
|
7
miketeam OP 怕覆盖了别人的，5 个人的代码改来改去，受不了了
|
 |
8
XinLake 2018-01-23 21:54:56 +08:00
不重叠，不遗漏，逐个穷尽，完全独立。
不同的人做不同模块的代码这种情况就少了，你这估计是有多人做同一个事情就变成这样了 |
|
9
miketeam OP compare 对比，一个个挑，把我自己的先挑出来。
|
|
10
miketeam OP 一部分人开发新模块，然后又有人局部重构
|
 |
11
thundernet8 2018-01-23 21:56:09 +08:00 via Android 2
以后要让你的队友 开发习惯性 rebase 主分支
|
 |
12
youdiqs 2018-01-23 21:57:33 +08:00 via iPhone 1
我们是 git 一个主分支 4 个开发分支
目前没啥大问题，万一有啥问题反正可以回滚。 要是对 git 合并不太信任，或者无法测试是否合并正确 or 难以判断冲突的代码 那就要至少按天来 频繁的合并 才不会导致后期大量堆积代码验证合并。 也可以用 代码比较工具 来进行对代码一行行的对比合并（太难…耗时间） |
 |
13
chinvo 2018-01-23 21:58:07 +08:00 1
团队协作没做好
new branch、pull request 之类的方案要高效率用的基础是团队分工 避免同时针对同一个 feature/bug 作改动 每做到一个阶段就提交一次 |
|
14
miketeam OP 这样合并完了明天又是自虐般的自测试验证了。真的好绝望
|
 |
15
Hieast 2018-01-23 22:06:23 +08:00 3
git flow，各自处理各自的 feature 合并到 develop 分支
|
|
16
miketeam OP 你是不知道我们这里 controller 有多重…我现在有空就一点一点的搬。头发都熬白了几根。真真的勇士敢于直面惨淡的垃圾场～
|
 |
17
zjsxwc 2018-01-23 22:28:55 +08:00 via Android
是你们分支太少的缘故吧，不可能只有两个分支，一个主分支 master，一个开发分支 dev，这样合并当然会有很多冲突了。
git 正常使用应该是每个 feature 都从 master 开一个小分支，于是我们工作时会有 n 多小分支，这样既保证了每个小分支可以很容易的（冲突少、逻辑清晰、能快速找到当事人）被合并到 master，又能和 redmine 等项目管理配合起来管理项目，然后定期删除老的 feature 分支就好了。 |
|
18
miketeam OP 你们猜到我这里是几手的代码
|
|
19
miketeam OP 还真是 2 个分支呢
|
 |
20
YyYyYyy 2018-01-23 22:30:45 +08:00
@miketeam 为什么局部重构会和新模块开发有冲突需要合并？那说明这局部的重构就不是解耦的。
再退一步讲，为什么不用适配器模式把重构部分的对外接口包起来？ 建议明天把搞局部重构的那人拉出去枪毙（不要说是我说的 ε===ᕕ(ᐛ)ᕗ |
|
21
miketeam OP 想法是好的，我现在改那些代码只能借着修改 bug 去改。主动修改那些代码需要和一堆人讲明情况，拉个 ppt 说明这样改的原因…
|
 |
22
nicevar 2018-01-23 22:45:43 +08:00 1
就两个分支....楼主你不累死也是奇迹，人上得多，效率低下
这不是合代码的问题，是你们任务分配组织能力有点差啊，尽量把任务分细了，一个分支对应一个任务或者 bug，限制时间，比如每个任务必须三天内完成，如果评估完不成就再细分，这样代码冲突会降到最低 发布版本的时候迭代做好点，可以一周一小版本，一月一大版本之类的 |
|
23
miketeam OP 我现在最怕的是把别人的代码覆盖了…正在对比，不出意外我马上可以下班了。还有人在奋斗。。
|
|
24
miketeam OP 7 点开始的，中间合了几次，正要上又被抢先了……然后又要拉取代码在看！
|
 |
25
yomiko123 2018-01-23 23:04:24 +08:00 1
祝你好运吧
|
 |
26
ryd994 2018-01-23 23:08:17 +08:00 via Android
所以分 pull 党和 rebase 党
|
 |
27
nl101531 2018-01-23 23:12:44 +08:00
应该不同的人不要做同一块业务...或者分层逻辑下,不同的人写不同的层.中间用接口沟通
|
|
28
miketeam OP 这个不是 rebase 的问题。主分支跑太快了……
|
|
29
miketeam OP 此刻路上已经没有多少人了……内心拔凉拔凉滴
|
|
30
miketeam OP 狠狠滴骂一句：狗屎架构师
|
 |
31
lihongjie0209 2018-01-23 23:26:25 +08:00
每个人做自己的模块不就好了吗?
|
|
32
miketeam OP 抢出版本，dieline 快来了……
|
 |
33
imNull 2018-01-23 23:33:32 +08:00 via Android
master 加锁，只有 owner 有 Merge 权限。
开发时，每个人一个自己的分支，自己定期合 master，最后提 code review，如果冲突打回重改，最后 owner 合并。 这样子应该没什么问题了，有问题可以再交流 |
 |
34
eccstartup 2018-01-23 23:35:44 +08:00 via iPhone
deadline
git pull --rebase |
|
35
miketeam OP 以为代码不多的。原本计划 8 点下班，喝喝茶，写写 go 在睡觉。现在撒都不想直接睡了，太困了……
|
 |
37
66450146 2018-01-23 23:45:07 +08:00
CI 自动从开发分支上 merge 主分支，如果出错的话要求分支作者 rebase / merge 就是了
我们的做法是，没办法 merge without conflict 的改好才做 code review，测试没通过的修好才做 code review，review 不过的重新改 |
 |
38
PureWhite 2018-01-24 00:19:04 +08:00 6
@miketeam 楼主，给出一个比较好的实践吧：
1. 禁止直接 push 到 dev 或者 master 分支，必须使用 pull request 才行（ github 会保证合并无冲突，有冲突自己 resolve ），而且必须要 review 通过才行，任何人都没有权限直接合。 2. 所有 pr 要求代码量改动在 100 行之内，方便 review，一般 30 行左右最佳。 3. 把所有的任务无限拆小，越小越好，不停地分解到一个几十行代码的级别。 4. 集成 ci 测试，测试不过不 review 不能 merge，github 是可以设置的，和 circleci 集成很好。 5. **如果不遵守以上的，你干嘛还用 git 啊，大家直接改 ftp 的文件不得了，不按照流程走一切工具和方法论都无用。** |
 |
39
swulling 2018-01-24 00:23:24 +08:00 via iPhone 2
配置 push 只允许 fast forward，如果出现冲突，由提交代码的人自行解决，不解决无法合入
简单讲，谁的代码先入库，其他人就得解决冲突。 |
 |
40
last 2018-01-24 00:27:18 +08:00 via Android
祝你好运哈哈，我期末作业就四人的代码都弄得头疼
|
 |
41
zhx1991 2018-01-24 00:28:13 +08:00
定期的把主分支往自己分支上合, 防止差太远.
|
 |
42
iyaozhen 2018-01-24 00:30:04 +08:00 via Android 1
我们是分支开发主干上线。
大家都在自己的主干开发，提测前先把主干的代码合到分支，上线前分支再提合到主干 |
 |
43
alexapollo 2018-01-24 01:18:20 +08:00
最简单有效的开发准则：
人数较少，项目不大，且人员精良程度较高，可以只有 master 和 dev 分支，尽量避免分支之间的切换 |
 |
44
msg7086 2018-01-24 08:08:19 +08:00
这大概是把 Git 当成 SVN 在用了。
|
|
45
miketeam OP @alexapollo 然而事实就是人数多，项目大，人员高中低都用，富有层次感。经常 2 个分支来回切。。。
|
 |
47
dong3580 2018-01-24 09:31:24 +08:00 2
@miketeam
同时多个人改一个文件必然会冲突，需要配合，细化模块然后分更小的小组开发，这样只要每个人都在改自己的那部分代码，一般不会有问题。 |
 |
48
lights 2018-01-24 09:36:11 +08:00 via iPhone
用 git，大家都遵循同一个 git 的 work flow
|
 |
49
SmiteChow 2018-01-24 10:26:45 +08:00
需求拆分问题
|
|
50
miketeam OP 和需求拆分粒度好像没关系。主要是先前写的太挫了。不敢改，因为每 50 行代码要自己设计 3 个测试用例。完全就是一项体力活。改完了还要一个个汇报。心力憔悴啊
|
 |
51
BBCCBB 2018-01-24 12:19:04 +08:00
gitflow 对合并代码也不友好,
github flow 是最吼的~ 就是提 pull request 这种方式是最吼的. |
|
52
miketeam OP 不能永 GitHub 怎么办？
|
 |
53
mars0prince 2018-01-24 12:58:41 +08:00 1
最简单的就是每天同步 master，其他任何方法都不靠谱，你落后主分支几百个版本，神仙也帮不了你
|
 |
54
iamsk 2018-01-24 12:59:55 +08:00 1
迭代时间短一些，功能小一点。
|
 |
55
yuankui 2018-01-24 13:11:35 +08:00
项目启动的时候从 master 拉一个 feature 分支
然后你们项目成员基于这个 feature 分支开发, 开发的方式是从这个 feateure 分支拉新的分支,然后后定期把"相对稳定的"代码合到 feature 分支, 保持 feature 分支与你们每个月的分支都是相对实时的. 这样就不会有最后合代码的问题了. 话说回来, 合代码是日常的事, 而不是最后 的事. |
 |
56
zhangyouming 2018-01-24 13:14:08 +08:00
推荐一个工具 beyond compare 。用了很久了。
|
 |
57
AsisA 2018-01-24 13:22:23 +08:00 via Android
master 分支+dev 分支，master 分支设置 owner，然后大家每人从 dev 分支上开自己的分支。
平时大家往 dev 分支合并自己的分支，owner 定期把 dev 分支往 master 分支合并，如果不怕麻烦还可以加上 reviewer 分工的时候也尽量每人做不同的部分，比如按照功能模块拆分 |
 |
58
wizardoz 2018-01-24 13:29:54 +08:00
楼主生怕把别人的代码覆盖了，所以熬夜加班比较代码。
当楼主看完最后一行确定无误运行 push 的时候，git 提示，你的本地代码不是最新，请更新到最新再进行提交！ 楼主心中一万只羊驼奔腾而过。在对比代码的几个小时中别人又上传了新的代码。 一切从头开始…… |
 |
59
xloger 2018-01-24 13:30:50 +08:00
我们是这样的，线上版在 master 分支，开发版在 dev 分支，然后每次一个人或几个人要开发某新功能时就在 dev 上切一个分支出来，开发完毕后 merge。基本没遇到落后几百个分支没法合并的问题。 [但是我隐约记得这样好像会导致这些分支的 commit 信息丢失？
|
 |
60
scofieldpeng 2018-01-24 13:35:17 +08:00
用 git 那么久就没有出现过你的这些问题，很明显是你们 git 工作流，然后你们自己也不按照规则玩导致的，最后套用 v 站经典话术：要么忍，要么滚
|
 |
61
zhangsen1992 2018-01-24 13:36:28 +08:00
每次 变更完立马 commit merge 别人再 pull 否则攒一堆冲突
|
 |
62
contmonad 2018-01-24 13:46:32 +08:00 via iPhone
用一些新出的更好的工具。关键词：patch-based VSC, semantic merge
|
 |
63
lwldcr 2018-01-24 13:48:35 +08:00
每天先 pull --rebase, 再开始干活
另外 代码如果拆分的好的话 单个文件只有 2、3 个人需要修改它 这样出现冲突也好解决一些 |
 |
64
ittianyu 2018-01-24 13:48:59 +08:00
后端：微服务(一人负责几个项目)
移动端：分模块(一人负责几个模块) 前端：有请下面的大神来回答 |
 |
65
firefox12 2018-01-24 13:53:52 +08:00 via iPhone
很好办的 gerrit 每个人 gerrit 提交 ci 过了再提交，有冲突了 自己打回去重新做。rebase 了 编不过了 你来负责。总之先进去的一定是有优势的，后进去的 需要解决冲突，这个永远不能避免
|
 |
66
ai277014717 2018-01-24 13:54:39 +08:00
根据模块分工，然后单元测试。先提交先走人。
|
|
67
miketeam OP 就是用 beyond compare
|
 |
68
tairan2006 2018-01-24 13:56:31 +08:00
git flow，定期合并
|
|
69
ai277014717 2018-01-24 13:56:47 +08:00
每次小版本结束就 merge 到 master 上然后开一个新的 develop-1.1xx 分支，大家在上面开发。
|
|
70
miketeam OP 也正是用 gerrit ……
|
 |
71
scriptB0y 2018-01-24 14:15:02 +08:00
能往主分支合并代码的不应该只有 develop 分支和紧急的 hotfix 分支吗？不然区分主分支和 develop 还有什么意义？
|
|
72
miketeam OP @scriptB0y
情况是：主管让我们在 develop 分支开发验证好没问题，然后自己去理清代码上传到 master 分支… |
 |
73
banksiae 2018-01-24 15:01:31 +08:00
应该是分支没开对，各种分支合并的操作流程出问题了
|
 |
74
precisi0nux 2018-01-24 16:28:10 +08:00
借助工具吧，比如 jet brains 有些有冲突的代码可以智能合并，完了自己再检查一下就好了，能省不少事。
|
 |
75
pkookp8 2018-01-24 16:44:22 +08:00 via Android
复杂的代码先合，简单的代码后合
没事就把别的分支的代码合到自己分之上 |
 |
76
Alex6 2018-01-24 16:52:16 +08:00
楼上说的都挺好的，比如任务拆分，禁止直接推送 develop，master 等。
建议你们小团队可以搞这样一个习俗，不管什么分支代码，只要在该项目内，比如是拉出的 feature 开发分支，那么保持提交点是一条直线，谁要是玩花了，请客喝水吃零食！ 至于 feature 分支合到 develop 上冲突很多，那显然是模块任务划分不清，或者是需求不明，很多人在同时在改同一个地方。那是组织需求的问题了，这是属于是做不做。而代码的维护和管理是怎么做。 |
 |
77
0Kelvin 2018-01-24 16:53:15 +08:00
我只要改完一块东西必然提交，怕自己这工作的破电脑忽然哪天就跪了。
|
 |
78
nekoyaki 2018-01-24 16:55:39 +08:00
要么是你们自己工作流程的问题，要么是把 git 当 svn 用了……
|
 |
79
sampeng 2018-01-24 17:29:04 +08:00
1.模块化不够好。改一处要动其他地方
2.每日提交合并。你需要一根假 master 分支，对，就是测试分支。这个分支和 master 分支是时刻同步的，最少基线是同步。每日提交合并到这根分支上来。如果有测试，测试应该在这根分支上做测试。难道你们在各自的子分支上测试？会累死的。。ok，测试完毕。可以上线了。一个 merge 就完事了。根本不可能有冲突。要冲突也在每日提交的时候解决了。每日提交的时候，开发分支需要 rebase 合并好了的结果。然后接着干。 |
|
80
sampeng 2018-01-24 17:30:38 +08:00 1
当然，我实际的使用场景来看。。小于 5 个人压根没这么麻烦。。模块化做好后，没人 commit 也不会冲突。一根线就够了。。其他都是自己折腾自己
|
 |
81
romisanic 2018-01-24 19:52:36 +08:00
每天开始开发前，合并一次主干代码，晚上下班前，合并一次主干代码
|
|
82
miketeam OP 已经记下了，一个个试一下，看以后会不会好一点
|
 |
83
ckylolo 2018-01-24 20:45:05 +08:00 1
吃尽苦头，明白是流程规范问题，尝试一下 git 最佳实践吧，具体参考
[link]( http://blog.jobbole.com/109466/) 重点两个： ##理解这张图  ##记住合适的提交时机 |
 |
84
lvxg 2018-01-27 22:14:14 +08:00
我们也 2 个分支，有一次和运维合了一宿 都合懵逼了
|
|
85
miketeam OP 我心里有阴影合的…
|
Select Language