Git 및 Perforce로 작업하기: 통합 워크플로
팀은 Git 리포지토리에서 독립적으로 작업하지만 조직의 일부는 여전히 Perforce를 사용하여 동일한 코드베이스의 일부를 관리하는 경우를 가정해 보겠습니다. Perforce를 사용하는 팀은 마이그레이션을 계획하고 있지 않지만 여러분의 팀은 이미 Git으로 전환했습니다(여러 가지 타당한 이유로 인해). 코드베이스 간에 양방향 코드 공유 프로세스를 계속 진행하여 시간이 많이 들거나 팀을 방해하지 않으면서 두 버전에서 개발된 개선 사항을 공유할 수 있도록 하는 것이 중요합니다.
바로 이러한 경우에 이 가이드가 필요합니다. TomTom에서 이 동기화 작업은 새 릴리스마다 한 번씩 이루어집니다(한 달 반에 한 번씩 진행).
-- 이 게시물은 TomTom의 NavApps Unit에서 사용하는 Git 프로세스를 공유해 주신 Andrea Carlevato, Adolfo Bulfoni 및 Krzysztof Karczewski가 함께 작성했습니다. --
시작하기 전의 가정
이 글에서는 독자가 기본적인 Git 사용 방법과 기능 브랜치 워크플로에 익숙하다고 가정합니다. 익숙하지 않다면 시간을 내어 실습 자습서 또는 웹 세미나를 확인하세요. 준비가 되시면 다시 방문해 주세요.
이 과정에서 염두에 두어야 할 몇 가지 중요한 사항이 있기 때문에 이러한 통합을 수행할 때는 각별히 주의해야 합니다. 준비가 되셨다면 바로 시작하겠습니다!
git p4 설치
첫 번째 단계는 브리지 설치입니다. 명령줄에 다음을 입력하여 이미 설치했는지 확인합니다.
git p4시스템에 git p4가 설치되지 않은 경우 git-p4.py를 다운로드하고 PATH에 있는 폴더, 예를 들어 ~/bin(물론 제대로 작동하려면 Python도 설치해야 함)에 넣습니다.
다음을 사용하여 실행 가능하게 만듭니다.
chmod +x git-p4.py
다음을 추가하여 ~/.gitconfig 파일을 편집합니다.
[alias]
p4 = !~/bin/bit-p4.py
그런 다음 git p4를 다시 실행하면 오류가 없을 것입니다. 도구가 설치되었습니다.
관련 자료
전체 Git 리포지토리를 이동하는 방법
솔루션 보기
Bitbucket Cloud에서 Git에 대해 알아보기
워크플로 개요
초기 복제
P4의 프로젝트에서 기록의 양이 매우 많아질 수 있으므로 팀에서는 동기화할 중단 지점을 선택하여 공간과 시간을 많이 절약할 수 있습니다. git p4를 사용하면 추적을 시작할 변경 목록을 선택할 수 있습니다.
git p4 clone //depot/path/project@<earlier-cutoff-point>,<latest-changelist>- 이제 동기화를 실행하고 모든 변경 집합을 로컬로 수신했는지 확인할 수 있습니다.
git p4 sync
sync 명령은 P4의 새로운 변경 사항을 찾아서 Git 커밋으로 가져옵니다.
- Perforce
p4-integ와 직접 인터페이스할 때 사용할 브랜치의 이름을 지정합니다. 이 시점에서는remotes/p4/main에서 브랜칭하려고 합니다.
git checkout -b p4-integ origin/p4/main
후속 빠른 동기화(일명 "미끼 전략")
첫 번째 가져오기가 완료된 후 다음과 같은 명령으로 이후의 git-> p4 동기화를 수행할 수 있습니다.
git checkout p4-integ
git p4 sync위의 방법은 효과가 있지만 느릴 수 있습니다. 동기화를 실행하는 더 빠른 방법은 최근 통합에서 사용한 것과 동일한 refs를 다시 만드는 것입니다. 통합 작업을 맡은 신규 개발자가 올바른 커밋/변경 목록에서 시작하도록 하는 유용한 방법이기도 합니다.
그렇게 하는 방법은 다음과 같습니다.
p4원격 리포지토리의 이전 원본(또는 오래된)refs를 제거합니다(선택 사항):
git symbolic-ref -d refs/remotes/p4/HEAD
git update-ref -d refs/remotes/p4/mainorigin의p4-integ에서 마지막 커밋을 가리키는 인위적인(일명 모조) 원격 참조를 만듭니다.
git update-ref refs/remotes/p4/main remotes/origin/p4-integ
git symbolic-ref refs/remotes/p4/HEAD refs/remotes/p4/main훨씬 빠른 이 동기화의 유일한 단점은 git p4에서 브랜치를 명시적으로 지정해야 한다는 것입니다. 마지막 명령은 다음과 같습니다.
git p4 sync --branch=refs/remotes/p4/main
git p4가 Git 커밋 ID와 P4 간의 매핑을 추적하는 방식은 메타 데이터로 커밋에 주석을 추가하는 것입니다.
Merge pull request #340 in MOB/project from bugfix/PRJ-3185 to develop
Squashed commit of the following:
commit c2843b424fb3f5be1ba64be51363db63621162b4
Author: Some Developer
Date: Wed Jan 14 09:26:45 2015 +0100
[PRJ-3185] The app shows ...
commit abc135fc1fccf74dac8882d70b1ddd8a4750f078
Author: Some Developer
Date: Tue Jan 13 14:18:46 2015 +0100
[PRJ-3185] The app shows the rating ...
[git-p4: depot-paths = "//depot-mobile/project/": change = 1794239]참고로 최신 버전의 git p4에서 Git 커밋을 P4 변경 목록과 연결하는 메타 데이터는 커밋 메시지가 아니라 커밋 메모에 저장됩니다. TomTom 팀에서는 필요할 때 변경 목록 번호를 확인하는 작업이 약간 더 많아졌기 때문에 변경을 달갑게 받아들이지 않았습니다.
Git에서 Perforce로 변경 사항 이동
위의 빠른 동기화 작업이 완료되면 이제 git에서 Perforce로 변경 사항을 푸시할 준비가 되었습니다.
첫 번째 단계는 remotes/p4/main의 변경 사항으로 p4-integ를 rebase하는 것입니다.
git checkout p4-integ
git p4 rebase그 후에는 Perforce의 모든 새 변경 사항이 p4-integ에 적용되어 main을 업데이트할 수 있습니다.
- 그런 다음 간단히 다음을 수행할 수 있습니다.
git checkout main
git merge develop- 로컬에 최신 태그가 있는지 확인합니다.
git fetch --tagsP4에 이미 있는 커밋을 제거해야 할 경우를 대비하여 임시cleanup을 사용합니다(커밋의P4태그 참조). 커밋을 건너뛰지 않을 경우 기록을 선형화할 자동 rebase를 실행합니다.
git checkout -b cleanup #branching off from main
git rebase -s recursive -X theirs tag/last-p4-integ- 대화형 rebase를 사용하면 그 대신 다음과 같이 할 수 있습니다.
git rebase -i tag/last-p4-integ
cherry-pick을 사용하여 새 커밋을 선택하고p4-integ브랜치에 놓습니다. 그렇게 하는 이유는git브랜치인main및develop이p4-integ브랜치의 적절한 상위 항목으로 유지될 수 있다는 가정을 하지 않기 때문입니다. 사실 TomTom에서는 더 이상 그렇지 않습니다.
git checkout p4-integ
git cherry-pick tag/last-p4-integ..cleanupP4에 제출하고p4-integ를 동기화합니다.
git p4 submit
git p4 sync --branch=refs/remotes/p4/main
git reset --hard refs/remotes/p4/main- 임시 rebase 브랜치를 삭제합니다.
git branch -D cleanup
- 최근 통합 지점(태그)에 대한 포인터를 로컬에서 그리고 원격 리포지토리에서 제거합니다.
git tag -d tag/last-p4-integ
git push origin :refs/tags/tag/last-p4-integP4의 새 통합 지점을 가리키도록last-p4-integ태그를 업데이트합니다.
git checkout develop
git tag -a tag/last-p4-integ -m "tag pointer to last develop commit integrated with p4"
git push origin main
git push origin tag/last-p4-integ
git push origin p4-integP4 코드베이스에서 테스트를 실행하여 통합으로 인한 문제가 발생하지 않았는지 확인합니다.
Perforce에서 Git으로 변경 사항 이동
이 작업은 git->P4 푸시가 이미 완료된 후에 수행해야 합니다. P4에서 테스트를 성공적으로 통과한 후에 이제 다음과 같이 P4에서 git으로 변경 사항을 이동할 수 있습니다.
git checkout p4-integ
git p4 sync --branch=refs/remotes/p4/main
git p4 rebase- 다음은 들어오는 변경 사항을 한 번의 커밋으로 스쿼시하는 강력한 "다른 사용자의 변경 사항" 병합 전략을 수행하는 간단한 요령입니다. 명령은 다음과 같습니다.
git checkout -b p4mergebranch #branching off from p4-integ
git merge -s ours main ## ignoring all changes from main
git checkout main
git merge p4mergebranch --squash
git commit -m "Type your integration message"git branch -D p4mergebranch
- 위의 작업을 완료하고 나면 변경 사항을
develop에 병합합니다.
<p>Bitbucket has the following space stations:</p>
<p>
<b>Earth's Moon</b><br>
Headquarters
</p>develop에서 변경 사항을 선택한 이후에 변경 사항이 있을 수도 있으므로 먼저 병합해야 할 수도 있습니다. 하지만 last-p4-integ 태그를 올바른 커밋으로 업데이트하는 것이 중요하며 특히 개발할 병합 커밋에 업데이트하지 않아야 합니다. 이 작업을 안전하게 수행하려면 main의 현재 상태에 태그를 지정하는 것이 가장 좋습니다.
- 로컬 및 원격 리포지토리에서 이전 태그를 제거합니다.
git tag -d tag/last-p4-integ
git push origin :refs/tags/tag/last-p4-integ- 새 위치에 태그를 만듭니다.
git checkout main
git tag -a tag/last-p4-integ -m "tag pointer to last develop commit integrated with p4"- 이제
main, develop, p4-integ및tag/last-p4-integ를origin에 푸시합니다.
결론
Git과 Perforce를 사용하는 두 개발 팀을 서로 동기화하는 방법을 알아봤습니다. 위의 프로세스는 TomTom에서 시간이 지남에 따라 발전했으며 현재는 꽤 오랫동안 큰 문제 없이 실행되고 있습니다. 효과가 있기는 하지만 유지 관리하는 데 상당한 오버헤드가 발생합니다. 가능하다면 완전히 Git으로 마이그레이션하는 것이 좋습니다.
어떤 경우든 양방향 동기화를 유지하는 데 다른 접근 방식을 취하신다면 아래 댓글로 알려주세요. 아니면 @durdn 또는 @atlassiandev로 트윗을 보내주셔도 됩니다.
Andrea Carlevato, Adolfo Bulfoni 및 Krzysztof Karczewski에게 다시 한번 감사의 말을 전합니다.
이 문서 공유
다음 토픽
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
Bitbucket 블로그
DevOps 학습 경로
