MQL5 Algo Forge로 이동하기(4부): 버전 및 릴리스 작업

소개

MQL5 Algo Forge로의 전환은 계속 진행 중입니다. 우리는 개인 리포지토리로 워크플로우를 설정했으며 그 이유는 커뮤니티에서 기여한 코드를 쉽게 사용할 수 있는 기능을 사용하기 위해서입니다. 3부에서 우리는 다른 리포지토리의 공용 라이브러리를 자체 프로젝트에 추가하는 방법을 살펴봤습니다.

SmartATR 라이브러리를 SimpleCandles Expert Advisor에 연결하는 실험을 통해 단순 복제가 항상 편리한 것은 아니며 특히 코드 수정이 필요한 경우 더욱 그러하다는 것을 분명히 알 수 있었습니다. 대신 적절한 워크플로우를 따랐습니다: 우리는 다른 사람의 리포지토리가 우리의 개인 복사본이 되는 포크를 만들어 버그를 수정하고 수정하는 한편 나중에 풀 리퀘스트를 통해 이러한 변경 사항을 작성자에게 제안할 수 있는 옵션을 보존했습니다.

MetaEditor 인터페이스에 몇 가지 한계가 있었지만 MQL5 Algo Forge 웹 인터페이스와 결합하여 복제부터 편집 내용을 커밋하고 최종적으로 외부 라이브러리와 프로젝트에 연결하는 것까지의 전체 작업 과정을 성공적으로 완료할 수 있었습니다. 이러한 특정한 작업을 해결하고 타사의 구성 요소를 통합하기 위한 범용 템플릿을 만들었습니다.

이 기고글에서는 프로젝트에 새로운 기능을 추가하거나 발견된 문제를 수정하는 등 완전한 솔루션을 구성하는 데에 필요한 여러 변경 사항을 리포지토리에 게시하는 단계에 대해 자세히 살펴보고자 합니다. 이는 새 제품 버전을 커밋하거나 릴리스하는 프로세스입니다. 이 프로세스를 구성하는 방법과 이를 위해 MQL5 Algo Forge가 어떠한 기능을 제공하는지 살펴보겠습니다.

브랜치 찾기

이전 파트에서는 특정 작업과 관련한 일련의 편집을 할 때 별도의 리포지토리 브랜치를 사용하는 것을 권장했습니다. 그러나 이러한 브랜치에서 작업을 완료한 후에는 다른 (메인) 브랜치에 해당 브랜치를 병합한 다음 삭제하는 것이 가장 좋습니다. 그렇지 않으면 리포지토리는 소유자조차도 쉽게 작업의 위치나 과정을 잃을 수 있게 됩니다. 따라서 쓸모없는 브랜치는 제거해야 합니다. 그러나 때로는 특정 브랜치가 삭제되기 직전의 상태로 코드를 되돌리는 것이 필요할 때가 있습니다. 어떻게 하나요?

먼저 브랜치는 단순히 시간순으로 정렬된 일련의 커밋이라는 점을 명확히 해두겠습니다. 엄밀히 말하면 브랜치는 연속된 커밋의 연속에서 가장 최근의 커밋으로 간주되는 커밋을 가리키는 포인터입니다. 따라서 브랜치를 삭제해도 커밋 자체는 삭제되지 않습니다. 최악의 경우 다른 브랜치로 재할당 되거나 하나의 요약 커밋으로 병합될 수도 있지만 어떤 경우든 리포지토리에 계속 존재합니다(드문 예외가 있습니다). 따라서 "브랜치를 삭제하기 전"의 상태로 돌아간다는 것은 어떤 브랜치에 존재하는 커밋 중 하나로 되돌아간다는 의미입니다. 그렇다면 그 커밋을 어떻게 찾을 수 있을까요?

3부에서 살펴본 변경 사항이 적용된 후의 SimpleCandles 리포지토리의 상태를 살펴보겠습니다:

