关于git:gitlab-合并请求

Git 以及基于 Git 的各代码开发合作平台，比方 Github, Gitlab, Bitbucket, TFS Git 等正逐步成为首选的代码版本管理工具，而基于 Git 的根本开发流程则是开发者创立集体的公有分支并在集体的公有分支上提交代码，代码实现后创立合并申请 (pull/merge request) 到主分支让相干人员做代码评审，评审通过后将合并申请 (pull/merge request) 合并到主分支上。

用一句话总结就是：你收到一个工作后，在团队分支的根底上创立一个集体分支并在这个分支上开发，实现后将代码推送到近程，并发动申请合并申请，行将集体分支合并到团队分支上，由团队负责人审核该分支的代码并决定是否合并到团队分支上。

从上述总结咱们能够看出，合并申请的作用之一是 代码审查，团队负责人对每个我的项目参与者的代码进行初步审查后，再决定合并与否，肯定水平上能够缩小 bug 的数量，尤其是审查老手或者说不太懂 git 的程序员的代码。

下面只是陈说性地阐明了什么是合并申请以及合并申请的作用，上面将通过菜鸟犯过的谬误来直观地感触合并申请的重要性。

菜鸟犯的两个谬误

菜鸟小明和巨匠老白共同开发一个我的项目，一人负责我的项目的一半。小明菜，先一步开发，实现一个模块后就把代码推送到 dev 分支上。老白经验丰富，拉取、开发、推送天然不在话下。到这里，所有都还失常，因为是小明先推送代码。第二天小明从 dev 分支上拉取代码时，问题就呈现了。因为小明负责模块的路由和老白负责模块的路由写在同一个文件中，所以小明在第二次拉取代码的时候，近程的路由文件和本地的路由文件起了抵触，须要手动合并。菜鸟小明在解决抵触时，不太懂 Accept Current Change 和 Accept Incoming Change 的含意，就凭感觉点了一个选项（事实证明是错的），实现一天的开发后就把代码推送到了 dev 分支上。而这时菜鸟小明还没有意识到本人犯了错——把老白写的路由都删了。这是菜鸟小明犯的第一个谬误。

菜鸟小明犯的第二个谬误就是把另外一个模块的同名文件改了。小明负责的某个模块的某个性能与我的项目中另外一个模块的性能十分相似，图省事，就创立了一个相似的文件，取了一样的文件名。小明习惯用 ctrl + g 这个快捷键跳转文件，有可能是累了，有可能是午休没睡醒加上那段时间状态不太好，恍惚间误改了另一个模块的文件，导致呈现了很重大的问题。

置信你能够感触到，如果让菜鸟小明去合并团队的代码，问题将会是无穷无尽的。事实上，老白发现小明删除了他写的路由后就让小明提交合并申请而非间接把代码推送到 dev 分支上。菜鸟小明听到“合并申请”时一头雾水，尽管他在网上找到了一篇十分具体地介绍“合并申请”的博客——保姆级教程 | Merge Request 分支合并申请，然而实际操作起来还是差点意思，最初还是在老白的帮忙下，菜鸟小明才搞明确了合并申请的流程。

流程

以在一个我的项目中减少一个新性能 A 为例：

1. 切换到本地的 dev 分支，并将近程的 dev 分支拉取到本地；
2. 在本地 dev 分支上新建一个分支 feat_A，并切换到该分支上；
3. 在 feat_A 分支上进行开发；
4. 进行开发并提交你的代码；
5. 将 feat_A 分支推送到近程；
6. 找到并点击 merge_request 按钮，抉择好对应的参数，点击合并；
7. 期待审核后果，如果审核通过，就将近程和本地的 feat_A 分支删除；
8. 如果新的工作来了，就反复以上步骤。

4、5 步骤在理论的开发中可能会反复执行，直到一个残缺的性能开发实现。

详情参考 保姆级教程 | Merge Request 分支合并申请

可能呈现的问题

近程仓库的代码和本地仓库的代码呈现抵触，应用 git pull origin <remote branch> 拉取近程代码时，会呈现一个多余的 merge commit。

如果多人屡次如此操作，那么提交记录就会呈现很多条这种主动生成的 merge commit，十分难看。

而应用 git pull --rebase <remote branch> 这个命令行，就能够防止生成多余的 merge commit，使提交记录更加洁净清新。

详情参考 git pull –rebase 的正确应用

流程优化——合并提交

如果须要在我的项目中新增一个性能 A，这个性能十分大，须要四五天能力实现。在接到这个工作后，失常状况下，执行 1、2、3 步骤，然而这个性能一天开发不完，在下班前会提交一次当天的代码，而后推送到近程，周而复始，直到最初一天开发完 A 性能，才把分支合并到团队的分支上。

这样做也没什么大问题，然而一个性能有四五次提交，如果性能更大更难，就会呈现更屡次的提交，不不便 code review。

更好的做法是合并提交：将开发性能 A 的所有提交合并为一个提交，随后合并到团队开发的分支上。

能够应用 git rebase -i 命令行来合并多个提交，详情参考 git 合并屡次提交

参考

1. Git 合并申请 (Pull/Merge request) 的实质
2. 保姆级教程 | Merge Request 分支合并申请
3. git pull –rebase 的正确应用
4. git 合并屡次提交