MQL5 Algo Forge로 이동하기(2부): 여러 리포지토리로 작업하기

소개

첫 번째 글에서 우리는 MetaEditor에 내장된 SVN 기반의 MQL5 저장소에서 Git 버전 제어 시스템을 기반으로 하는 보다 유연하고 현대적인 솔루션으로 전환하기 시작했습니다: MQL5 Algo Forge. 이 단계를 거친 주된 이유는 여러 프로젝트 또는 단일 프로젝트 내에서 서로 다른 기능으로 작업하는 동안 리포지토리 브랜치를 충분히 활용해야 했기 때문입니다.

전환은 MQL5 Algo Forge에 새로운 리포지토리를 생성하고 필요한 MQL5 및 Git 확장 및 지원 도구와 함께 Visual Studio Code를 사용하여 로컬 개발 환경을 설정하는 것으로 시작되었습니다. 그런 다음 버전 관리에서 표준 파일과 임시 파일을 제외하기 위해 리포지토리에 .gitignore 파일을 추가했습니다. 기존의 모든 프로젝트는 이전에 작성된 모든 코드의 보관 저장소로 지정된 전용 아카이브 브랜치에 업로드 되었습니다. main 브랜치는 비워두었고 새로운 프로젝트 브랜치를 구성할 준비를 했습니다. 이러한 방식으로 우리는 리포지토리의 여러 브랜치에 서로 다른 프로젝트 코드를 배포할 수 있는 기반을 마련했습니다.

그러나 첫 번째 기사가 게시된 이후 MetaEditor는 새로운 리포지토리 시스템에 대한 지원을 크게 확장했습니다. 이러한 변화로 인해 이전에 설명한 접근 방식을 재고하게 되었습니다. 따라서 이 글에서는 원래 계획에서 약간 벗어나 다른 공개 프로젝트를 구성 요소로 통합하는 공개 프로젝트를 만드는 방법을 살펴봅니다. 우리가 집중할 프로젝트는 다중 통화 EA의 개발입니다. 이 프로젝트를 위한 코드 개발 및 수정에 대한 접근 방식을 설명하는 여러 기사가 이미 게시되어 있습니다. 이제 우리는 Git 버전 관리를 최대한 활용하여 개발 프로세스를 체계화하고 간소화할 것입니다.

경로 매핑

믿기 어려우시겠지만 제가 이전 글을 작성할 당시 MetaEditor에는 아직 MQL5 Algo Forge 리포지토리 작업을 위한 "Git: 메뉴 또는 파일 컨텍스트 메뉴 명령이 포함되어 있지 않았습니다. 그 결과 Visual Studio Code와 같은 외부 도구를 사용하여 워크플로를 구성하는 데 상당한 노력이 필요했습니다. 우리는 MetaEditor가 결국 어떻게 리포지토리 지원을 구현할지 알 수 없었기 때문에 다른 사용 가능한 도구를 사용해야 했습니다.

그 이후로 새로운 MetaEditor 릴리스에는 MQL5 Algo Forge에 대한 기본 지원이 도입되었습니다. MetaQuotes는 또한 기본 사항을 설명하고 주요 기능을 시연하는 새 문서 'MQL5 Algo Forge 시작하기'를 게시했습니다. 하지만 우리가 보기에 가장 중요한 발전은 MetaEditor에서 공유 프로젝트를 구현한 것입니다.

이것이 중요한 이유는 무엇인가요? 이전에는 MQL5 폴더가 MQL5 Algo Forge의 Git 서버에서 호스팅 되는 리포지토리 역할을 했었습니다. 분명히 이 리포지토리의 이름은 mql5로 고정되어 있었을 것입니다. 즉 각각의 사용자는 Algo Forge에 mql5라는 이름의 저장소를 갖게 되었을 것입니다. 그런 다음 새로운 터미널을 설치하고 커뮤니티에 로그인한 후 리포지토리를 연결하면 이 리포지토리가 MQL5 폴더에 복제되었을 것입니다. 동시에 MQL5 Algo Forge는 항상 추가 저장소를 생성할 수 있도록 허용했었습니다. 더 정확하게는 추가 리포지토리가 아닌 별도의 리포지토리로 mql5 리포지토리와 관련이 없었습니다. 당연히 이러한 다른 리포지토리를 MetaEditor는 어떻게 처리할 것인가 하는 의문이 들게 했습니다. 

