개선 과정에서 메타에디터와 웹 인터페이스만 사용하여 몇 가지 원시 분기 전략을 몇 번 반복해 볼 것을 제안합니다.
다음 브랜치를 만들고 거기서 몇 가지 커밋을 합니다.
다음을 메인에 넣고, 다음을 삭제합니다.
새 부모 커밋으로 다음을 다시 만들고 몇 가지 커밋을 한다.
...
포인트 3은 현재 외부 도구를 사용하지 않고는 불가능합니다. 따라서 포인트 2를 사이트를 통해 할 수 있다는 사실은 막다른 골목이기 때문에 더 쉬워지지 않습니다.
나는이 토론에서 새로운 것을 말하지 않았습니다. 나는 이미 몇 달 전에이 모든 것을보고했습니다. 이제 포인트 1과 2를 설명하는 기사가 있지만 어떻게 든 포인트 3이 기사에 없습니다 (포인트 3은 논리적으로 연속적이지만).
3번 항목이 누락된 이유는 서로 다른 기능의 브랜치가 항상 같은 이름이 아닌 다른 이름을 갖는 접근 방식을 선호하기 때문입니다(다음). 귀하의 접근 방식으로는 다음을 제거해야하는 이유가 전혀 명확하지 않습니다. 메인/개발 번들의 개발 브랜치와 의미가 비슷해 보이며, 기능을 순차적으로 추가할 때 각각의 새로운 기능에 대해 작업하는 데 사용됩니다.
며칠 동안 브레인스토밍을 한 끝에 최소한 '깨진' 파일 목록을 채울 수 있는 방법을 찾아냈습니다.
예, 한때는 컴파일 된 모든 파일의 공통 저장소를 지우는 스크립트를 시도했지만 결과적으로 불필요한 것으로 판명되었습니다. 웹 인터페이스를 사용하여 파일 차이점을 처리하지 않았기 때문에 콘텐츠가 표시되지 않는 것은 중요하지 않았습니다. 그렇다면 "깨진" 파일 목록을 찾는 것은 가능하지만 그 이유는 무엇일까요? 이미 ME가 만든 파일(UTF-16 LE 인코딩)이라는 것을 알고 있다면 README.md, .gitignore 및 몇 가지 다른 파일을 제외한 모든 리포지토리 파일이 해당됩니다.
Yuriy Bykov #: 이 파일들이 모두 ME가 만든 파일이라는 것이 이미 알려진 경우(UTF-16 LE 인코딩으로)
몇 달 전에 이 문제를 테스트해 보았습니다. 마법사는 UTF-8 (깨진 파일이 아닌 정상 파일)을 생성합니다. MT4 마법사도 정상 파일을 생성합니다. 테스트하는 동안 마법사에서 "깨진" 파일을 가져온 적은 한 번도 없었습니다.
가끔 커밋하기 전에 해당 스크립트로 파일을 확인합니다. 그리고 결과적으로 정상 파일이 갑자기 인코딩이 변경되는 경우가 있었습니다. 아마도 클립 보드에서 무언가를 삽입 한 후 확실하지 않습니다. 키릴 문자가 거기에 있었을 가능성은 거의 없습니다. 오래 전에 댓글에서도 사용을 포기했습니다.
개선 과정에서 메타에디터와 웹 인터페이스만 사용하여 몇 가지 원시 분기 전략을 몇 번 반복해 볼 것을 제안합니다.
포인트 3은 현재 외부 도구를 사용하지 않고는 불가능합니다. 따라서 포인트 2를 사이트를 통해 할 수 있다는 사실은 막다른 골목이기 때문에 더 쉬워지지 않습니다.
나는이 토론에서 새로운 것을 말하지 않았습니다. 나는 이미 몇 달 전에이 모든 것을보고했습니다. 이제 포인트 1과 2를 설명하는 기사가 있지만 어떻게 든 포인트 3이 기사에 없습니다 (포인트 3은 논리적으로 연속적이지만).
3번 항목이 누락된 이유는 서로 다른 기능의 브랜치가 항상 같은 이름이 아닌 다른 이름을 갖는 접근 방식을 선호하기 때문입니다(다음). 귀하의 접근 방식으로는 다음을 제거해야하는 이유가 전혀 명확하지 않습니다. 메인/개발 번들의 개발 브랜치와 의미가 비슷해 보이며, 기능을 순차적으로 추가할 때 각각의 새로운 기능에 대해 작업하는 데 사용됩니다.
며칠 동안 브레인스토밍을 한 끝에 최소한 '깨진' 파일 목록을 채울 수 있는 방법을 찾아냈습니다.
예, 한때는 컴파일 된 모든 파일의 공통 저장소를 지우는 스크립트를 시도했지만 결과적으로 불필요한 것으로 판명되었습니다. 웹 인터페이스를 사용하여 파일 차이점을 처리하지 않았기 때문에 콘텐츠가 표시되지 않는 것은 중요하지 않았습니다. 그렇다면 "깨진" 파일 목록을 찾는 것은 가능하지만 그 이유는 무엇일까요? 이미 ME가 만든 파일(UTF-16 LE 인코딩)이라는 것을 알고 있다면 README.md, .gitignore 및 몇 가지 다른 파일을 제외한 모든 리포지토리 파일이 해당됩니다.
Renat, 모든 소스를 UTF-8로 변환하는 것이 합당한 지 아니면 ME가 계속 UTF-16 LE에만 지향되는지 알려주시겠습니까? 새 빌드의 브랜치 어딘가 또는 다른 곳에서 UTF-8로의 전환에 대해 언급 한 것 같지만 아마도 그렇게 보였을까요?
아, 방금 ME (새 클래스)에서 새 파일을 만들었으므로 즉시 UTF-8로 생성되었습니다.
이런 접근 방식으로는 다음 브랜치를 삭제하는 이유가 전혀 이해가 되지 않네요.
저는 항상 브랜치가 안정성이 더 높은 브랜치에 완전히 병합된 후 즉시 삭제합니다. 습관이고 매우 유용한 습관이라고 확신합니다.
순전히 기술적인 수준에서 브랜치를 리빌드하면 부모 커밋(다음 커밋의 부모 커밋)의 형태로 상당한 차이를 만드는 경우가 많습니다. 때로는 이것이 중요하지 않고 커밋 그래프의 사용성에만 영향을 미치지만, 때로는 다시 만들지 않고는 할 수 없는 경우도 있습니다.
[편집]
일반적으로 로컬 리포지토리에서 브랜치를 제거할 수 있어야 한다고 주장하는 것은 이상하다고 생각합니다. 브랜치 모델이 Git의 킬러 기능이고 Git은 브랜치를 자주 만들고, 삭제하고, 병합하도록 장려한다는 점을 감안하면 말이다.
저는 파일 차이를 처리하기 위해 웹 인터페이스를 사용하지 않았기 때문에 웹 인터페이스에 콘텐츠가 표시되지 않는 것은 중요하지 않았습니다.
저도 웹 인터페이스를 거의 사용하지 않습니다. 그리고 메타에디터에서 Git 버튼도 사용하지 않습니다. 터미널에서 직접 Windows용 Git Bash를 보면 충분하고 편리합니다.
그래서 "깨진" 파일 목록을 찾을 수 있는데, 그 이유는 무엇인가요?
파일을 수정하기 위해 손상된 파일 목록을 알아야합니다. diff를 볼 수 있도록 수정하기 위해서입니다.
diff의 용도는 무엇인가요? [자동 번역기에 문제를 일으키는 중요하지 않은 문장을 삭제했습니다.]
이 파일들이 모두 ME가 만든 파일이라는 것이 이미 알려진 경우(UTF-16 LE 인코딩으로)
몇 달 전에 이 문제를 테스트해 보았습니다. 마법사는 UTF-8 (깨진 파일이 아닌 정상 파일)을 생성합니다. MT4 마법사도 정상 파일을 생성합니다. 테스트하는 동안 마법사에서 "깨진" 파일을 가져온 적은 한 번도 없었습니다.
가끔 커밋하기 전에 해당 스크립트로 파일을 확인합니다. 그리고 결과적으로 정상 파일이 갑자기 인코딩이 변경되는 경우가 있었습니다. 아마도 클립 보드에서 무언가를 삽입 한 후 확실하지 않습니다. 키릴 문자가 거기에 있었을 가능성은 거의 없습니다. 오래 전에 댓글에서도 사용을 포기했습니다.
키릴 문자는 거의 사용되지 않았고 오래 전에 댓글에서도 사용을 포기했습니다.
분명히 제가 착각한 것 같습니다. 방금 UTF-8 인코딩으로 .mq5 파일에 추가했습니다:
// 키릴 문자그리고 저장 후 파일 인코딩이 "UTF-16 LE BOM"으로 변경되었습니다.
메타에디터의 잘못인 것 같습니다. 키릴 문자를 추가하고 메모장 ++를 사용하여 파일을 저장했는데 인코딩이 UTF-8로 유지되었습니다.
또한 로컬 리포지토리에서 브랜치를 제거할 수 있어야 한다고 주장하는 것도 이상하게 느껴집니다. 브랜치 모델이 Git의 킬러 기능이고 Git은 브랜치를 자주 만들고, 삭제하고, 병합하도록 권장한다는 점을 고려하면 말이죠.
그래서 저도 브랜치가 메인 브랜치와 병합된 후 브랜치를 삭제하는 것을 선호합니다. 삭제 후 새 지점이 아닌 같은 이름의 새 피시에 대한 지점을 만든다는 말은 처음 들어봤습니다.
차이를 보는 목적은 무엇인가요?
네, 매우 필요한 기능입니다. 저도 적극적으로 사용하지만 VS 코드에서만 사용합니다. 그리고 이상하게도 "나쁜"인코딩이있는 파일을 살펴 보지만 거기에는 충돌이 없습니다.
나는 그런 일을 겪은 적이 없습니다. 그것도 꽤 예상치 못한 일입니다. 동일한 파일로 작업하기 위해 서로 다른 ME 빌드를 동시에 사용했기 때문에 정상 파일이 손상된 것일까요? 글쎄요...
커밋 기록을 살펴보니 두 달 전에 추가된 파일은 실제로 이미 UTF-8 인코딩이 되어 있고, 석 달 전에 추가된 파일은 여전히 UTF-16 LE입니다. 그 무렵 어딘가에서 UTF-8 인코딩으로 전환된 것 같습니다.
제가 틀렸던 것 같습니다. 방금 UTF-8 인코딩으로 .mq5 파일에 추가했습니다:
그리고 저장 후 파일 인코딩이 "UTF-16 LE BOM"으로 변경되었습니다.
메타에디터의 잘못인 것 같습니다. 키릴 문자를 추가하고 메모장 ++를 사용하여 파일을 저장했는데 인코딩이 UTF-8로 유지되었습니다.
러시아어 문자를 추가하고 파일을 저장한 후 인코딩이 UTF-8에서 UTF-16 LE로 변경되는 것을 확인했습니다. 러시아어 문자를 모두 제거하고 저장해도 여전히 UTF-16 LE로 남아 있습니다.
메타에디터의 잘못인 것 같습니다.
다음은 UTF-8, 키릴 문자 및 Git이 호환되도록 만들 수 있다는 증거입니다:
https://forge.mql5.io/junk/utf8-cyrillic-test/commit/e87d37b02e88d44305dea0f7f6630c6173471aea
메타에디터에 파일 인코딩을 변경하지 않도록 요청하기만 하면 됩니다.