다른 서버와 다른 코드베이스에 Git을 사용하려면 어떻게해야합니까?

배경 : 최근에 회사에서 일련의 프로젝트를 물려 받았으며 처리 방식과 관련된 몇 가지 근본적인 문제를 해결하려고합니다. 즉, 이전 개발자 (더 이상 회사에 있지 않은 개발자)는 어떤 형태의 소스 제어도 사용하지 않았으며 문서를 거의 만들지 않았으며 실제로 개발 프로세스가 제대로 이루어지지 않았습니다.

이제는 주로 타사 응용 프로그램 및 API를 위해 작성된 웹 사이트와 응용 프로그램 및 도구로 구성되는 SQL 스크립트 및 기타 저장소로 구성된 3 개의 서버 (개발, 준비, 프로덕션) 서버를 보유하고 있습니다. 나의 첫 번째 생각은 변경과 수정이 이루어지기 전에이 모든 것을 Git에 넣는 것이었지만 최선의 방법을 찾는 데 어려움을 겪고 있습니다.

많은 이전 개발이 프로덕션 서버에서 직접 수행되어 각 서버의 코드 기반을 구분했습니다. 모든 차이점이 어디에 있는지 즉시 알 수는 없습니다. 개발 / 스테이징에서 수행되지 않은 프로덕션 측면의 버그 수정과 스테이징 / 프로덕션으로 이동하지 않은 개발의 새로운 기능이 있습니다. .

질문 : 이것을 구성하고 Git으로 옮기는 가장 좋은 방법은 무엇입니까? 코드의 차이점을 수용하기 위해 저장소 / 분기를 어떻게 구성합니까?

프로덕션 서버 코드 복제본에서 개발을 계속하고 개발 / 스테이징 코드 기반을 기록 참조로 유지하는 것을 고려했습니다. 어쨌든 dev / staging 코드에 대해 아무것도 모르는 것을 고려할 때 이것이 잠재적으로 시작점이 될까요? 각 웹 사이트, 도구, 스크립트 세트 등에 대한 프로덕션 서버의 저장소를 간단히 만들고 기존 개발 / 스테이징 코드에 대한 분기를 만들 수 있으며 새로운 개발은 프로덕션 서버의 코드 기반에서 분기됩니다. 이게 말이 되요?

생산물을 master새로운 저장소 의 지점 으로 밀어 넣으십시오 . 크리에이트 develop것과 지점을 한 다음에 준비 서버를 병합합니다. 해결해야 할 충돌이 생길 수 있습니다. 그 문제가 해결되면 또 다른 생성 feature_branch의를 develop하고 그것으로 개발 서버를 병합합니다. 발생하는 충돌을 해결하십시오.

생산, 스테이징 및 개발 환경을 나타내는 3 개의 브랜치가 남습니다. 생산-> master, 준비-> develop, 개발-> feature_branch. 따라서 모든 개발은 기능이 수행되고 테스트되고 안정적 ​​일 때 지점 feature_branches에서만 수행되고 병합됩니다 develop. 안정적이므로 스테이징으로 사용할 수 있습니다. 릴리스 준비가 완료되면 release지점을 잘라 develop내고 느슨한 부분을 묶고에 병합 master한 다음 새 프로덕션 빌드를 갖습니다.

이 셋업을 받고 이후 사업의 첫 번째 순서 중 하나는 병합해야 feature_branch다시 develop다음 *을하고, develop다시로 master. (가) 명심 feature_branch로를 병합 할 때 테스트되지 않은 코드와 기능, 운동주의 있도록를 포함 할 수 있습니다 develop다음과 master. 이 작업이 완료되면 모든 지점에 동일한 코드가 포함되어야하며 프로덕션 서버에서 수행 된 모든 개발은 이제 개발 "서버"로 다시 포팅됩니다.

이 모델에서 각 프로젝트는 자체 리포지토리에 있으며 해당 리포지토리에는 분기 master및 develop분기 가 있으며 feature_branches모든 작업이 수행됩니다.

의견을 해결하기 위해 편집 : 예, 이것은 Gitflow입니다.

