Plastic SCM - GitSync 가이드

소개

이제 아시겠지만, Plastic SCM은 모든 기능을 갖춘 분산형 버전 관리 소프트웨어(DVCS)입니다. 또한 Plastic SCM은 Git 네트워크 프로토콜을 사용합니다.

Plastic SCM은 모든 원격 Git 서버에 변경사항을 직접 내보내고 가져올 수 있으며, 그 이유는 Plastic에서 https:// and git:// protocols를 내보내기 및 가져오기 체인지 세트에 모두 지원하기 때문입니다.

이 기능은 Plastic SCM을 Git과 완전하게 호환되는 DVCS로 즉시 전환합니다. 이는 워크스테이션에서 Plastic이나 Git을 사용할 수 있고 Git 프로젝트(GitHub, CodePlex 등 다수)에도 계속 참여할 수 있다는 장점으로 이어집니다.

GitSync 소개

GitSync는 GitHub에 연결된 기본 Windows DVCS로, 이는 새로운 접근 방식일 수 있습니다. 따라서 GitSync는 사실상 Plastic SCM을 본격적인 Git용 Windows 클라이언트로 전환합니다.

참고: GitSync는 엄밀히 말하면 새로운 Git 클라이언트가 아닙니다. 클라이언트에서 Plastic SCM을 사용해도 https는 Git 프로토콜을 사용하여 Git 서버에 내보내거나 가져올 수 있습니다.

GitHub(또는 Bitbucket이나 CodePlex)를 사용하는 개발자라면 어떤 경우든 코드에 클라우드 기반 리포지토리를 사용하고 Windows를 사용해 개발하는 것을 선호합니다. 강제로 CLI를 사용해야 하거나 정말 뛰어난 GUI 툴이 부족한 것을 선호하지 않습니다.

따라서 클라우드 리포지토리, DVCS 기능, 뛰어난 Windows용 툴 등 모든 것을 갖추고 싶을 것입니다.

GitSync를 사용하면 모두 확보할 수 있습니다.

기능 목록

GitSync의 기능은 다음과 같습니다.

직접 내보내기/가져오기 - 모든 커밋, 코멘트, 브랜치, 병합 추적, 태그가 포함됩니다.
파일 추가/삭제 또는 이동 - 두 측에 적용되는 제한은 없습니다.
전체 병합 추적 - Git 측에서 병합할 수 있고 Plastic에서 이 병합 추적을 인식합니다. Plastic에서 Git으로의 방향도 마찬가지입니다. 이는 모든 기능을 갖춘 DVCS인 Plastic SCM과 Git이 가지는 장점입니다.
충돌 관리 - Git 측과 Plastic 측의 동일한 브랜치에서 동시에 변경할 수 있으며 Plastic은 데이터 교환을 처리하고, 변경사항을 가져오고, 사용자에게 병합 실행을 요청한 다음, 해결된 충돌을 내보냅니다(전체 Git 설정을 사용하는 경우처럼).

작동 방식

이미지로 보면 훨씬 이해하기 쉬우므로, 내보내기 및 가져오기의 전체 과정을 단계별로 살펴보겠습니다.

초기 시나리오

Git 리포지토리를 생성한 후 Plastic에 가져옵니다. 그러면 Git에 있는 브랜치와 커밋을 포함하면서 Plastic으로 변환된 클론을 갖게 됩니다. 이 방식은 브랜치 탐색기에서 렌더링할 수 있다는 장점이 있습니다.

Git 측에서 새 커밋 생성하기

다음 이미지는 Git 측에서 새 커밋이 생성되는 경우 어떤 일이 발생하는지 및 Plastic SCM에서 가져오기로 커밋을 어떻게 가져오는지 보여 줍니다.

이 그림은 단순히 변경을 수행하는 것뿐만 아니라 big_feature 브랜치에서 마스터로의 병합도 표시합니다. Plastic SCM 내의 결과는 Plastic 브랜치 탐색기에서 병합 링크(녹색 선으로 렌더링됨)를 추가하는 경우 Git 측에서 어떤 일이 발생했는지 표현합니다.

Plastic 측에서 새 체인지 세트 생성하기

다음은 Plastic SCM에서 변경을 수행하고 변경사항을 Git으로 내보내는 단계입니다. 단지 새 체인지 세트를 만드는 것이 아니라 보다 완벽한 예시를 구성하기 위해 병합도 수행할 것입니다.