터미널을 설치할 때마다 어떤 리포지토리를 사용할지 사용자가 선택할 수 있게 해야 하나요? 다른 방법이 있나요? 사용자가 각기 다른 프로젝트의 브랜치로 작업을 분리해야 하는 상황에서 mql5 리포지토리만 지원될까요? 저희는 처음에 이 최악의 시나리오에 대비했습니다. 하나의 리포지토리에서 여러 브랜치에 걸쳐 여러 프로젝트를 관리하는 것은 그리 편리하지 않습니다. 다행히도 저희의 우려는 기우였음이 밝혀졌습니다.

MetaQuotes는 두 가지 문제를 한 번에 효과적으로 해결할 수 있는 보다 우아한 솔루션을 도입했습니다. 하나는 mql5라는 이름의 메인 리포지토리입니다. 이는 이미 MQL5 스토리지에 익숙한 사용자에게 적합합니다. 이제 어떤 버전 관리 시스템을 사용하는지 걱정하지 않고 버전 관리를 계속 사용할 수 있습니다.

반면에 다른 모든 사용자 리포지토리는 이제 공유 프로젝트 안의 폴더로 사용할 수 있습니다. 이는 사용자의 추가 리포지토리에 있는 코드를 저장하기 위한 기존 폴더(예: MQL5, MQL5/Experts, MQL5/Include 등)와 함께 새로운 표준 루트 폴더를 제공합니다.

예를 들어 보겠습니다. MQL5 Algo Forge에 두 개의 별도 리포지토리가 있고 그 중 어느 것도 기본 mql5가 아니라고 가정해 보겠습니다. 첫 번째 리포지토리 Adwizard)에는 라이브러리 코드, 즉 *.mqh 포함 파일만 있고 Expert Advisor 또는 지표로 컴파일 될 수 있는 *.mq5 파일은 없습니다. 두 번째 리포지토리Simple Candles)에는 첫 번째 리포지토리의 include 파일을 사용하는 *.mq5 파일이 포함되어 있습니다. 구분을 위해 첫 번째 리포지토리를 라이브러리 리포지토리, 두 번째 리포지토리를 프로젝트 리포지토리라고 하겠습니다.

우리의 목표는 프로젝트 저장소 내에서 개발하는 동안 라이브러리 저장소의 코드를 사용하는 방법을 결정하는 것입니다. 예를 들어 mql5.com 코드 베이스에서 공유되는 코드가 작성자에 의해 MQL5 Algo Forge의 공용 리포지토리로 미러링 되는 경우 이 시나리오는 점점 더 일반화될 수 있습니다. 이러한 경우 하나 이상의 리포지토리를 외부 라이브러리로 프로젝트에 연결하면 이 글에서 살펴보려는 것과 같은 방식으로 처리될 수 있습니다.

시작하기

먼저 두 리포지토리를 모두 소유하고 있는 개발자의 관점에서 상황을 살펴봅시다. 즉 풀 리퀘스트 메커니즘을 통해 검토와 승인을 기다릴 필요 없이 어느 리포지토리에서나 코드를 자유롭게 변경할 수 있습니다. 먼저 깨끗한 터미널 폴더를 만들고 이전에 설치된 MetaTrader 5 복사본에서 두 개의 파일을 복사합니다:

파일 시스템 깊숙한 곳에서 검색하지 않으려면 터미널을 포터블 모드로 실행하는 것이 좋습니다. Windows에서는 터미널의 실행 파일에 대한 바로 가기를 만들고 바로 가기 속성에서 대상 필드에 /portable 플래그를 추가하는 것이 한 가지 방법입니다. 

터미널을 실행한 후 만일을 대비하여 새로운 데모 계정을 열고 최신 버전으로 업데이트한 다음 커뮤니티에 로그인하고 F4 키를 눌러 MetaEditor를 실행합니다. 아직 자동으로 연결되지 않은 경우 MQL5 Algo Forge를 연결합니다.

