Gitlab Merge Request “commits” “changes”分析

最近处理开发人员Merge request 问题时候碰到一个问题:开发人员实际做了一个提交,编辑了三个文件,但是在gitlab merge request中显示的是12个文件差异。今天分析了一下原因,以此记录:


1 分析gitlab mq(merge request)的commits

例如有两个feature,develop和张三的创建的fea1,fea1提交 mq到develop时候gitlab是如何计算commits?

如果把fea1提交到develop那么只需要计算出来 在fea1上不在develop分支上的commit就可以了,用git 命令是 git log develop..fea1 展示的就是gitlab显示commits 即 B D


2 Gitlab mq的changes

先看一个简单情况:

例子还是上面的例子如何计算变更文件的呢?

合并两个分支的时候Git会首先找到两个分支的公共父提交从图上可以看出他们的父提交为A(如果拓扑图复杂可通过命令寻找 git merge-base fea1 develop)那么fea1修改的代码文件即fea1 在提交A基础上修改的文件内容直接展示即可,gitlab展示的changes为 git diff A fea1


复杂情况:

基于以上拓扑图张三提交mq 到develop分支(F) 测试人员测试认为不通过

张三在原来fea1基础上修改bug提交(G)

与此同时开发李四从提交C拉出fea2分支开发提交(H),提交后正常走mq到develop(I)

张三需要fea2的功能于是就把fea2 merge到了fea1 形成了新的提交J

在这种情况下如果 张三发起mq会怎样呢?

分析如下:

首先git会找fea1和develop的公共父提交,这种情况下公共父提交有两个H和D(A也是公共父提交但不是最优公共父提交,因为A是D的父提交,这个git官网所述可以参考git merge-base命令) 父提交可以通过 git merge-base fea1 develop -a 显示

commits: 通过 git log develop..fea1 可以查询到G J gitlab显示正确

changes该如何选择呢?如果公共父提交选择D 应该显示 git diff D J,这样的话可可以理解的 本次mq显示张三最近的修改。如果选择H 就会显示 git diff H J,会把fea1 的历史修改全部显示即 B D G所有修改,这样就有歧义了, 1、Merge Request commits展示的死活G J二changes展示的是B D G的修改,2、张三这次本来至修改了G 他认为changes只展示G是合理的。

做了个实验:结果是gitlab确实选择的是H,个人猜测gitlab 是通过 git merge-base fea1 develop直接得到的(加 -a参数会显示全部的)

                        

综上所述个人认为gitlab的Merge Request还是有些歧义的 本人用的gitlab版本是8.17

看到此博客如果有自己的观点请留言

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
### 回答1: 1. 在GitLab上创建一个分支,用于修改代码。 2. 在分支上进行代码修改和提交。 3. 在GitLab上创建一个Merge Request(合并请求),将修改后的代码合并到主分支。 4. 等待其他开发人员对代码进行审核和评论。 5. 根据审核和评论修改代码,直到通过审核。 6. 合并代码到主分支。 7. 删除分支。 ### 回答2: GitLab Merge RequestGitLab 中的一个重要功能,用于对代码进行审查和合并。在进行 GitLab Merge Request 时,我们需要遵循以下步骤: 1. 新建 Merge Request:小组成员可以通过 GitLab 提交代码到项目的分支上,然后新建一个 Merge Request,该 Merge Request 会将我们提交的代码与目标分支合并。 2. 填写 Merge Request 相关信息:在填写 Merge Request 的相关信息时,我们需要确保描述清晰明了。对于要合并的代码,我们应该给予足够的解释和上下文,包括代码的用途、修改的原因、影响的范围等。 3. 分配审核人员:当 Merge Request 创建后,审核人员将查看您的代码并作出反馈。可以通过在 Merge Request 中分配审核人员来确保代码正确性和合规性。 4. 进行代码审查:审核人员应该对代码进行彻底的审查,检查代码的逻辑、变量名、类名等等,确保代码符合规范,同时避免因代码问题而引发的漏洞和错误。 5. 合并代码:如果审核人员对代码没有意见,就可以将其合并到项目的目标分支上。如果审核出问题,可以在 Merge Request 页面上提出建议或留下评论,然后再进行修改和重审。 总之,GitLab Merge Request 是一个重要且必要的步骤,可确保代码在合并到主分支之前得到透彻的审查和测试。通过正确执行 Merge Request 步骤,可以帮助提高代码质量、减少错误和节约时间。 ### 回答3: GitLab是一种版本控制系统,它允许团队协同工作并让他们跟踪软件项目的变化。当团队中的两个或多个人都进行开发工作时,他们通常会使用merge request(合并请求)来更新代码。接下来我们来看一下GitLab merge request的步骤。 1. 创建分支 在进行任何修改之前,最好先创建一个新的分支。这样您就可以在不影响主分支的情况下进行修改和测试。创建分支的操作非常简单。只需在您的项目中单击“分支”,然后输入一个分支名称。 2. 进行修改 在您的分支中进行所需的更改。您可以添加、修改或删除文件,这些更改都将保存在您的本地库中。 3. 提交更改 一旦您做出修改并准备好将其提交,您需要将这些更改提交到您的远程库中。这可以通过使用“git commit”命令来完成。提交的更改将保存在分支中,但不会更新主分支。 4. 新建merge request 完成更改后,您需要将分支与主分支合并。为此,您需要打开GitLab并选择您的分支。然后,单击“新建merge request”按钮。这将为您创建一个merge request,该请求显示将被合并到主分支中的更改。 5. 审查merge request 一旦您创建了merge request,您需要等待其他人来查看并审查修改。审查人可以在合并之前先对更改进行批准或者建议其他更改。 6. 合并请求 一旦审查者批准了更改,您就可以将更改合并到主分支中。单击“合并”按钮并输入合并请求的标题。合并请求处理程序将负责将分支合并到主分支中。 综上所述,这就是GitLab merge request的步骤。GitHub的工作流程与此类似。使用这些工具,能够促进团队的协作工作,加快项目的发布速度。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值