체인지 세트 6 및 7은 Plastic에서 생성된 다음 Git으로 내보내집니다. 아래 그림에서 확인할 수 있듯이, 병합 정보(Git 리포지토리의 여러 부모)도 Plastic에서 Git으로 전송됩니다.

지금까지는 한 측 또는 다른 한 측에서 변경이 이루어졌고 양 측에서 동시에 이루어지지는 않았습니다.

동시에 변경 수행하기: 충돌

다음 그림은 개발자들이 동시에 같은 브랜치에서 작업할 때의 상황을 보여 줍니다. Git(초록색)과 Plastic(주황색)에 각각 새 커밋이 생성됩니다.

Plastic 개발자가 Git으로 내보내기를 시도하면 변경사항들이 충돌하기 때문에 오류가 표시됩니다(순수 Plastic 또는 순수 Git 설정에서도 유사한 시나리오에서 동일한 결과 발생). 다음과 같은 단계를 따라야 합니다.

먼저, Git에서 변경사항을 가져옵니다.
새 "하위 브랜치"가 생성되면서 88ffa 체인지 세트가 올바른 곳에 위치하게 됩니다.
다음으로, Plastic SCM 측에서 병합 충돌이 해결되고 내보내기가 완료됩니다.

상호작용의 마지막에는 두 리포지토리의 모습이 같아지고, 개발자가 양측에서 함께 작업하게 됩니다.

참고: Plastic SCM은 Git과 마찬가지로 모든 기능을 갖춘 DVCS이므로 git 리포지토리를 복제해 나중에 변경사항을 git 리포지토리로 전부 내보낼 수 있습니다. 단일 브랜치만 생성하는 것이 아닙니다. Plastic에서 여러 브랜치를 생성하여 Git으로 내보낼 수 있고 반대로, Git에서 여러 브랜치를 생성하여 Plastic으로 가져올 수도 있습니다.

gitsync.conf 파일

GitSync 구성 파일(gitsync.conf)을 사용하면 GitSync 작업 중에 자동으로 사용될 정보를 포함할 수 있습니다.

이 정보는 다음 두 Plastic SCM 및 Git 객체 사이의 매핑과 관련되어 있습니다.

사용자 계정
Xlink/하위 모듈 정보

gitsync.conf 파일은 반드시 다음 위치에 있어야 합니다.

Plastic SCM 클라이언트 폴더
plastic4 디렉터리(Linux/Mac 시스템의 경우 $HOME/.plastic4 아래, Windows의 경우 C:\Users\사용자\AppData\Local\plastic4 아래)

사용자 계정 매핑

gitsync.conf 파일에서 Plastic과 Git(이메일) 사이의 매핑을 정의할 수 있습니다. 매핑 정보는 Git 커밋 시 작성자 및 커미터로 사용됩니다.

정보는 다음과 같은 형식으로 email-mapping 섹션에 추가됩니다.

plastic_user = git_email_address

다음은 gitsync.conf 파일 예시입니다.

[email-mapping]
asalim = asalim@mymailprovider.com
ubuntu = ubuntu@linuxprovider.com

Plastic SCM Xlink 및 Git 하위 모듈 매핑

Git 하위 모듈은 단순히 다른 리포지토리의 커밋을 가리키는 역할만 합니다. 하위 모듈 간 작업을 전파하거나 리포지토리 간 브랜치 작업을 처리하지 않으므로 이는 하위 모듈 작업에 충분할 정도로 매우 기본적인 정보입니다.

Plastic Xlink 객체는 Git 하위 모듈보다 복잡합니다. 즉, Xlink를 사용하면 관련 서버를 설정하고 브랜치 확장 규칙을 정하며 Xlink의 쓰기 가능 여부를 정의할 수 있습니다.

일반적으로, Git 하위 모듈과 Plastic Xlink에는 다른 리포지토리의 커밋을 가리키는 동일한 임무가 있다고 할 수 있습니다. 따라서 직접 매핑이 다음 두 항목 사이에 설정될 수 있습니다.

Git 커밋 ↔ Plastic 체인지 세트
git 리포지토리 url ↔ Plastic 리포지토리 사양

GitSync를 사용하면 Git 하위 모듈에서 Plastic Xlink를 생성하거나 반대로 Plastic Xlink에서 Git 하위 모듈을 생성할 수 있습니다. Git 하위 모듈과 Plastic Xlink는 다음과 같이 GitSync를 사용하여 동기화될 수 있습니다.