이제 내비게이터에 이전에 웹 인터페이스를 통해 만든 리포지토리가 나열된 '공유 프로젝트' 폴더가 표시됩니다. 그러나 탐색기에서 이 폴더를 열면 여전히 비어 있습니다. 이는 실제 리포지토리 파일이 아직 컴퓨터에 다운로드 되지 않았음을 의미합니다.

복제하려면 필요한 리포지토리를 각각 마우스 오른쪽 버튼으로 클릭하고 메뉴에서 "Git Clone(깃 복제)"을 선택합니다. 로그에서 Adwizard와 Simple Candles 모두 복제에 성공했음을 확인할 수 있습니다. 이제 복제된 리포지토리가 있는 폴더가 탐색기에 나타납니다:

이 시점에서 두 프로젝트의 코드는 로컬에서 사용할 수 있게 됩니다.

첫 번째 문제

SimpleCandles.mq5를 열고 컴파일해 보겠습니다:

예상대로 컴파일 오류가 발생합니다. 그 이유를 이해해 알아보겠습니다. 우리는 이전에 코드가 성공적으로 컴파일 된 것을 알고 있습니다. 그러므로 이는 중요하지 않습니다. 변경된 것은 라이브러리와 프로젝트 파일의 상대적 배치 뿐입니다. 처음 두 가지 근본적인 오류는 컴파일러가 라이브러리 파일을 예상한 위치에서 찾을 수 없다는 사실에서 비롯됩니다. 28부에서 우리는 라이브러리와 프로젝트 파트를 저장할 때 다음과 같은 폴더 구조를 사용하기로 했습니다:

즉 라이브러리 저장소를 프로젝트 저장소의 하위 폴더에 저장합니다. 이를 통해 우리는 라이브러리 파일을 찾는 데 예측 가능한 구조를 만들 수 있었습니다. 하지만 이번에는 이를 변경할 예정입니다. 프로젝트 내에서 필수 Include 하위 폴더를 사용하는 대신 MQL5/Shared Projects 폴더를 사용합니다. 이상적이게도 이 폴더는 안정적으로 유지되며 향후 MetaEditor 버전에서도 동일한 용도로 계속 사용됩니다.

이 문제를 해결하기 위해 두 파일에서 #include 지시문을 업데이트합니다. 하지만 코드를 변경하기 전에 좋은 개발 관행을 따라봅시다. 이 격리된 작업을 위한 별도의 브랜치를 만들어 보세요. 수정 사항이 테스트 되면 브랜치를 다시 메인 개발 브랜치에 병합할 수 있습니다.

프로젝트 리포지토리에 이미 어떤 브랜치가 있는지 살펴봅시다. 이 작업은 여러 가지 방법으로 수행할 수 있습니다:

• MetaEditor에서 리포지토리 폴더의 컨텍스트 메뉴를 통해: 

• 리포지토리의 브랜치 페이지에 잇는 웹 인터페이스를 통해

• Visual Studio Code와 같은 외부 Git 도구 사용. 리포지토리 이름 옆에는 현재 브랜치의 이름인 main이 표시됩니다. 클릭하면 사용 가능한 브랜치 목록(및 새 브랜치 생성을 위한 메뉴 항목)이 표시됩니다:

현재 리포지토리에는 4개의 브랜치가 있습니다:

