Gitlab에서 보호 브랜치를 설정하고 PR을 제출하는 방법에 대해 이야기해 보겠습니다.

이 글은 Gitlab을 배우고, 보호 브랜치를 설정하고 리더에게 PR을 제출하는 방법에 대해 설명합니다. 모두에게 도움이 되기를 바랍니다.

보호 브랜치를 설정하는 방법

보호 브랜치는 무엇을 위한 것인가요?

앞서 git flow 워크플로에서 소개했듯이 master|main(메인 브랜치) 브랜치는 모든 개발자가 마음대로 메인 브랜치에 코드를 푸시할 수 있는 경우 온라인 브랜치입니다. 때로는 개발자가 실수로 온라인에 접속할 필요가 없는 코드(버그가 많을 수 있음)를 메인 브랜치에 푸시하고 온라인에 접속할 때 가져오는 경우 발생한 피해는 복구할 수 없을 수도 있습니다. 따라서 푸시를 허용하지 않도록 메인 브랜치를 설정해야 하며, PR을 통해서만 코드를 메인 브랜치에 병합할 수 있습니다. master｜main（主分支）分支是上线分支，如果每个开发人员都能随意的在主分支push代码，假如上线的时候，哪个开发不小心把自己不需要上线的代码（有可能有很多bug）push到了主分支，上线的时候一起带上去了，那么造成的损失有可能无法挽回。所以我们需要设置主分支不允许push，只能通过PR的方式把自己的代码合并到主分支。

下面我们来操作一下。在项目中找settings->Repository->Protected branches，选择受保护的分支，这里我们的主分支是main，然后选择merge权限为Maintainers，不允许任何人push代码到主分支。最后点击profect

下面我们来push一下代码试试

可以很明显的看到，已经不让任何人推送代码了。要推送代码，只能另外新建分支去推送到远程，然后把代码合并到主分支。

如何提交Merge request

为什么会有Merge reqeust呢？

前面提到，main分支是我们的保护分支，已经不需要本地push代码，那么我们的代码如何合并到主分支呢？这时候就需要开发人员发起一个Merge reqeust来把我们的代码合并到main分支了。Merge request还有一个用途非常重要，那就是code review。

何为code review呢？

code review翻译过来就是代码审查。一个公司，一个团队，对代码是有规范的，对代码是有要求的，对质量是有要求的，你写的代码是要经过你的leader审查的，才能合并到主分支，所以这一步操作在你主管合并之前，会吧你写的代码肉眼过一遍，确保不会出现重大线上问题才会给你合并，如果有问题，会让你重新改代码重新提交Merge requst，直到符合上线要求。这样做的目的呢，也是为了保证上线不出问题，毕竟出了重大的线上bug，你的leader是要承担责任和风险的，问题严重的部门领导也跟着倒霉。所以，我们写代码的同时也要非常的严谨。

讲了这么多，下面我们实际操作一下。

在本地新建一个dev分支，然后修改一些东西push到远程，首次推送需要使用git push -u origin dev，因为远程没有这个分支。

刷新页面可以看到，我们现在在main分支，上面显示一个Create merge request按钮，这里就是我们发起merge请求的地方，点击一下

进入到merge页面，这里我们可以看到我们现在是想把dev分支merge到main分支，如果想合并其他的分支，点击change branches即可修改。title和description可以填写你提交merge相关的功能描述。

Assignee和Reviewer为受让人和审查人员，直白一点就是想的代码谁给你审查，你就选择谁。

这里可以看到你本次合并提交的commit信息和修改内容

最后，点击Create merge request，即可发起一个merge请求，剩下的事情就是你的leader审查代码了。

你的leader看到的merge信息是这样子的，这里他可以看到你的commits和changes，从而看到你的代码的修改内容。如何没有问题，点击Merge

지금 해보자. 프로젝트에서 설정->저장소->보호된 분기를 찾아 보호된 분기를 선택합니다. 그런 다음 기본 분기를 선택합니다. 누구도 메인 브랜치에 코드를 푸시할 수 없도록 관리자로서 병합 권한을 부여합니다. 마지막으로 profect🎜🎜를 클릭하세요. 코드를 푸시해서 사용해 보세요🎜🎜아무도 코드를 푸시할 수 없다는 것을 분명히 알 수 있습니다. 코드를 푸시하려면 새 브랜치를 생성하여 원격으로 푸시한 다음 코드를 기본 브랜치에 병합하면 됩니다. 🎜

