这是一个创建于 388 天前的主题，其中的信息可能已经有所发展或是发生改变。
起因还是之前系统问题，因为服务器 SVN 版本过老， 遂建议迁移 git ，讨论了一下决定可以。
于是我就帮忙架了 gitea
使用都还好 ，目前碰到一个问题是，多人同时改一个项目时频繁出现
Merge remote-tracking branch 'origin/main'
说一下我们的情况， 小公司 小团队，10 开发人员。
项目也比较老，没有模块化，所以不是那种每人负责自己的模块那种。
我一个人的提交线就是一条直线， 但是当有别人提交的时候 很容易就出现
Merge remote-tracking branch 'origin/main' 虽然好像也没啥影响。
因为就这么点人，使用方面就是 线上版本用分支 onlie 和 main 分支做开发版 ，
有什么都往 main 里提。线上有问题就切 onlie 改线上的，等没啥情况了再合到 main 。
但是目前几乎只要提交记录里出现别人 就会出现这个提示。
提交前更新在第一次出现这个问题的时候，也交代了大家，也做了，但是还是出现了。
查了下 好像没什么影响。但是就是看着有点烦。
所以想问下。git 的正确姿势是什么。我们的使用方法有哪些需要改正的？
 |
1
renfei 2023-12-07 14:12:18 +08:00
建议看下 GitFlow 工作流
每人一个分支，然后往基准分支中 merge 合并 基准分支往个人分支中的话，使用变基 rebase |
 |
2
kaf 2023-12-07 14:13:30 +08:00
建议看下 GitFlow 工作流
|
 |
3
jowan 2023-12-07 14:14:50 +08:00  12
人不多直接公用一个 dev 分支 再 merge 到 master
提交之前拍一下桌子大喊：哥要 PUSH 了！！ |
 |
4
Guaidaodl 2023-12-07 14:16:49 +08:00
你们这个接近主干开发的流程, 就是所有的开发都是在一个分支上开发.
在这种开发模式下, 开发在 push 之前要先把自己的提交 rebase 到最新的代码上. 具体的命令就是你运行 pull 的时候加上 --rebase 参数 |
 |
5
cheng6563 2023-12-07 14:17:14 +08:00
正常现象
|
|
6
Guaidaodl 2023-12-07 14:18:09 +08:00
话说回来, 这种开发模式很考验开发人员素质. 建议考虑切换到 Git Flow 的工作流.
|
 |
7
awalkingman 2023-12-07 14:43:50 +08:00 1
@jowan 桌子：你礼貌吗
|
 |
8
newaccount 2023-12-07 14:51:14 +08:00
别瞎扯 git-flow ，你这又不是多版本发布，别搞那玩意
保持单一主线跟你的线上版本一致，就假设是 online 其他人开的时候从哪里切分支出来都无所谓，准备上线的时候，从 online 切个 testing 出来 准备上线的功能强制 rebase 到这个 testing ，不能做的就 cherry pick ，保持 tesing 是一条直线，不要有奇奇怪怪的合并出现 tesing 去测试，没问题了上线，然后 online 去 merge testing ，合并的时候强制 --ff-only 上面是改了名字的做法，你也可以直接用 master 当做在线分支，重点是做好权限控制，只允许一个人合并到 master 简单的讲： 1. 只有一条线，其他分支都可以删 2. 只有一个人可以合并这条唯一的线，合并时必须 --ff-only |
 |
9
yangzzzzzz 2023-12-07 14:51:54 +08:00
主分支合并 其他分支只变基到主分支。
|
 |
10
janus77 2023-12-07 15:03:16 +08:00
最省力的做法我遇到过一个，那就是每个人自己开发的时候先切一个本地分支出来，在新的本地分支上面开发，然后提交的时候把这个分支合到本地的主分支，然后主分支 push 上去。
举例：员工 A 要开发 a 功能，他在他的电脑上建一个本地分支，随便取名，就叫 fucka 吧。写完以后把 fucka 合到本地的 main ，然后 main 推到远程。无冲突。 好处： - 代码冲突较小，本地分支可以写一个功能以后就合，此时改动小，解决冲突也容易。然后合完以后本地分支可以删掉，下次开始写代码的时候再开新的本地分支，保证干净。本地分支可以随便取名，随建随删。每个人都有自己的本地分支，只合自己的那部分改动，冲突也是自己最熟悉、最容易解决。 - 每次解决冲突都是本地操作，也是改代码的那个人本人亲手操作。他熟悉代码，解决冲突更容易，而且不会影响到远端。 |
 |
11
HaroldFinchNYC 2023-12-07 15:03:57 +08:00
如果代码发生冲突，多半是管理者的问题
|
 |
12
nerkeler 2023-12-07 15:05:20 +08:00 via Android
我也也是这样，但是我们这纯属拿 git 当 svn 用，多人公用 dev ，测试好了手动在提到 prd
|
 |
13
yidinghe 2023-12-07 17:08:44 +08:00
没有模块化就先模块化一下
|
 |
15
helee9199 OP |
 |
16
alleluya 2023-12-07 17:25:39 +08:00
@newaccount 根据我的经验 我觉得你说的很有道理
|
 |
17
yc8332 2023-12-07 17:31:17 +08:00
这个就是你们提交的时候没有拉取一下。如果是 commit 再拉取，他就会有一条这种记录。。
|
 |