가져오기 작업 중 Git 하위 모듈이 Plastic Xlink로 변환됩니다.
내보내기 작업 중 Plastic Xlink가 Git 하위 모듈로 변환됩니다.

참고로 리포지토리를 Xlink/하위 모듈과 동기화하기 전에 대상 리포지토리가 반드시 동기화되어야 합니다.

리포지토리를 Xlink/하위 모듈과 동기화하려면 gitsync.conf 파일에 매핑 정보가 추가되어야 합니다. 매핑 정보는 다음과 같은 형식으로 하위 모듈 섹션에 추가됩니다.

git_repository_url -> plastic_repository_spec [writable:true|false] [relativeserver:true|false]

Git 하위 모듈이 쓰기 가능한 Plastic Xlink에서 변환되어야 한다면 writable 필드가 writable:true로 포함되어야 합니다. writable 필드가 누락되거나 false로 설정되어 있으면 Xlink가 읽기 전용으로 생성됩니다.
Git 하위 모듈이 관련 서버가 있는 Plastic Xlink에서 변환되어야 한다면 relativeserver 필드가 relativeserver:true로 포함되어야 합니다. relativeserver 필드가 누락되거나 false로 설정되어 있으면 Xlink가 비관련 Xlink로서 Plastic 리포지토리 서버에 대해 생성됩니다.

다음은 유효한 구성의 예입니다.

[submodules]
git://localhost/code -> code@localhost:8084 writable:true relativeserver:true
git://localhost/doc -> doc@localhost:8084 writable:false relativeserver:true

GitSync 제한 사항

GitSync 사용 시 제한되는 두 가지 Git 작업은 다음과 같습니다.

rebase 명령
merge(가속화) 명령

이러한 Git 명령은 변경사항 내역에 반영되지 않습니다. 사용자가 병렬 방식으로 작업하더라도 Git에서는 선형적인 작업으로 내역에 대해 알려줍니다. 하지만 Plastic에서는 변경사항 내역 작성에 우선 순위를 둡니다.

Plastic SCM에서는 사용자가 적용한 변경사항의 전체 내역이 반영됩니다. 즉, Plastic은 내역을 재작성하지 않습니다. 그러한 방식을 지양했다기보다, 이는 설계 철학에 따른 결정이었습니다.

브랜치에서 작업하고 병합할 때 변경사항 내역이 반영됩니다. Plastic SCM에서 내역을 파악하여 보여줄 수 있으므로, GitSync를 사용할 때에는 해당 Git 명령을 사용하지 않는 것이 좋습니다.

Git에서 베이스 재설정은 미묘한 주제입니다. 내보내기 전에만 이를 수행할 수 있고(사실, 사용하지 않는 편이 좋은 경우가 많음) 베이스 재설정을 사용하면 병합에 따른 모든 어려움을 피해 내역을 파악할 수 있습니다.

Plastic에서는 Git 방식으로 베이스 재설정을 처리하지 않습니다.
Git 병합 가속화 명령은 선형적인 방식으로 병합을 해결하는 것과 비슷한 작업을 수행합니다.

merge --no-ff 명령을 사용하여 내역을 유지합니다.

Plastic에는 무슨 일이 이루어지는지 그래픽으로 파악할 수 있는 브랜치 탐색기가 있습니다. 이 방법을 사용하면 집중할 수 있고 베이스 재설정을 누락하는 일이 없습니다.

브랜치와 여러 병합을 비교하는 경우 브랜치에서 실제로 변경된 사항과 병합 결과를 확인하는 것이 어렵습니다. 이 또한 Plastic에서 해결되었습니다.

Plastic과 Git 간에 리포지토리를 동기화하는 경우 예기치 않은 결과를 방지하기 위해 Git rebase 및 merge(가속화) 명령을 사용하지 않는 것이 좋습니다.

특별한 경우가 아니면 리포지토리 내역을 재작성하는 이러한 명령을 사용하지 마십시오. 예를 들면 체인지 세트 삭제 또는 이동, 레이블 삭제 또는 이동이 있습니다.

직접 내보내기/가져오기

앞에서 설명한 대로, Plastic은 GitHub, BitKeeper, CodePlex 등의 유명 사이트를 포함해 기본 Git 및 https 프로토콜을 사용하여 원격 Git 서버로 바로 내보내거나 가져올 수 있습니다.