🎜병합 요청 제출 방법🎜🎜🎜병합 요청이 있는 이유는 무엇인가요? 🎜🎜앞서 언급했듯이 메인 브랜치는 보호되는 브랜치이므로 로컬 푸시 코드가 필요하지 않습니다. 그렇다면 코드를 메인 브랜치에 병합하려면 어떻게 해야 할까요? 이때 개발자는 코드를 메인 브랜치에 병합하기 위해 병합 요청을 시작해야 합니다. 병합 요청에는 코드 검토라는 또 다른 매우 중요한 목적이 있습니다. 🎜🎜🎜🎜코드 리뷰🎜란 무엇인가요? 🎜🎜🎜코드 검토는 코드 검토로 번역됩니다. 회사, 팀에는 코드에 대한 표준, 코드에 대한 요구 사항, 품질에 대한 요구 사항이 있습니다. 작성한 코드는 메인 브랜치에 병합되기 전에 리더의 검토를 받아야 하므로 이 단계는 담당하기 전에 완료됩니다. 병합할 때, 여러분이 작성한 코드를 육안으로 살펴보고 병합하기 전에 온라인에 큰 문제가 없는지 확인하겠습니다. 문제가 있는 경우 코드를 변경하여 를 다시 제출하라는 메시지가 표시됩니다. 온라인 요구 사항이 충족될 때까지 요청을 병합하세요. 결국 온라인에서 큰 버그가 발생하면 리더가 책임과 위험을 감수해야 하고, 심각한 문제를 안고 있는 부서 리더도 어려움을 겪게 되기 때문이다. 그러므로 우리는 코드를 작성할 때 매우 엄격해야 합니다. 🎜🎜 말은 많이 했으니 실제로 해보자. 🎜🎜로컬에서 새 dev 브랜치를 생성한 다음 원격으로 push를 수정해야 합니다. git push -u Origin dev를 사용해야 합니다. 첫 번째 푸시의 경우 리모컨에 이 분기가 없기 때문입니다. 🎜🎜페이지를 새로 고치면 이제 병합 요청 만들기 버튼이 표시된 메인 브랜치에 있는 것을 볼 수 있습니다. 여기에서 병합 요청을 시작합니다🎜🎜🎜🎜병합 페이지로 들어가세요. 여기에서 이제 원하는 것을 볼 수 있습니다. dev 브랜치를 main 브랜치에 병합하세요. 다른 브랜치를 병합하려면 브랜치 변경을 클릭하여 수정하세요. . 제목 및 설명은 제출한 병합과 관련된 기능 설명을 채울 수 있습니다. 🎜🎜🎜🎜담당자 및 Reviewer는 담당자이자 검토자입니다. 직설적으로 말하면 원하는 코드를 검토하는 사람을 선택하면 됩니다. 🎜🎜🎜🎜보실 수 있습니다 여기 이 병합을 위해 제출한 커밋 정보 및 수정 사항입니다🎜🎜🎜🎜🎜 🎜마지막으로 병합 요청 만들기를 클릭하여 병합 요청을 시작하세요. 나머지는 리더가 코드를 검토하는 것입니다. 🎜🎜당신의 리더가 보는 병합 정보는 다음과 같습니다. 여기서 그는 당신의 커밋과 변경 사항, 그리고 코드 수정 사항을 볼 수 있습니다. 문제가 없으면 병합 버튼을 눌러 병합하세요. 🎜

위는 Merge reqeust완성 과정과 그 중요성입니다.

병합 프로세스에는 코드 사양의 린트 확인, 코드 단위 테스트 등과 같은 일부 CI/CD 작업이 포함될 수도 있습니다. 이에 대해서는 나중에 하나씩 논의하겠습니다.

(학습 영상 공유: 기본 프로그래밍 영상)

위 내용은 Gitlab에서 보호 브랜치를 설정하고 PR을 제출하는 방법에 대해 이야기해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!