왼쪽에서 커밋의 히스토리와 브랜치 간의 관계를 컬러로 시각화한 것을 볼 수 있습니다. 각 커밋은 해시, 즉 다른 모든 커밋과 구별되는 고유 번호로 식별됩니다(혹은 더 정확하게는 그 일부). 해시 표현을 줄이기 위해 해시는 16진수 형식(예: b04ebd1257)으로 표시됩니다. 

이러한 커밋 트리는 MQL5 Algo Forge 웹 인터페이스의 전용 page에서 모든 리포지토리에 대해 찾아 볼 수 있습니다. 표시된 스크린샷은 얼마 전에 찍은 것이므로 지금 이 페이지를 방문하면 새로운 커밋이 트리에 나타나고 추가적인 병합 커밋으로 인해 브랜치의 얽힌 상태가 변경되므로 약간 다른 모습을 볼 수 있습니다.

일부 커밋의 옆에 브랜치 이름도 볼 수 있는데 각 브랜치의 가장 최근 커밋에 대해 표시됩니다. 스크린샷에서 main, develop, convert-to-utf8, article-17608-close-manager, article-17607 및 article-19436-forge3와 같은 6가지 브랜치를 확인할 수 있습니다. 마지막 브랜치는 3부를 작성하는 동안 변경한 내용을 반영하는 데 사용되는 브랜치입니다. 하지만 2부를 작업할 때는 계획된 변경 사항을 위한 별도의 브랜치도 만들었습니다. 이 브랜치의 이름은 article-17698-forge2였으며 이후 삭제되었기 때문에 현재 이 브랜치 이름을 가진 커밋은 없습니다. 그렇다면 어디에서 찾을 수 있을까요?

58beccf233의 전체 커밋 메시지를 보면 이 브랜치 이름이 나와 있고 develop로 병합되었음을 알 수 있습니다.

원하는 커밋을 찾았지만 이런 식으로 찾는 것은 편리하지 않습니다. 게다가 풀 리퀘스트가 아닌 'git merge'와 같은 콘솔 명령을 사용하여 수동으로 브랜치를 병합했다면 병합 커밋에 임의의 커멘트를 작성할 수도 있었을 것입니다. 이 경우 브랜치 이름이 메시지에 전혀 포함되지 않았을 수 있으므로 올바른 커밋을 찾기가 훨씬 더 어려웠을 것입니다.

이제 원하는 커밋을 찾았으니 해당 커밋으로 전환하여 로컬 리포지토리를 커밋 직후의 상태로 복원할 수 있습니다. 이를 위해 'git checkout' 명령에서 커밋 해시를 사용할 수 있습니다. 하지만 여기에는 몇 가지 미묘한 차이가 있습니다. MetaEditor에서 프로젝트의 컨텍스트 메뉴 옵션 "Git Log"를 통해 히스토리에서 이 커밋을 선택하여 전환하려고 하면 됩니다:

... 그런데 오류 메시지가 표시됩니다:

아마도 이 오류에는 이유가 있을 것입니다. 무슨 일이 일어나고 있는지 자세히 살펴보겠습니다. 먼저 'tag'와 'HEAD pointer'라는 새로운 개념을 소개합니다.

Tags

Git 버전 관리 시스템에서 태그는 특정 커밋에 할당된 또하나의 추가적인 이름입니다. 태그는 특정 커밋을 직접 가리키기 때문에 리포지토리의 특정 코드 버전에 대한 포인터 또는 참조라고 간주할 수도 있습니다. 태그를 사용하면 언제든지 태그된 커밋에 해당하는 코드의 정확한 상태로 돌아갈 수 있습니다. 태그는 버전 릴리스, 완료 단계 또는 안정 빌드와 같이 프로젝트 개발의 중요한 마일스톤을 표시하는 데 유용합니다. MQL5 Algo Forge 웹 인터페이스에서는 별도의 page에서 선택한 리포지토리의 모든 태그를 볼 수 있습니다.

Git에는 경량 태그와 주석이 달린 태그의 두 가지 유형이 있습니다. 경량 태그에는 이름만 포함되지만 주석이 달린 태그에는 작성자, 날짜, 댓글, 서명 등의 추가 정보가 포함될 수 있습니다. 대부분의 경우 경량 태그가 사용됩니다.