Git 및 Plastic SCM의 양방향 동기화를 개발하기 시작했을 때 염두에 둔 시나리오는 다음과 같습니다.

GitHub, CodePlex, BitKeeper 등과 같은 사이트의 프로젝트에 기여하려는 개발자가 이미 Plastic SCM을 사용하고 있습니다.
Git을 주 서버로 사용하는 팀에서 작업하는 개발자는 Plastic SCM 사용을 선호하지만 주 서버로 변경사항을 다시 제공해야 합니다.
Git의 다른 팀에 기여해야 하는 팀에서는 점진적으로 Plastic SCM을 도입하고 있습니다.

해결책을 마련하는 것은 매우 힘들었습니다. 많은 제약이 있었기 때문에 한 시스템에서 다른 시스템으로 변경사항을 변환하거나 빠른 임포트/익스포트를 수행하는 중간 스크립트를 고안하지 못했습니다. 하지만 Plastic에서 Git 네트워크 프로토콜을 레이어로 구현하여 Git으로 가져오거나 내보낼 수 있었습니다.

Plastic은 Git 명령을 사용하여 원격 Git 서버와의 협상 단계를 시작하고 이를 Git 프로토콜이라고 부릅니다. 이는 핵심 기능이며 추가 스크립트가 아닙니다.

앞서 설명한 대로 GitSync는 스마트 프로토콜을 구현하고 다음을 수행할 수 있습니다.

원격 Git 수신 팩과 협상하여 데이터를 업로드할 수 있습니다(어떤 체인지 세트/커밋이 필요한지 협상하고 Git으로 보낼 Plastic 리포지토리 데이터로부터 올바른 팩 파일을 생성함).
또한 원격 업로드 팩과 협상하여 패키징할 커밋을 결정하고 팩을 다운로드하여 Plastic으로 임포트합니다.

첫 번째 가져오기

먼저 GitHub 리포지토리에 연결합니다.

GitHub로 이동하여 리포지토리를 탐색하면 "트렌디" 리포지토리 등의 목록을 볼 수 있습니다. 예제 그림에서는 목록에서 corefx 리포지토리를 선택했습니다.

이제 리포지토리를 Plastic으로 가져오기 위해 "호스트"할 리포지토리(똑같은 corefx 리포지토리)를 생성하고 처음에 비어 있던 브랜치 탐색기로 이동한 다음 컨텍스트 메뉴 옵션으로 이동하여 Git과 동기화를 실행합니다.
그런 다음 동기화 다이얼로그(Plastic 서버 간 변경사항의 가져오기/내보내기를 위한 복제 다이얼로그와 매우 유사함)를 시작하고 Git 리포지토리 URL을 입력합니다.

공개 리포지토리에서 가져오기 중(복제 중)이므로 자격 증명이 필요하지 않습니다. 리포지토리를 내보내고 서버가 인증된 사용자를 요구하는 경우를 대비하여 자격 증명을 지정해야 합니다.
동기화를 누르면 프로세스(가져오기)가 다음과 같이 시작됩니다.

참고: 이 작업은 다음과 같이 명령줄을 사용하여 수행할 수 있습니다. cm sync corefx git https://github.com/corefx/corefx.git
로컬 corefx 리포지토리가 비어 있다고 가정하면 원격 GitHub 리포지토리에서 가져와야 하는 체인지 세트와 브랜치를 계산하고 이를 가져옵니다.

GitHub에서 수행한 새 변경사항을 가져오려면 같은 명령을 다시 실행하면 됩니다.
cm sync corefx git https://github.com/corefx/corefx.git
그러면 Git에서 변경된 사항이 있는 경우 새 변경사항만 계산하고 가져옵니다.

현재 Git 체인지 세트와 브랜치를 로컬 Plastic SCM 리포지토리로 바로 가져오고 있습니다.
복제가 완료되면 워크스페이스 탐색기로 돌아가서 워크스페이스를 업데이트하여 소스 파일을 다운로드합니다.
브랜치 탐색기도 새로 고칩니다. 그러면 방금 임포트한 Git 체인지 세트를 Plastic SCM 방식으로 렌더링할 수 있습니다.

이제 체인지 세트를 오른쪽 클릭(Git 용어로 커밋)하면 빌트인 비교 시스템과의 차이점을 확인할 수 있습니다.