이 전략 (또는 일반적으로 Gitflow)은 기존 3 단계 시스템 (생산, 준비, 개발)을 개발에서 생산에 이르는 명확한 병합 경로로 유지합니다. 이 방법으로 코드베이스를 가져 오면 최소한 병합을 테스트 할 수있을 때까지 프로덕션에서 상태 유지를 유지하면서 분기를 동기화 할 수 있습니다. 이것은 몇 가지 목표를 달성합니다. 소스 제어에서 코드를 가져오고 서로 다른 코드베이스를 동기화 및 병합합니다 (따라서 더 이상 프로덕션에는 버그 수정이 없지만 개발은 아님). 앞으로 사용할 멋진 프로세스를 제공합니다 (잘 정의 된 프로세스) 많은 사람들 / 팀 / 회사에서 사용합니다). OP가 Gitflow가 자신의 프로젝트 / 팀 / 회사에서 사용 / 회사가 성장함에 따라 자신의 프로젝트에 적합하지 않다는 것을 알게되면,

* 다른 피쳐 분기를 잘라 내고 명백한 새 피쳐를 제거하고 해당 분기를에 병합 develop한 다음에 병합 할 수master 있습니다. 이렇게하면 다른 모든 테스트 외에 새로운 기능을 테스트하지 않아도됩니다.

staging초기 가져 오기를위한 최상의 기준으로 코드 를 추천하겠습니다 . 그의는 때문에 변화가 production에 있지 않은 staging모든 변경하면 훨씬 적은 인해 핫픽스에,하지만 staging하지 않을 수 있습니다 production. 마찬가지로이 변경됩니다 development에없는 staging에서 변경하면 가능성이 훨씬 적은 인해 새로운 기능으로,하지만 staging하지 않을 수 있습니다 development.

초기 가져 오기 후에 기준 이 되고 싶지 않습니다staging . 변경 사항이 이전에 추적되지 않아 일시적인 상황입니다. 변경 사항을 제거하지 않고 추가하는 경우 분기 작업이 훨씬 원활하게 진행됩니다 . 초기 반입 후 가장 적합한 분기 모델로 전환하십시오.

따라서 staging코드를 staging분기 로 확인한 다음 a git checkout -b master staging를 수행 하여 master분기 를 생성 하고 프로덕션 코드를 확인하십시오. 그런 다음 a git checkout -b development staging를 수행 하여 development브랜치 를 만들고 개발 코드를 확인하십시오.

이제 체크 아웃 development분기 및 병합 master 에 그것. 이를 통해 master실제 프로덕션 환경에 대한 기록을 유지하면서 대량의 병합 충돌을 해결할 수 있습니다 . development이제 모든 환경의 모든 변경 사항이 포함됩니다. 이제 가장 적합한 분기 모델로 전환 할 수 있습니다.

역사를 갖는 것이 좋습니다. 가장 안정적인 환경에서 리포지토리 (또는 각 제품마다 하나씩)를 만듭니다. 다른 사람을 위해 가지 또는 차이를 만듭니다.

높은 수준에서 :

1. 새로운 리포지토리 만들기
2. 프로덕션 기반 작업 복사본에서 : 모두 추가, 커밋 및 푸시
3. 새 디렉토리에 대한 체크 아웃 마스터
4. 각 추가 환경에 대해 XYZ
   1. 지점 만들기 Archive-XYZ
   2. 모든 것을 XYZ소스로 교체하십시오 (.git 제외)
   3. 모두 추가, 커밋 및 푸시

또는 git diff > XYZ.diff실제로이 값에 대해 회의적이라면 실제로 커밋하고 밀기보다는 diff를 보관하십시오.

어느 쪽이든, 각 환경에서 실행중인 코드를 쉽게 비교할 수있는 상태에서 종료해야합니다. 각 코드는 각 프로젝트의 단일 시작점을 설정하는 데 사용할 수 있습니다. 그리고 무언가가 깨지면 이론적으로 변경 사항을 세 가지 환경 중 하나와 비교할 수 있습니다.