• main - 기본 브랜치입니다. 리포지토리와 함께 생성됩니다. 가장 간단한 경우에는 추가 브랜치를 만들지 않고도 여기에서 모든 작업을 수행할 수 있습니다. 더 복잡한 경우 이 브랜치는 안정적인 버전인 코드를 제공하는 파일의 상태를 저장하는 데 사용됩니다. 아직 완료 및 테스트가 완료되지 않은 변경 사항은 다른 브랜치에서 작업 중이게 됩니다.
• develop - 개발 브랜치입니다. 간단한 경우에는 변경 사항을 추가하고 새로운 기능을 구현하는 유일한 브랜치로 사용할 수 있습니다. 새로운 기능이 순차적으로 구현되는 경우 이 옵션으로 충분합니다. 즉 이전의 기능을 추가한 후 프로젝트가 완전히 작동하고 안정적인 상태가 될 때까지 새로운 기능 구현을 시작하지 않습니다. 새 기능에 대한 작업을 시작하기 전에 브랜치가 병합됩니다. develop 브랜치에서 편집한 내용이 main 브랜치에 병합됩니다. 여러 기능을 동시에 개발하는 경우 하나의 개발 브랜치에서 작업하는 것이 불편해집니다. 이러한 경우 추가로 기능 브랜치를 만들 수 있습니다.
• 예시 또는 이러한 브랜치는 article-17608-close-manager 및 article-17607입니다. 전자는 수익/손실 임계값에 기반한 포지션 청산 로직을 위한 기능 분기입니다. 이 브랜치는 이미 develop로 병합되어 있고 develop는 다시 main으로 병합되어 있습니다. 두 번째 기능 브랜치는 자동화된 최적화를 개선하는 데 사용됩니다. 아직 개발 중이며 아직 develop 또는 main에 병합되지 않은 상태입니다.

Git은 특정 브랜치 사용 규칙을 강제하지 않는다는 점을 강조하고 싶습니다. 따라서 우리는 가장 편리한 옵션을 선택할 수 있습니다. 일부 개발자가 유용하다고 판단하여 다른 개발자와 공유한 특정 워크플로우들이 있습니다. 이것이 '모범 사례'가 표시되는 방식입니다. 적합한 브랜칭 모델을 프로젝트에 자유롭게 채택하거나 조정할 수 있습니다. 예를 들어 여기 기사에 설명된 제안된 분기 원칙 중 하나를 살펴보세요.

이제 리포지토리로 돌아가 보겠습니다.

의문을 제기할 수 있는 한 가지 세부 사항은 접두사 origin/ (또는 MetaEditor에 표시된 것처럼 refs/remotes/origin/ )입니다. 이 접두사는 브랜치가 단순히 로컬뿐만 아니라 원격 리포지토리에도 존재함을 나타냅니다. 일반적으로 로컬 브랜치와 원격 브랜치는 동기화 상태를 유지합니다. MetaEditor에서 커밋 명령을 실행하면 자동으로 Push 명령이 트리거되어 커밋이 원격 리포지토리로 전송됩니다.

MetaEditor 외부에서 커밋을 수행하는 경우 푸시하지 않고 로컬에서 커밋할 수 있습니다. 이러한 경우 이름이 같은 로컬 브랜치와 원격 브랜치는 다를 수 있습니다. origin/접두사는 이들을 구분하는 데 도움이 됩니다. 이 접두사는 원격 리포지토리에 있는 브랜치를 의미하며 그렇지 않으면 로컬 브랜치입니다.

새로운 브랜치 만들기

계획된 편집은 라이브러리 부분의 배치가 변경된 후에만 코드가 올바르게 컴파일되도록 보장하므로 develop에서 생성된 새 브랜치를 기반으로 합니다. 로컬 develop 브랜치로 목록에 표시 된후 origin/develop로 전환합니다.

그런 다음 새로운 브랜치를 만들고(New 명령 실행) 원하는 이름을 입력합니다. 관례에 따라 문서 관련 브랜치는 문서와 해당 문서의 고유 식별자를 더한 문서로 시작합니다. 선택적으로 글의 주제를 설명하는 짧은 접미사를 뒤에 붙일 수 있습니다. 그래서 새 브랜치의 이름은 "article-17698-forge2"입니다.

웹 인터페이스 Visual Studio Code 인터페이스 또는 명령줄 인터페이스 등 다른 방법으로도 브랜치를 만들 수 있으며 리포지토리의 루트 폴더에 있는 명령줄에서 실행할 수 있습니다:

git checkout -b article-17698-forge2 develop

이렇게 하면 Git에게 develop 브랜치를 기반으로 article-17698-forge2라는 새로운 브랜치(-b)로 전환(체크 아웃)하도록 지시하는 것입니다.

웹 인터페이스 외부에서 브랜치를 만들면 원격 리포지토리로 처음 푸시할 때까지 로컬 컴퓨터에만 브랜치가 존재합니다. 그 반대도 마찬가지입니다. 웹 인터페이스를 통해 원격 리포지토리에 브랜치를 만들면 원격 리포지토리에서 처음 pull 할 때까지 로컬 머신에 브랜치가 나타나지 않습니다.