18
jiangzm 2023-12-07 17:34:29 +08:00 2
相当于把 git 当 svn 用， 那 svn 提交代码前是不是要拉下远程不然提交不上去。
同样 git 在提交(push)前也先同步下`git pull --rebase`，这样本地提交到远程都是增量提交。 其实最好还是开发人员要有自己的开发分支，功能完整再合并到主开发分支。 |
 |
19
dif 2023-12-07 17:36:13 +08:00
每人一个分支，修改谁的，改完自己合并，如果有 codeview ，就指定开发组长才可以合并。其他人通过 gitea 发起合并申请。最终合并到 dev 分支，测试没问题合并到 master
|
 |
20
xloger 2023-12-07 17:44:02 +08:00
首先是要有意识，Git 切换分支是比较轻量的，所以是可以多分支开发。
一个简单的协作方式是：dev 分支当开发分支，然后每个人自己一个 dev-xxx 分支，某个人每次开发完一部分把代码合并到 dev ，需要的时候也从 dev 拉代码到 dev-xxx 分支。 这种是比较简单省事不容易出问题学习成本也不高的方式。 另一种更简单的方式就是其他人说的，push 的时候选 rebase ，在 IDEA 里也是一键的事。 |
 |
21
SilentOrFight 2023-12-07 17:47:31 +08:00
每个人一个分支，把改动的 commit cherry-pick 到主分支合并测试
|
 |
22
zero47 2023-12-07 17:48:52 +08:00
共用分支太频繁的锅，commit 的时候没 pull ，别人 push 后 head 就对不上了，一般 gui 的 git 就会帮你生成这个 merge ，个人分支定期合并到公共分支会好点。
|
 |
23
kogorou 2023-12-07 22:37:30 +08:00
每次开发新功能的时候就从主分支切一个新分支分配给开发者，开发人员在这个分支上 commit,push ，完成以后让开发人员提交 pull request ，然后你审核好她的代码没问题，再把这个分支 merge 到主分支上去。关键就是，merge 这个事情让一个人做，不能大家都往上 merge 。
|
|
24
kogorou 2023-12-07 22:38:57 +08:00
一个人一个分支，一个功能一个分支，切分支又不花钱。
|
 |
25
bthulu 2023-12-08 08:40:19 +08:00
CTRL+T 拉代码的时候, 下面两个选项默认选中的是第一个, 你戳一下选中第二个就没有 Merge remote-tracking branch xxx 了
Merge incoming changes into the current branch. Rebase the current branch on top of incoming changes |
 |
26
lovelylain 2023-12-08 08:53:27 +08:00 via Android
强迫症吗？实在是不喜欢有 merge 提交，可以 rebase 再 merge ，例如开发分支 dev 主干分
支 main ，在发布前： git checkout dev git fetch git rebase origin/main #这一步如果有冲突，处理起来比直接 merge 麻烦 git checkout main git merge dev 我以前喜欢在发布前这么干，可以使一个特性的提交集中到一起，后来因为冲突解决更麻烦和 dev 分支要 push -f ，改直接 merge 了 |
 |
27
balabalaguguji 2023-12-08 09:01:01 +08:00
要不试下我们的 SVN 代码托管平台： https://svnbucket.com
|
 |
28
a33291 2023-12-08 09:16:39 +08:00
我也经常见到这个,原因是 IDE 的自动化机制导致的,至少 vs 会这样.
我使用独立的 git 管理工具,从不出现这个问题 |
 |
29
tearzx 2023-12-08 09:26:48 +08:00
git pull -r
|
 |
30
horizon 2023-12-08 09:28:04 +08:00
gitlab flow
|
 |
31
mengdodo 2023-12-08 10:43:07 +08:00
不模块化就是找罪受，同一个文件所有人反复改，最后被别人丢弃了都不知道
|
|
32
helee9199 OP @mengdodo 快 20 年的项目改来改去的
同事习惯也不好。没用的代码不删，注释丢在那 。也不格式化。不会抽取。不停造差不多的轮子。 甚至 jdbc 的 rs 连线不关被我发现了，狡辩说 rs 不是连线。 提交记录是为了解决宕机问题 比我早进公司一年（ 6 年），就这水平混到现在。 另外我们是真扁平化。质量没人管。 10 个人 只有包括我在内的 2 3 个人习惯好一点。 现在的代码就是屎屎屎屎山。 鉴于在四线城市。薪资凑合，不加班。前年鉴于此想跳槽来着，但是薪资打 8 折 ，还单双休。 就只能在这养老了 |
 |
33
7inFen 2023-12-08 10:50:42 +08:00
建议把 online 设为保护分支，只有 leader 可以从 main 合并到 online
main 分支代码是主分支，再切一个 dev 分支各自开发，开发测试完合并到 main 分支 |
 |
34
nothingistrue 2023-12-08 14:50:42 +08:00
在还不熟悉 git 工作流的时候，先强制禁用默认的 merge pull （ fetch + merge ），改为 rebase pull （ fetch + rebase ），这样的话，提交历史的表现会跟 svn update 一样的。
|
 |
35
rnv 2023-12-08 16:51:05 +08:00
git pull --rebase 试试
|
Select Language