리포지토리에 유사 콘텐츠 동기화하기

Question

나는 가능하면 특정 방법으로 동작하도록 여러 git 리포지토리를 설정하는 방법을 알아 내려고하고 있습니다. 기본적으로 우리는 여러 클라이언트에 대해 여러 저장소를 가지고 있지만 모두 시스템 디렉토리를 공유합니다. 한 클라이언트의 시스템 디렉토리가 변경되면 모든 클라이언트의 시스템 디렉토리로 변경해야합니다. 이제는 복잡성 때문에 CI 개발 시스템에 여러 환경을 사용하고 있습니다. 우리는 현재 프로덕션 환경, 클라이언트 레브 환경, qa 환경 및 개발 환경을 갖추고 있습니다. 워크 플로가 다음 환경에 대해 승인되면 해당 워크 플로 분기를 적절한 환경 분기에 병합하고 해당 워크 플로의 변경 사항 만 해당 환경에 추가 할 수 있기 때문에 다른 분기로 변환됩니다.

문제는 코드 구조가 우리의 기본 코드 인 시스템 디렉토리, 클라이언트 코드가있는 사용자 정의 디렉토리 (시스템 코드의 파일 대체에 사용되는 파일 포함) 및 클라이언트 특정 구성 디렉토리가 있습니다. 사용자 화를 쉽게하기위한 상속이나 확장이 없기 때문에 우리는 개발을 더욱 복잡하게 만드는 객체 지향 시스템이 아닙니다.

우리의 목표는이 개발 시스템을 GIT로 변환하는 것입니다. 우리가 가진 문제는 공유 시스템 디렉토리를 유지하는 것입니다. 우리는 서브 모듈을 시험해 보았지만, 서브 모듈은 덮어 쓰거나 잘못 가리키는 것을 막기 위해 많은 유지 보수가 필요하며 클라이언트 qa 분기가 항상 가리키고 있는지 확인하기 위해 과도한 지루한 작업량 때문에 영구적 인 환경 분기와도 잘 작동하지 않습니다. 시스템 하위 모듈의 qa 분기의 리드 커밋이 아니라 WF 분기의 리드 커밋이됩니다.

우리의 현재 IDE는 하위 트리 통합이없는 eclipse입니다 (하위 트리를 읽은 것만 큼 서브 모듈만큼 복잡 할 수도 있음). 우리가 정말로 필요로하는 것은 전파 된 여러 저장소를 가로 지르는 병렬 지점입니다. 예를 들어 클라이언트 리포에서 워크 플로 분기를 만들면 WF 분기가 시스템 리포와 다른 모든 클라이언트 리포지토리에서 생성됩니다. 그리고 그 작업 흐름을 qa로 변경하고 병합 할 때, system repo의 wf 브랜치 또한 qa 브랜치로 합쳐 지지만 시스템 폴더의 변경만으로 합쳐지고 커스텀 및 config 디렉토리에 대한 변경 사항은 병합되지 않습니다.

이 작품과 같은 것을 만들기에 좋은 구조가 있는지 궁금합니다. 다른 사이트 및 출처에서 읽은 모든 내용은 솔루션이 단지 그렇게하지 않는다고 말했지만 그 결정은 내 것이 아닙니다. 상위 시스템은 현재 개발 시스템을 유지하기로 결정됩니다.

내가 가진 한 가지 생각은 시스템 모듈 만있는 저장소를 만드는 경우에 통과 할 수있는 방법이 있는지 확인하는 것입니다. 그런 다음 각 클라이언트에 대해 해당 repo를 복제하고 custom 및 config 디렉토리를 추가합니다. 그런 다음 우리가 개발을 할 때 고객의 레포를 복제합니다. 나는이 방법으로 우리가 변화를 만들어 업스트림으로 밀어 넣었다면 변경이 최상위 레벨 레포로 계속 진행되는지 궁금합니다. 또한 변경 사항을 푸시 할 때 최상위 수준의 레포에서 모든 것을 가져올 수 있습니다. 이것의 다른 측면은 클라이언트 저장소에 .gitignore를 설정해야하는 것과 같은 방식입니다. 스트림을 푸시 할 때 사용자 정의 및 config 디렉토리를 무시하지만 다운 스트림을 가져올 때 해당 디렉토리가 포함됩니다.

이것에 대한 의견을 보내 주시면 감사하겠습니다. 또한 우리의 코드 호스트는 개인 gitlab 서버입니다.

죄송합니다. 너무 오래되었지만 약간의 설명이 필요한 고유 한 (좋지 않은) 시스템이 있다고 생각합니다.

미래 망할 놈의 사용자

Answer 1

이 더 자식 문제보다 조직과 구조 문제처럼 보이지만 내가 갈 줄 것이다.

repo를 만드는 대신 각 클라이언트에 대해 분기를 만든 다음 필요에 따라 병합/풀을 수행 한 다음 밀어 넣으십시오.

git을 통한 배포는 권장하지 않습니다. git은 배포하기에 적합하지 않습니다. 디자인을 공개하고 변경 사항을 기록하고 코드를 쉽게 공유 할 수 있습니다. 누군가 실수로 자격 증명을 작성하면 미친 짓을하지 않는 한 영원히 기록됩니다.이 미친 짓을하면 다른 사람의 코드도 손상됩니다. 대부분의 정상적인 사용자는 git을 사용하여 변경 사항을 커밋 및 공유하고 특정 분기를 모듈/pkg/image/container/something-stable-and-constant로 빌드 한 다음 해당 모듈을 클라이언트에 배포합니다.

여전히 배포 용으로 사용하려는 경우 git-hooks을 확인하십시오. 분기가 업데이트 될 때 자동으로 코드를 가져 오는 몇 가지 후크 (예 : 업데이트 또는 사전 수신)를 설정할 수 있습니다.

또 다른 대안으로는 클라우드 스토리지 서비스 또는 문서 기반 NoSQL 서버에 대한 모든 공유 디렉토리가 있습니다. 모든 사람이 가져올 수있는 단일 소스를 유지 관리 할 수 ​​있습니다. 이것은 완벽하지 않으며 궁극적 인 일관성은 여기저기서는 거의 문제를 일으키지 않지만 가치가있을 것입니다. 필자는 클라이언트의 디스크에있는 파일이 중요한 경우에 대해서만 조언 할 것입니다.