다음과 같이 변경 사항을 푸시 할 수 있습니다:

또는 이와 같이:

Push 작업에 대한 콘솔 명령에 새 브랜치 만들기가 포함된 경우 원격 리포지토리에 브랜치를 실제로 만들 것인지 확인하는 추가 매개변수가 포함되어야 합니다:

git push --set-upstream origin article-17698-forge2

그 후 브랜치는 리포지토리의 로컬 복사본과 MQL5 Algo Forge에서 호스팅 되는 원격 리포지토리에 모두 존재합니다. 이 시점에서 우리는 다른 브랜치의 기능을 손상시킬 염려 없이 편집을 시작할 수 있습니다.

변경하기

필요한 수정 사항은 매우 간단합니다. SimpleCandles.mq5 파일에서 Adwizard 라이브러리의 파일이 포함된 줄을 업데이트합니다. 이제 Simple Candles 및 Adwizard 저장소의 루트 폴더가 공유 프로젝트 폴더 내에서 같은 레벨에 위치하므로 라이브러리 저장소의 하위 폴더로 내려가기 전에 먼저 Expert.mqh 경로를 한 레벨 위(../)로 이동해야 합니다:

#include "Include/Adwizard/Experts/Expert.mqh"
#include "../Adwizard/Experts/Expert.mqh"

Strategies/SimpleCandlesStrategy.mqh 파일에서도 비슷한 조정이 필요합니다:

#include "../Include/Adwizard/Virtual/VirtualStrategy.mqh"
#include "../../Adwizard/Virtual/VirtualStrategy.mqh"

이러한 변경 후 SimpleCandles.mq5가 다시 성공적으로 컴파일 됩니다. 이제 변경 사항을 리포지토리에 커밋할 수 있습니다:

앞서 언급했듯이 MetaEditor 인터페이스를 통해 커밋할 때 Push 명령이 자동으로 실행되어 MQL5 Algo Forge의 원격 리포지토리로 변경 사항을 전송합니다.

콘솔 명령으로 작업할 때 우리는 다음과 같은 결과를 얻을 수 있습니다. 기존 파일을 편집하는 것 외에 새 파일을 만든 경우에는 먼저 리포지토리 인덱스에 파일을 추가해야 합니다:

git add .

이 명령은 리포지토리 폴더에 있는 모든 새로운 파일을 추가합니다. 특정 파일만 추가하려면 점(.)을 해당 파일 이름으로 바꾸세요. 그런 다음 지정된 주석과 함께 변경 사항을 커밋하고 원격 리포지토리에 푸시합니다:

git commit -m "Adwizard에서 파일을 포함하도록 상대 경로 수정"
git push

이 시점에서 article-17698-forge2 브랜치의 변경이 완료되었습니다. develop 브랜치에 병합한 다음 끝낼수 있습니다.

두 번째 문제

여기서 우리는 불쾌한 놀라움에 직면하게 됩니다. 현재 MetaEditor에는 브랜치 병합을 위한 도구가 없습니다. 즉 이제 새 브랜치를 만들 수는 있지만 한 브랜치에서 다른 브랜치로 변경 사항을 전송할 수는 없습니다! 조만간 이 기능이 추가되기를 바랍니다. 지금은 리포지토리 작업을 수행하기 위해 다시 한번 대체 도구로 전환해야 합니다.

브랜치를 병합하는 방법에는 크게 두 가지가 있습니다. 첫 번째는 Visual Studio Code 또는 표준 콘솔 명령의 병합 인터페이스를 사용하는 것입니다. 이 경우 다음 명령을 사용할 수 있습니다:

git checkout develop
git pull
git merge --no-ff article-17698-forge2

먼저 develop 브랜치로 전환합니다. 그런 다음 예방 조치로 (아직 로컬 컴퓨터에 도달하지 않은 변경 사항이 있는 경우) 이를 업데이트합니다. 마지막 명령은 실제 병합을 수행합니다. 병합 충돌이 발생할 수 있지만 우리의 시나리오에서는 한 명의 개발자가 프로젝트를 진행하는 경우를 고려하고 있습니다. 그러므로 여러 위치에서 작업하는 경우에도 정기적으로 리포지토리를 최신의 상태로 업데이트하면 충돌이 발생하지 않을 것입니다.