이제 브랜치, 병합 등 Plastic에서 더 많은 변경 작업을 할 수 있습니다. 그런 다음 같은 프로세스를 반복하여 Git에 동기화합니다. 동시에 같은 브랜치에 변경사항이 발생한 경우, Git으로 다시 내보내기 전에 변경사항을 내보내거나 가져오고 병합을 해결하도록 요청할 수 있습니다.

Git으로 내보내기

Plastic 리포지토리 중 하나를 GitHub로 내보내려 합니다. 이 프로세스가 이전 프로세스와 유사한 것을 확인하게 될 것입니다.

자 그럼, 시작합니다.

Plastic 리포지토리를 GitHub로 익스포트하기 위해 새 GitHub 리포지토리를 생성했습니다.
dokancode Plastic 리포지토리를 선택했습니다. 브랜치 탐색기 뷰에서 브랜치 중 하나를 오른쪽 클릭하고, 이전 장에서처럼 Git과 동기화 메뉴 옵션을 선택합니다.

동기화 다이얼로그가 실행됩니다.
그런 다음, 필요한 경우 GitHub 리포지토리 URL과 자격 증명을 입력합니다.
그런 다음, 동기화 버튼을 클릭하여 동기화를 시작합니다. 여기에서는 Plastic 리포지토리를 내보내기(또는 익스포트)하겠습니다.

현재, Plastic SCM 체인지 세트와 브랜치를 GitHub 리포지토리로 직접 내보내고 있습니다.

참고: 이 작업은 다음과 같이 명령줄을 사용하여 수행할 수 있습니다. cm sync dokancode git https://github.com/mbctesting/dokancode.git
GitHub dokancode 리포지토리가 비어 있다고 가정하면서 GitSync는 Plastic 리포지토리에서 내보내야 하는 체인지 세트와 브랜치를 계산한 다음 내보냅니다.

내보내기 작업이 완료되면 익스포트된 객체가 포함된 요약을 확인할 수 있습니다.
GitHub로 돌아가서 dokancode 리포지토리를 새로 고치면 Plastic에서 익스포트된 객체를 확인할 수 있습니다.

이제 Plastic SCM과 GitHub 모두에서 리포지토리를 사용할 준비가 되었습니다. 이제 가져오기/내보내기를 하여 브랜치를 생성하고, 변경사항을 실행하고, 동기화를 다시 수행할 수 있습니다.

양측에서 작동

이 장에서는 GitHub와 Plastic 모두에서 dokancode 리포지토리를 사용하여 몇 가지 기본 작업을 적용하는 방법을 소개합니다.

이 단계를 반드시 살펴볼 것을 권장합니다. 양쪽에서 변경사항을 생성하기 전에 Git과 동기화 작업을 사용하여 리포지토리를 동기화해야 충돌을 피할 수 있습니다.

Git 측의 변경사항

이제 마스터 브랜치에서 일부 작업을 실행합니다.

license.txt 파일을 삭제합니다.
dokan-net-0.6.0\readme_dokan.txt 파일을 편집합니다.
그리고 해당 파일을 dokan-net-0.6.0\DokanNet 폴더로 이동합니다.
그런 다음 새 브랜치(scm007)를 생성합니다.
새 파일 두 개를 추가합니다.
그리고 다음 파일 중 하나를 편집합니다.

커밋이 완료되었으며 이제 Plastic 측에서 이를 볼 수 있습니다.

이 가이드에서 학습한 대로, GitSync는 반대 측에서 새로운 사항을 계산하고 원격 서버와 협상하여 변경사항을 내보낼 수 있습니다.

이제 Git와 동기화 작업을 실행하여 Plastic 리포지토리와 GitHub 리포지토리를 동기화하겠습니다.
동기화를 클릭하여 동기화를 시작하고 GitHub 측에서 수행한 변경사항을 Plastic 리포지토리로 내보냅니다.

동기화가 완료됩니다.
임포트된 객체에 대한 요약을 확인할 수 있습니다.
브랜치 탐색기로 돌아가서 뷰를 새로 고치면 GitHub 측에서 수행하고 Plastic으로 임포트된 변경사항을 확인할 수 있습니다.
체인지 세트 뷰를 열어 이러한 GitHub 변경사항을 확인할 수 있습니다.
더 자세히 살펴보려면 GitHub 측의 readme_dokan.txt 파일을 통해 변경사항을 확인하면 됩니다. 해당 파일의 내역을 보면 동기화를 통해 적용된 변경사항을 확인할 수 있습니다.