웹 인터페이스를 통해 태그를 만들려면 커밋 페이지(예: this one)을 열고 'Operation' 버튼을 클릭한 다음 'Create tag'를 선택하면 됩니다.

어쨋든 태그를 생성하는 것에 대해서는 잠시 후에 다시 설명하겠습니다.

Git 콘솔 명령을 통해 태그를 만들려면 'git tag' 명령을 사용합니다. 경량 태그를 만들려면 태그의 이름을 지정하기만 하면 됩니다:

git tag <tag-name>

# 예제
git tag v1.0

주석이 달린 태그를 만들려면 몇 가지 추가의 매개변수를 생성해야 합니다:

git tag -a <tag-name> -m "태그 설명"

# 예제:
git tag -a v1.0 -m "버전 1.0 릴리스"

태그는 게시 또는 배포(릴리스)를 위한 코드 버전을 표시하는 것 외에도 특정 태그가 있는 커밋이 나타나면 미리 정의된 작업을 트리거 하도록 CI/CD 파이프라인에 신호를 보내거나 새 버전 릴리스가 아니더라도 주요 기능의 완료 또는 중요한 버그 수정과 같은 중요한 개발 이정표를 표시하는 데 사용할 수도 있습니다.

HEAD pointer

또 다른 중요한 개념인 HEAD pointer에 대해 알아보겠습니다. 이 태그는 현재 체크 아웃된 브랜치의 최신 커밋으로 자동으로 이동하는 고정된 이름 HEAD 태그와 유사합니다. HEAD는 종종 "현재 브랜치의 마커" 또는 "활성 브랜치에 대한 포인터"라고도 합니다. 본질적으로 다음 질문에 대한 답변입니다: "지금 리포지토리의 위치는 어디인가요?" 그러나 엄밀히 말해 태그는 아닙니다.

물리적으로 이 포인터는 리포지토리의 .git/HEAD 파일에 저장됩니다. HEAD의 내용에는 기호 참조(태그 또는 브랜치 이름) 또는 커밋 해시가 포함될 수 있습니다. 브랜치 사이를 전환할 때 HEAD 포인터는 현재 브랜치의 최신 커밋을 가리키도록 자동으로 업데이트됩니다. 새 커밋이 추가되면 Git은 커밋 객체를 생성할 뿐만 아니라 HEAD 포인터도 새로운 커밋으로 이동합니다.

따라서 Git 콘솔 명령에서 최신 커밋의 해시나 현재 브랜치 이름 대신 HEAD라는 이름을 사용할 수 있습니다. 특수 기호 ~와 ^를 사용하면 최신 커밋 앞에 있는 커밋을 참조할 수 있습니다. 예를 들어 HEAD~2는 가장 최근 커밋 두 단계 전의 커밋을 나타냅니다. 자세한 내용은 지금 자세히 설명하지 않겠습니다.

추가적으로 리포지토리의 두 가지 가능한 상태에 대해서도 알아보겠습니다. '연결된 HEAD'라고 하는 정상 상태는 현재 브랜치의 최신 커밋보다 새 커밋이 먼저 나타나는 것을 의미합니다. 이 상태에서는 모든 편집 내용이 충돌 없이 순차적으로 브랜치에 추가됩니다.

'분리된 HEAD'로 알려진 다른 상태는 HEAD 포인터가 어떤 브랜치에서도 최신이 아닌 커밋을 가리킬 때 발생합니다. 예를 들어 다음과 같은 경우에 발생할 수 있습니다: 