그러나 이 방법의 미묘한 뉘앙스에 대해서는 우선 넘어가겠습니다. 대신 두 번째 접근 방식에 대해 자세히 살펴보겠습니다. 여기서는 MQL5 Algo Forge 웹 인터페이스를 사용합니다.

병합을 위한 풀(Pull) 리퀘스트 사용

다른 Git 기반 플랫폼(예: GitHub, GitLab 또는 Bitbucket)과 마찬가지로 MQL5 Algo Forge에는 풀 리퀘스트(PR)라는 메커니즘이 포함되어 있습니다.

풀 리퀘스트를 사용하면 개발자가 브랜치에서 변경한 내용을 리포지토리로 병합할 것을 제안할 수 있습니다. 즉 PR을 만드는 것은 리포지토리 소유자 및 다른 기여자에게 알리는 방법입니다: "내 지점에서 작업을 완료했으니 이 변경 사항을 검토하여 main 브랜치(main/master/develop)에 병합해 주세요."

PR은 Git 자체의 기능이 아니라 그 위에 구축된 추가 계층입니다. 변경 사항이 main 브랜치에 병합되기 전에 코드 검토 및 토론 프로세스를 구성합니다.

또한 풀 리퀘스트는 자동화된 테스트를 통한 지속적인 통합(CI), 다른 개발자의 품질 관리, 특정 수정이 이루어진 이유를 설명하는 PR 댓글 형태의 변경 사항 문서화 등 최신 개발에서 중요한 몇 가지 다른 작업도 해결합니다. 이러한 수행방식은 팀 기반 프로젝트에 가장 적합한데 비해 MQL5 프로젝트는 일반적으로 개별 프로젝트입니다. 어쨌든 앞으로 공동 작업 프로젝트가 등장하게 되면 워크플로우의 중요성이 더욱 커질 수 있습니다.

우리는 PR을 사용하여 새로운 기능이나 수정 사항을 추가하는 일반적인 워크플로우의 시작을 이미 복제했습니다:

1. 최신 변경 사항을 풀 합니다. 작업을 시작하기 전에 로컬 develop 브랜치를 업데이트했습니다.

2. 작업에 대한 새로운 브랜치를 만듭니다. 업데이트된 develop 브랜치에서 이름 article-17698-forge2로 브랜치를 만들었습니다.

3. 새 브랜치에서 변경합니다. 여러 파일을 수정하고 테스트한 다음 변경 사항을 커밋했습니다.

다음 단계는 다음과 같습니다.

4. 풀 리퀘스트를 만듭니다. MQL5 Algo Forge 웹 인터페이스에서 풀 리퀘스트 탭으로 이동하여 빨간색의 큰 '새 풀 리퀘스트' 버튼을 클릭합니다.

그러면 브랜치 선택 페이지가 열립니다. 이 단계에서는 아직 PR이 생성되지 않았으므로 먼저 변경 사항을 병합할 위치를 정의해야 합니다. 브랜치를 선택하면 변경 사항 목록을 검토할 수 있습니다. 그런 다음 '새 풀 리퀘스트'를 다시 클릭합니다.

변경 사항에 대한 자세한 설명을 제공하는 새 페이지가 열립니다. 여기에서 검토자를 지정할 수도 있습니다. 기본적으로 요청은 우리 자신에게 전달되며, 이 경우에 필요한 것이 바로 이 요청입니다.

5. 검토 및 토론. 우리는 혼자 작업하는 것을 가정하고 있습니다. 그러므로 이 단계는 건너뛸 수 있습니다. 일반적으로 이 단계에는 다음이 포함됩니다:

   • 코드를 검토하고 코멘트를 남기는 리뷰어(일반적이거나 특정 줄에 연결된)입니다,

   • 같은 브랜치에서 댓글에 응답하고 수정하는 PR 작성자가 있습니다,

   • 모든 새 푸시가 기존 PR에 자동으로 추가됩니다.

