기고글 토론 "MQL5 Algo Forge로 이동하기(2부): 여러 리포지토리로 작업하기"
https://www.mql5.com/ko/articles/17698
병합하기 전에 MQL5 Algo Forge 리포지토리의 편리한 인터페이스에서 모든 변경 사항을 다시 한 번 시각적으로 검토할 수 있습니다. 이렇게 의도적으로 확인하는 동안 불필요한 주석, 실수로 추가된 파일, 최적이 아닌 변경 사항 등 커밋 중에 빠져나간 것들을 발견할 수 있습니다. 본질적으로 이것은 일종의 자기 훈련입니다. 게다가 올바른 프로세스에 익숙해지면 이러한 방식으로 작업하는 습관이 생깁니다 (별도의 브랜치 만들기, 코드 검토 등).
저자가"MQL5 Algo Forge 리포지토리의 편리한 인터페이스에서 변경 사항 보기"를 시연하지 않은 이유를 추측해 보겠습니다. 작성자가 할 수 없기 때문에 diff가 작동하지 않기 때문입니다. diff가 작동하지 않는 이유는 Git이 소스 코드 파일을 바이너리로 간주하기 때문입니다. 이 글의 스크린샷에서도 확인할 수 있습니다:
https://www.mql5.com/ko/articles/17698
이로써 병합 프로세스가 완료됩니다. article-17698-forge2 브랜치가 개발 브랜치에병합되고삭제됩니다:
서버에서만 제거되고 메타에디터(로컬 리포지토리)에서는 제거되지 않습니다. 작성자가 실수로 가장 흥미로운 지점에서 멈췄거나, 아니면 침묵하기로 선택한 또 다른 문제일 수 있습니다.
[브레이크를 추가하는 것을 잊은 스포츠카에 대한 기사를 작성하는 것과 같습니다. 시속 300km로 달리는 것이 얼마나 멋진지 설명하되, 벽이나 좋은 나무에 부딪힐 때만 멈출 수 있다는 사실은 빼는 것이 좋습니다.저자가"MQL5 Algo Forge 리포지토리의 편리한 인터페이스에서 변경 사항 보기"를 시연하지 않은 이유를 추측해 보겠습니다. 작성자는 diff가 작동하지 않아서 할 수 없기 때문입니다. diff가 작동하지 않는 이유는 Git이 소스 코드 파일을 바이너리로 간주하기 때문입니다. 이 글의 스크린샷에서도 확인할 수 있습니다:
안타깝게도 한 번에 모든 것을 할 수는 없습니다. 이것은 문제를 숨기려는 시도가 아닙니다. 쉽게 고칠 수 있다고 거의 확신했기 때문에 강조하지 않았습니다. 이제 하나의 리포지토리 파일을 UTF-8로 변환하는 실험을 해봤습니다. ME에서는 UTF-16 LE일 때와 아무런 차이 없이 열리고 컴파일됩니다. 이제 웹 인터페이스에서 차이점을 정상적으로 확인할 수 있습니다. 일반적으로소스 코드 파일을 바이너리로 간주하는 것은 Git이 아니라, Forgejo 기반 웹 인터페이스가 메타에디터가 기본적으로 사용하는 UTF-16 LE 인코딩의 텍스트 파일을 처리하도록 설계되지 않았기 때문입니다.
하지만 메타에디터와 다른 점은.... 분명히 UTF-8로 된 파일의 러시아어 문자가 올바르게 표시되지 않고 모든 줄 끝의 차이로 인해 전체 파일이 변경된 것으로 간주되는 UTF-16 LE만 사용할 수 있습니다:
기사를 작성하는 과정에서 나는 ME에서 diff를 사용하지 않았습니다. ME가 Git 지원을 추가하는 동안 사용하는 데 익숙해졌고 리포지토리와 관련된 모든 작업에 대해 VS 코드를 병렬로 실행해야 했기 때문입니다. 그래서 이 글에서는 다루지 못했습니다.
아직까지 ME에는 리포지토리에 문제가 있기 때문에 다른 방법을 제안하려고 합니다. 그러나 동시에 나는 그들이 제 시간에 고쳐질 것이라고 믿고 싶습니다. 그 동안에는 우리가 가진 것을 사용합시다.
서버에서만 제거되고 메타에디터(로컬 저장소)에서는 제거되지 않습니다. 작성자가 실수로 가장 흥미로운 곳에서 멈췄거나 침묵을 지키고 싶었던 또 다른 문제입니다.
지적해 주셔서 감사합니다. 실제로 원격 리포지토리에서 브랜치를 삭제할 때 로컬 컴퓨터의 이 리포지토리의 모든 클론에서 자동으로 삭제되어서는 안 됩니다. 로컬 리포지토리에서 별도로 삭제해야 합니다. 이는 모든 Git 기반 리포지토리에 해당되는 문제이므로 Algo Forge의 문제는 아닙니다.
[편집] 브레이크를 추가하는 것을 잊은 스포츠카에 대한 기사를 작성하는 것과 같습니다. 시속 300km로 얼마나 멋지게 달리는지 설명하되, 벽이나 멋진 나무에 부딪힐 때만 멈출 수 있다는 사실은 빼고요.
오, 그건 확실합니다! 드라이브는 특별합니다 ) 솔직히 말해서 모든 구석에서 이렇게 비틀 거리고 싶지는 않습니다. 가는 것이 좋습니다. 그리고 브레이크가 충분하지 않은 곳에서는 외부 브레이크를 사용하려고 노력할 것입니다.
아니요, Git 자체는 메타에디터가 때때로 저장하는 인코딩으로 바이너리 파일을 고려합니다. 위조조나 웹 인터페이스는 이 문제와 아무 관련이 없습니다. 그 증거는 Windows용 Git Bash의 리포지토리에 있습니다:
그러나 이 VS 코드에도 불구하고 UTF-16 LE 인코딩에서도 모든 차이점을 침착하게 보여줍니다. 글쎄, Git 자체는 그것들을 바이너리라고 부릅니다.
우리가 발견 한 가장 중요한 것은 UTF-8로 변환 한 후 Git 콘솔과 웹 인터페이스에서 문제가 해결된다는 것입니다 (그러나 Diff ME에는 또 다른 문제가 있습니다):
아니요, Git 자체는 메타에디터가 때때로 저장하는 인코딩으로 바이너리 파일을 고려합니다. 위조조나 웹 인터페이스는 이 문제와 아무 관련이 없습니다. 그 증거는 Windows용 Git Bash의 리포지토리에 있습니다:
며칠 동안 머리를 굴린 끝에 최소한 "깨진" 파일 목록을 채울 수 있는 방법을 찾아냈습니다. 이 방법은 다음 명령이
git ls-files --format='%(eolinfo:index) %(path)'
명령이 "-text"를 표시한다는 사실에 기반합니다:
그러나 이 명령은 색인만 찾습니다(수정된 파일과 추적되지 않은 파일은 무시됨). 저는 eolinfo의 특성에 신경 쓰지 않고 모든 파일을 새 리포지토리의 색인에 어리석게도 추가하기로 결정했습니다. 그 결과, 브릭되기 전에 "깨진" 파일을 확인할 수 있는 도구를 만들었습니다: https: //forge.mql5.io/boyvlad/mql-check-binary-surprises.
사용 논리: 커밋하기 전에 모든 프로젝트 파일(.git 폴더 및 gitignore 파일 제외)을 별도의 폴더에 복사하고 그 안에 스크립트(위에서 제공한 링크)를 실행합니다. 스크립트는 먼저 새 git 리포지토리를 초기화하고 모든 파일을 인덱스에 추가한 후 손상된 파일을 나열합니다. 이 스크립트는 먼저 .git 폴더와 gitignore 파일이 없는지 확인하여 실수로 복사본이 아닌 작업 디렉터리에서 실행되는 것을 방지합니다.
사용 예시:
편집기에서 작업하는 것을 포함하여 단계별로 수정하겠습니다.
개선 과정에서 메타에디터와 웹 인터페이스만 사용하여 몇 가지 원시적인 브랜칭 전략을 몇 번 반복해 보는 것이 좋습니다.
- 다음 브랜치를 만들고 거기서 몇 가지 커밋을 합니다.
- 다음을 메인에 넣고, 다음을 삭제합니다.
- 새 부모 커밋으로 다음을 다시 만들고 몇 가지 커밋을 한다.
- ...
포인트 3은 현재 외부 도구를 사용하지 않고는 불가능합니다. 따라서 포인트 2를 사이트를 통해 할 수 있다는 사실은 막다른 골목이기 때문에 더 쉬워지지 않습니다.
이 토론에서 저는이 모든 것을 이미 몇 달 전에보고했습니다. 이제 포인트 1과 2를 다루는 기사가 나오고 있지만, 포인트 3은 기사에 포함되어 있지 않습니다(포인트 3은 논리적으로 확장된 내용이지만).
브랜딩 없는 Git은 국물 없는 수프와 같습니다.
새로운 기고글 MQL5 Algo Forge로 이동하기(2부): 여러 리포지토리로 작업하기 가 게재되었습니다:
첫 번째 글에서 우리는 MetaEditor에 내장된 SVN 기반의 MQL5 저장소에서 Git 버전 제어 시스템을 기반으로 하는 보다 유연하고 현대적인 솔루션으로 전환하기 시작했습니다: MQL5 Algo Forge. 이 단계를 거친 주된 이유는 여러 프로젝트 또는 단일 프로젝트 내에서 서로 다른 기능으로 작업하는 동안 리포지토리 브랜치를 충분히 활용해야 했기 때문입니다.
전환은 MQL5 Algo Forge에 새로운 리포지토리를 생성하고 필요한 MQL5 및 Git 확장 및 지원 도구와 함께 Visual Studio Code를 사용하여 로컬 개발 환경을 설정하는 것으로 시작되었습니다. 그런 다음 버전 관리에서 표준 파일과 임시 파일을 제외하기 위해 리포지토리에 .gitignore 파일을 추가했습니다. 기존의 모든 프로젝트는 이전에 작성된 모든 코드의 보관 저장소로 지정된 전용 아카이브 브랜치에 업로드 되었습니다. main 브랜치는 비워두었고 새로운 프로젝트 브랜치를 구성할 준비를 했습니다. 이러한 방식으로 우리는 리포지토리의 여러 브랜치에 서로 다른 프로젝트 코드를 배포할 수 있는 기반을 마련했습니다.
작성자: Yuriy Bykov