이제 Plastic 측에서 계속 변경을 수행할 수 있습니다.

Plastic 측의 변경사항

scm005 브랜치에서 변경 작업을 수행하려 합니다. 이 시점에서 Git 측과 Plastic 측의 내용은 모두 동일합니다. 양쪽에서 동일한 내용을 확인할 수 있습니다.

이 브랜치에서 수행할 작업은 다음과 같습니다.

새 파일을 추가합니다.
DokanOperation.cs 파일을 편집합니다.

새로운 변경사항은 다음과 같습니다.
변경이 이루어지면 Git와 동기화 작업을 실행하여 GitHub 리포지토리를 동기화합니다.
동기화가 완료되면 요약을 확인할 수 있습니다.

이 요약은 하나의 동기화를 통해 하나의 브랜치에 포함된 두 체인지 세트를 전송했음을 알려줍니다.
GitHub 측으로 이동하면 Plastic 측에서 이루어진 새로운 변경사항을 확인할 수 있습니다.

Plastic 및 Git 브랜치 변환

Plastic 주 브랜치는 Git 마스터 브랜치에 매핑됩니다. 이 매핑은 Plastic에 있는 주 브랜치의 자식 브랜치에도 적용될 수 있습니다. 즉, Plastic 브랜치가 계층을 제거하고 / 문자를 - 문자로 교체하여 Git 브랜치로 변환됩니다. 이 규칙은 Git 브랜치가 Plastic 브랜치로 변환될 때도 유효합니다. 이때 - 문자는 Plastic에서 계층을 다시 만드는 데 사용됩니다.

앞에서 본 예에서 Plastic 브랜치 /main/scm005는 master-scm005로 변환됩니다. 그리고 마스터 아래의 Git 브랜치 scm007은 /main/scm007로 변환됩니다.

다음 예와 같이 - 문자를 브랜치 이름의 일부로 사용할 수도 있습니다.

브랜치 - Git 측	브랜치 - Plastic 측
`master`	`/main`
`master-fix-5.0`	`/main/fix-5.0`
`master-fix-5.0-task1`	`/main/fix-5.0/task1`

전체 병합 추적

Plastic SCM에서는 Git과 동일한 개념(DAG, 커밋, 병합 링크 등)을 다루므로 병합 추적을 공유하기가 상당히 쉽습니다. Git에서 병합을 수행해 본 적이 있다면 Plastic에서도 문제없이 할 수 있습니다. Plastic에서 병합을 수행해 봤다면 병합 링크도 Git으로 문제없이 내보낼 수 있습니다.

가장 다루기 어려운 기능은 "정확한 항목 추적"과 관련되어 있습니다. Plastic에서는 사용되지만 Git에서는 사용되지 않기 때문입니다. Plastic에는 각 파일 및 디렉터리와 연결된 내부 ID가 있습니다. 즉, Plastic에서는 추적하기 쉬우나 Git에서는 추적하기 어려운 수많은 병합 충돌(예: 분기 이동)을 손쉽게 처리할 수 있습니다.

다음 예에서는 GitSync를 사용하는 경우 병합 추적의 작동 방식을 알아봅니다.

Plastic 측의 병합

다음과 같이 두 개의 새 브랜치를 생성합니다.

브랜치 scm008 - DokanNet.cs 파일의 DokanResetTimeout 메서드를 편집한 뒤 파일로 다시 이동하고 새 필드를 추가합니다.
브랜치 scm009 - DokanNet.cs 파일을 다른 폴더로 이동한 뒤 DokanResetTimeout 메서드를 다른 클래스로 이동하여 편집합니다.
변경사항이 여러 브랜치에 적용되면 주 브랜치로 변경사항을 병합하여 다음과 같은 결과를 얻습니다.
이제 Git과 동기화 작업을 사용하여 Plastic 측과 Git 측에서 리포지토리를 동기화합니다. 이러한 방식으로 Git 측에서 병합을 내보냅니다.

새 브랜치를 내보냈고 병합 추적은 Git 측에서 다음과 같이 표시됩니다.

Git 측의 병합

이제 Git 측의 병합이 Plastic 측에서 추적되는 것을 살펴보겠습니다.