6. 병합. 검토자가 승인(있는 경우)하고 CI가 통과(구성된 경우)하면 PR을 병합할 수 있습니다. 일반적으로 여러 가지 병합 옵션이 있습니다:

• Merge commit: 별도의 병합 커밋을 생성하여 브랜치 기록을 보존합니다.

• 스쿼시 및 병합: 모든 PR 커밋을 대상 브랜치에 추가된 단일 커밋으로 결합합니다. "오타 수정"과 같은 사소한 커밋으로 기록이 복잡해지는 것을 방지하는 데 유용합니다.

• 리베이스 및 병합: 대상 브랜치(이 경우에는 develop 브랜치) 위에 PR 커밋을 다시 적용합니다. 이렇게 하면 깔끔하고 선형적인 기록이 생성됩니다.

여기서 우리는 전체 커밋 기록을 보존하기 위해 첫 번째 옵션을 선택하겠습니다. 이를 위해 'Create merge commit'를 클릭합니다.

이제 풀 리퀘스트 작업의 마지막 페이지가 나옵니다. 여기서 '브랜치 삭제 ...' 옵션을 체크하여 임시 개발 브랜치를 닫습니다. 커밋 기록에는 여전히 브랜치가 존재했다는 사실이 반영됩니다. 우리는 목표를 달성했기 때문에 계속 열어 두는 것은 아무런 의미가 없습니다. 향후 다른 작업을 해결하기 위해 우리는 새로운 브랜치를 만들 예정입니다. 이렇게 하면 리포지토리의 브랜치 목록에서 현재 진행 중인 병렬 작업에 대한 명확한 스냅샷을 항상 확인할 수 있습니다.

나머지 설정은 그대로 두고 'Create merge commit'를 클릭합니다.

이제 프로세스가 완료되었습니다. article-17698-forge2 브랜치가 develop 브랜치에 병합되어 삭제되었습니다:

일반적으로 개인 프로젝트의 경우에도 자체 리포지토리에서 풀 리퀘스트를 사용하는 것이 좋으며 권장됩니다. 병합하기 전에 모든 변경 사항을 시각적으로 검토하여 커밋 중에 놓친 사항(불필요한 주석, 길 잃은 파일 또는 최적이 아닌 편집)을 찾아낼 수 있습니다. 본질적으로 이것은 일종의 자기 훈련입니다. 또한 이 워크플로우를 채택하면 브랜칭, 코드 검토 등에서 좋은 습관을 기를 수 있습니다. 따라서 나중에 개발팀에 합류한다면 이 프로세스는 이미 익숙해져 있을 것입니다.

따라서 모든 프로젝트에서 PR을 직접 제출하는 것은 가능할 뿐만 아니라 권장됩니다. 왜냐하면 이를 통해 코드 품질을 개선하고 규율을 강화합니다. 물론 한두 개의 커밋으로 구성된 빠른 수정의 경우 여러분은 git merge로 바로 병합할 것입니다. 하지만 더 큰 변경시에는 PR이 더 나은 접근 방식입니다.

결론

전반적으로 개인 리포지토리를 사용하는 워크플로는 이제 잘 정립되었습니다. 리포지토리 복제부터 변경 사항이 코드의 기능을 유지하고 추가 개발을 위한 준비가 되게 하는 프로세스를 개선하는 과정까지 살펴봤습니다. 이제 프로젝트 리포지토리에서 다른 리포지토리(또는 여러 리포지토리)의 코드를 라이브러리로 의미 있게 사용할 수 있습니다.

하지만 우리는 동일한 사용자가 프로젝트와 라이브러리 리포지토리를 모두 소유하고 있는 경우라는 한 가지 시나리오만 고려했습니다. 다른 시나리오는 프로젝트 소유자가 다른 사람의 리포지토리를 라이브러리로 사용하려는 경우입니다. 이 경우는 그렇게 간단하지 않습니다. 커뮤니티 코드의 활발한 재사용과 협업을 통한 이러한 워크플로야말로 새로운 리포지토리 시스템으로 전환한 목표 중 하나였습니다. 그 기반은 마련되었습니다.

지금은 여기서 멈추겠습니다. 다음 편에서 뵙겠습니다!