• 리포지토리를 특정한 과거의 커밋으로 전환합니다(예: ''git checkout <commit-hash>' 사용),
• 태그 이름으로 전환합니다(예: 'git checkout tags/<tag-name>'),
• 원격 리포지토리에 여전히 존재하지만 로컬 리포지토리에서 제거된 브랜치로 전환합니다(예: 'git checkout origin/<branch-name>').

다른 브랜치로 전환할 때 브랜치와 연관되지 않은 이 상태의 모든 변경 사항이 손실될 수 있으므로 이 상태는 가급적 피해야 합니다. 그러나 이 상태에서 변경하지 않을 것이라면 그대로 두어도 괜찮습니다.

아직 태그가 없습니다

이제 삭제된 브랜치 article-17698-forge2의 최신 커밋이었던 특정 커밋으로 로컬 리포지토리를 전환하려는 시도로 돌아가 보겠습니다.

리포지토리를 특정 과거의 커밋으로 전환하는 것은 개발자가 일상적인 Git 워크플로에서 일반적으로 하는 일은 아닙니다. 일반적인 상황에서는 이러한 작업을 수행할 필요가 거의 없습니다. 그러나 그렇게 하면 리포지토리는 이른바 "분리된 HEAD" 상태로 전환됩니다. 이 경우 해당 커밋은 이미 최신 커밋이 있는 develop 브랜치에 속하므로 더 이상 브랜치에서 최신 커밋이 아닙니다.

그래도 Git의 명령줄 인터페이스를 사용하여 이러한 전환을 수행하면 작업이 성공적으로 완료됩니다. Git은 '분리된 HEAD: 상태'에 대해 분명히 경고하지만:

 

주의 깊은 독자라면 마지막 스크린샷에서 해시 58beccf233을 사용하여 커밋으로 전환한 것을 알 수 있지만 Git은 이제 HEAD 포인터가 58beccf에 있다고 보고합니다. 마지막 세 자리는 어디로 갔나요? 아무 문제 없습니다. 사라지지 않았습니다. Git에서는 단축된 커밋 해시가 리포지토리 내에서 고유하게 유지되는 한 계속 사용할 수 있습니다. 인터페이스에 따라 해시가 4자에서 10자 사이로 짧게 표시될 수 있습니다.

전체 커밋 해시를 확인하려면 'git log' 명령을 실행하여 확인할 수 있습니다. 각 전체 커밋 해시에는 40자리가 포함됩니다.

각 해시는 무작위로 고유하게 생성되므로 처음 몇 자리도 리포지토리 내에서 거의 확실하게 구별됩니다. 그렇기 때문에 짧은 해시 접두사만 제공해도 Git은 일반적으로 명령에서 어떤 커밋을 참조하는지 정확히 인식할 수 있습니다.

UTF-8 인코딩 사용

또 다른 흥미로운 측면이 있습니다. 이전 버전에서 MetaEditor는 소스 코드 파일을 저장할 때 UTF-16LE 인코딩을 사용했습니다. 하지만 어떤 이유에서인지 이 인코딩으로 저장된 파일은 Git에서 텍스트 파일이 아닌 바이너리로 처리되어 커밋에서 수정된 정확한 코드 줄을 볼 수 없었습니다(Visual Studio Code에서는 잘 작동했지만). 표시되는 정보는 커밋 내의 변경 전후의 파일 크기 뿐이었습니다.

다음은 MQL5 Algo Forge 웹 인터페이스의 모습입니다:

이제 MetaEditor에서 생성된 새 파일은 UTF-8 인코딩을 사용하여 저장되며 국가별 알파벳 문자를 사용해도 더 이상 자동으로 UTF-16LE 전환이 트리거 되지 않습니다. 따라서 이전 프로젝트에서 새 리포지토리로 옮겨진 이전 파일은 UTF-8로 변환하는 것이 좋습니다. 이러한 변환을 수행한 후 다음 커밋부터 정확히 어떤 줄과 문자가 변경되었는지 확인할 수 있습니다. 예를 들어 MQL5 Algo Forge 웹 인터페이스에서는 다음과 같이 표시될 수 있습니다:

하지만 그건 잠깐의 여담이었습니다. 리포지토리에 새 버전의 코드를 게시하는 방법에 대한 논의로 돌아가 보겠습니다.

주요 작업으로 돌아가기

따라서 리포지토리에 있는 브랜치 중 이 두 가지, article-17608-close-manager와 article-17607에 주목해 보겠습니다. 이러한 브랜치의 변경 사항은 아직 관련 작업이 진행 중이므로 develop 브랜치에 병합되지 않았습니다. 이러한 브랜치는 개발이 계속 될 것이므로 develop로 병합하기에는 아직 이릅니다. 우리는 그 중 하나 (article-17607)에 대한 작업을 계속하여 논리적으로 완성된 지점에 도달한 다음 develop와 병합할 예정입니다. 코드의 결과 상태에는 버전 번호가 태그됩니다.

이렇게 하려면 먼저 추가 편집을 위해 선택된 브랜치를 준비해야 합니다. 왜냐하면 선택한 브랜치가 존재하는 동안 다른 브랜치에서도 변경 사항이 적용되었기 때문입니다. 이러한 변경 사항은 이미 develop로 병합되었습니다. 따라서 develop에서 행한 업데이트가 선택한 브랜치에도 통합되도록 해야 합니다.

develop에서 article-17607로 변경 사항을 병합하는 방법에는 여러 가지가 있습니다. 예를 들어 웹 인터페이스를 통해 풀 리퀘스트를 만들고 이전 파트에서 설명한 병합 프로세스를 반복할 수 있습니다. 그러나 이 방법은 테스트되지 않은 새 코드를 안정적이고 테스트된 코드를 포함한 브랜치에 병합하려는 경우에 사용하는 것이 가장 좋습니다. 우리의 경우는 상황이 정반대입니다. 우리는 개발 단계에서 안정적이고 검증된 업데이트를 아직 확인되지 않은 새로운 코드를 포함한 브랜치로 가져오려고 하는 것입니다. 따라서 Git 콘솔 명령을 사용하여 병합을 수행해도 무방합니다. 콘솔을 사용하고 Visual Studio Code에서 프로세스를 모니터링하겠습니다.

먼저 리포지토리의 현재 상태를 확인해 보겠습니다. 버전 제어판에서 브랜치 이름과 함께 커밋 기록을 볼 수 있습니다. 현재 브랜치는 article-19436-forge3이며 가장 최근에 변경된 브랜치입니다. 터미널의 오른쪽에 'git status' 명령의 출력이 표시됩니다:

이 명령은 우리의 리포지토리가 현재 article-19436-forge3 브랜치에 있고 그 상태가 원격 리포지토리의 해당 브랜치와 동기화되어 있음을 확인합니다.

다음으로, 'git checkout article-17607' 명령을 사용하여 article-17607 브랜치로 전환합니다:

그런 다음 'git merge develop'를 사용하여 develop와 병합합니다:

외부 변경 사항은 문서 17607에서 작업하는 동안 수정하지 않은 코드의 일부에 영향을 미쳤기 때문에 병합 중에 충돌이 발생하지 않았습니다. 그 결과 Git은 새로운 병합 커밋을 만들었습니다.

이제 업데이트된 정보를 원격 리포지토리로 보내기 위해 'git push'를 실행합니다:

MQL5 Algo Forge 리포지토리를 확인하면 병합 단계가 원격 리포지토리에 성공적으로 반영된 것을 확인할 수 있습니다:

스크린샷에 표시된 마지막 커밋은 develop와 article-17607 사이의 병합 커밋입니다. 

또한 아직 다른 브랜치에 연결되지 않은 article-19436-forge3 브랜치의 끝부분에 주목하세요. 이 브랜치의 변경 사항은 아직 작업이 진행 중이므로 아직 develop 브랜치에 병합되지 않았습니다. 지금은 그대로 두겠습니다. 때가 되면 다시 돌아오겠습니다.

이로써 article-17607의 지속적인 개발을 위한 준비가 완료되었으며 이제 코딩 작업을 진행할 수 있습니다. 이 지점과 관련된 작업에 대한 해결책은 다른 기고글에 설명되어 있습니다. 따라서 여기서는 반복하지 않겠습니다. 대신 작업을 완료한 후 달성한 코드의 상태를 마무리하고 기록하는 방법에 대해 설명해 보겠습니다.

병합 수행하기

특정 상태의 코드를 게시하기 전에 먼저 메인 브랜치에 병합해야 합니다. 기본 브렌치는 main입니다. develop 브랜치의 모든 업데이트는 결국 main 브랜치로 흘러들어갑니다. 개별 작업 브랜치의 변경 사항이 develop로 병합됩니다. 지금은 새 코드를 main에 병합할 준비가 되지 않았으므로 업데이트를 develop로 병합하는 것으로 제한하겠습니다. 이 메커니즘을 설명하기 위해 어떤 브랜치가 main 브랜치의 역할을 하는지는 특별히 중요하지 않습니다.

선택한 작업을 완료한 후 SimpleCandles 리포지토리의 상태를 살펴보겠습니다:

표시된 것처럼 최신 커밋은 article-17607 브랜치에서 이루어졌습니다. 앞서 설명한 대로 MQL5 Algo Forge 웹 인터페이스를 사용하여 이 브랜치를 develop로 병합하는 풀 리퀘스트를 생성합니다.

모든 것이 예상대로 진행되었는지 확인해 보겠습니다. 브랜치 트리 보기로 커밋 히스토리 페이지를 다시 엽니다:

해시 432d8a0fd7의 커밋이 더 이상 article-17607의 최신 커밋으로 표시되지 않는 것을 볼 수 있습니다. 대신 해시 001d35b4a7의 새 커밋이 최근의 것으로 develop에 나타납니다. 이 커밋은 두 브랜치의 병합을 기록하므로 병합 커밋이라고 부릅니다.

그런 다음 merge commit 페이지를 열고 새 태그를 만듭니다. 이 글의 앞부분에서 이 작업을 수행해야 하는 위치를 설명했는데 이제 실제로 수행해 볼 차례입니다:

아직 최종 버전과는 거리가 멀기 때문에 팝업 창에 태그 이름 "v0.1"을 입력합니다. 프로젝트에 얼마나 더 많은 기능이 추가될지는 아직 알 수 없지만 꽤 많은 기능이 추가될 것으로 예상됩니다. 따라서 이러한 작은 버전 번호는 아직 해야 할 일이 많다는 것을 알려주는 역할을 하기도 합니다. 참고로, 현재 웹 인터페이스는 주석이 달린 태그를 생성하는 것을 지원하지 않는 것 같습니다.

이제 태그가 성공적으로 생성되었으며 다음 페이지에서 결과를 확인할 수 있습니다:

 또는 리포지토리 전용 tags 페이지에서 확인할 수 있습니다.

'git pull'을 사용하여 로컬 리포지토리를 업데이트하면 새로 생성된 태그가 해당 리포지토리에도 표시됩니다. 하지만 현재 MetaEditor는 리포지토리 태그를 표시하지 않습니다. Visual Studio Code에서 이 태그들이 어떻게 표시되는지 확인해 보겠습니다. 커밋 트리에서 원하는 커밋에 마우스를 가져가면 관련 태그 이름이 포함된 색상 레이블이 도구 설명에 나타납니다:

이제 태그가 생성되었으므로 여기서 멈추고 'git checkout' 명령에서 해당 이름을 사용하여 정확한 코드 상태로 전환하거나 더 나아가 이를 기반으로 릴리스를 생성할 수 있습니다. 

릴리스 생성

릴리스란 사용된 프로그래밍 언어에 관계없이 특정 버전의 소프트웨어를 표시하고 배포하는 메커니즘입니다. 커밋과 브랜치는 개발 과정 상태를 나타내며 릴리스는 공식 결과물 즉 게시하려는 버전을 의미합니다. 릴리스를 사용하는 주요 목적은 다음과 같습니다:

• 버전 관리. 우리가 리포지토리 코드에서 코드의 특정 상태를 안정된 것으로 표기하는 경우 이는 심각한 오류(적어도 명백한 오류)가 없고 기능이 검증된 상태임을 의미합니다. 다른 사용자는 이러한 특정 버전에서 사용할 수 있습니다.
  
  
• 바이너리 배포하기. 릴리스에는 컴파일된 파일 또는 패키지 파일(.ex5, .dll 또는 .zip 등)이 포함될 수 있으므로 사용자가 직접 프로젝트를 컴파일할 필요가 없습니다.
  
  
• 사용자 커뮤니케이션. 릴리스에는 일반적으로 변경 사항, 새로운 기능, 수정된 버그 및 해당 버전에 대한 여러 관련 정보를 나열하는 설명이 포함되어야 합니다. 이 설명의 주된 목적은 사용자가 업데이트 여부를 결정하는 데 도움을 주기 위한 것입니다.

한 가지 더 언급하자면 MQL5 Algo Forge를 포함한 CI/CD 시스템은 브랜치가 main 브랜치에 병합될 때 자동으로 릴리즈를 생성하고 자동으로 빌드를 수행하고 바이너리 파일을 게시할 수 있습니다. 하지만 이러한 자동화를 위해서는 사전 설정과 이벤트 처리 스크립트를 구성하는 것이 필요합니다. 이러한 기능은 필수 기능은 아닌 고급 기능이므로 지금은 넘어 가겠습니다.
기존 태그를 기반으로 릴리스를 만들거나 릴리스 생성 프로세스 중에 새 태그를 생성할 수 있습니다. 이미 태그가 있으므로 우리는 이를 사용하여 새 릴리스를 만들겠습니다. 이렇게 하려면 리포지토리 태그 페이지로 이동하여 원하는 태그 옆의 'New release'를 클릭합니다:

릴리스 생성 양식에서 몇 가지 기본 속성을 지정할 수 있습니다:

• 릴리스 이름, 대상 브랜치 및 태그(기존 태그 또는 새로 만들 태그)를 입력합니다,
• 릴리스 노트는 새로운 기능, 수정된 기능, 해결된 알려진 문제에 대한 요약입니다,
• 첨부 파일에는 컴파일된 프로그램, 문서 또는 외부 리소스에 대한 링크등이 있을 수 있습니다.

MQL5 Algo Forge 웹 인터페이스에서 다음과 같습니다:

릴리스를 초안으로 저장하고 나중에 세부 정보를 업데이트하거나 바로 게시할 수도 있습니다. 지금 게시하더라도 나중에 수정할 수 있습니다. 예를 들어 나중에 릴리스 설명을 수정할 수 있습니다. 릴리스가 게시되면 리포지토리의 Releases에 표시되어 다른 사용자가 볼 수 있습니다:

다 된 겁니다! 이제 새 버전이 출시되어 바로 사용할 수 있습니다. 이후에 태그 이름과 일치하지 않아도 되는 릴리스 이름을 업데이트했고 구현된 솔루션을 설명하는 위에서 언급한 기고글의 링크를 추가했습니다.

결론

잠시 멈춰서 우리가 이룬 성과를 되돌아보겠습니다. 우리는 버전 관리의 기술적 측면만 살펴본 것이 아닙니다. 여기저기서 산만하던 편집 작업을 체계적이고 일관된 코드 관리를위한 작업 과정으로 전환하여 완전한 혁신을 이루었습니다. 우리가 도달한 가장 중요한 이정표는 완성된 작업을 최종 사용자를 위한 공식 제품 버전으로 출시하는 것입니다. 현재 리포지토리는 아직 완전히 성숙한 프로젝트는 아니지만 완전한 수준에 도달하기 위한 모든 토대를 마련했습니다.

이러한 접근 방식은 우리가 프로젝트를 인식하는 방식을 근본적으로 변화시킵니다. 예전에는 소스 파일의 산만한 모음이었던 것이 이제는 명확한 변경 내역과 잘 정의된 체크포인트가 있는 체계적인 시스템이 되어 언제든 안정적인 상태로 되돌릴 수 있습니다. 이는 개발자와 완성된 솔루션을 사용하는 사용자 모두에게 도움이 됩니다.

이러한 도구를 마스터함으로써 우리는 MQL5 Algo Forge 리포지토리 작업을 새로운 차원으로 끌어올려 향후 더 복잡하고 대규모 프로젝트를 진행할 수 있는 문을 열었습니다.

관심을 가져 주셔서 감사합니다! 다음에 뵙겠습니다!