다음과 같이 새 브랜치를 생성한 다음 새 파일을 만들고 다른 파일을 편집합니다.
커밋이 완료되면 다음과 같이 scm010 브랜치에서 마스터 브랜치로 병합을 수행합니다.

병합은 GitSync 제한 사항 섹션에서 본 것처럼 --no-ff 옵션을 사용하여 수행합니다.

병합이 완료되었으므로 이제 해당 변경사항을 원격 git 리포지토리로 가져옵니다.
로컬 Git 변경사항이 원격 git 리포지토리로 이동했으면 리포지토리를 동기화합니다. 따라서 리포지토리가 동기화되면 최근 변경사항을 Plastic 리포지토리로 가져오게 됩니다. 다음과 같이 Git과 동기화 작업을 실행하고
동기화가 완료됐을 때 브랜치 탐색기를 새로 고치면, 변경사항과 Git 측에서 완료된 병합을 어떻게 Plastic 측으로 가져왔는지 확인할 수 있습니다.

충돌 관리

작동 원리 장의 설명대로, Plastic 측과 Git 측 두 곳에서 동시에 변경할 수 있습니다. 즉, 두 시스템에서 동일한 브랜치로 작업하고 변경사항을 조정할 수 있습니다(순수 Plastic 환경이나 순수 Git 환경을 사용할 때 하듯이).

GitSync와 Plastic을 사용하여 이러한 상황을 처리하는 방법을 알아봅니다.

앞서 사용한 예시 중 하나를 사용하여 시작하겠습니다. Git 측 변경사항 섹션에서는 GitHub 측에서 일부를 변경했습니다. 다음과 같은 작업을 수행했습니다.

마스터 브랜치에서 license.txt 파일을 삭제하고 dokan-net-0.6.0\readme_dokan.txt 파일을 편집하여 dokan-net-0.6.0\DokanNet 폴더로 이동했습니다.
그런 다음 두 파일(ArrayIndex.cs 및 ArrayInitialization.cs)을 추가하고 그중 하나(ArrayIndex.cs)를 편집하여 새 브랜치(scm007)를 생성했습니다.

그리고 이제 Plastic 측에서 일부 변경사항을 수행합니다.

주 브랜치에서 DokanNet.cs 파일을 편집합니다.
그리고 새 파일을 3개 추가합니다.

변경이 이루어진 후, Git와 동기화 작업을 사용하여 두 리포지토리를 동기화하기로 했습니다.

동기화가 완료되면 병합이 필요하다는 메시지가 전달됩니다.

이유는 Git 측과 Plastic 측에서 모두 동일한 브랜치를 변경했기 때문입니다.

요약에서 주(또는 마스터) 브랜치에 병합 작업이 필요하다는 것을 확인할 수 있습니다.

이는 사실입니다. Git 측의 마스터 브랜치에 일부 변경사항을 적용했고, Plastic 측의 주 브랜치에 일부 변경사항을 적용했습니다. 주 및 마스터 브랜치는 동일하지만 다른 이름을 사용합니다(자세한 내용은 Git-Plastic 사전 참조).

작동 원리 섹션의 설명대로, Plastic 측의 병합 충돌을 해결해야 합니다. 이제 해결해 보겠습니다.

브랜치 탐색기를 업데이트하는 경우 다음을 확인할 수 있습니다.
- 첫째, 주 브랜치에 병합해야 할 여러 "헤드"가 있습니다. 이 충돌이 Plastic SCM의 하위 브랜치로 취급되기 때문입니다.
- 둘째, scm007 브랜치가 동기화되었습니다(GitHub에서 Plastic SCM으로 가져옴).
이 충돌을 해결하기 위해 "GitHub" 헤드(하위 브랜치의 헤드)에서 병합을 실행합니다.

병합할 변경사항을 확인합니다.
모든 병합 처리 버튼을 클릭하여 항목이 자동으로 병합되었습니다.
마지막 단계는 아시다시피 대기 중인 변경사항 뷰에서 변경사항을 체크인(확정)하는 것입니다.
체크인 버튼을 클릭하면 두 "헤드"가 하나의 헤드(주 브랜치의 헤드)에만 병합되는 것을 볼 수 있습니다.
이제 병합 충돌이 해결되었습니다. 하지만 Plastic 측에서 이루어진 변경사항을 Git 측에서 내보냄으로써 동기화를 완료해야 합니다. 그리고 아시겠지만 이 작업은 Git과 동기화 작업을 사용하여 처리합니다.