시작하며: 회사에서 Perforce Helix core를 사용하면서 드는 생각들

21년에 퍼포스 기능에 대한 포스트를 한 10개 안되게 만들어보면서 회사 내에도 그렇고 외부에도 그렇고 참 자료가 없다는 것을 느낍니다.
다들 퍼포스를 알게 모르게 쓰고 있는 것일까? 아니면 내부 자료로만 정리되고 있는걸까 하기도 하구요.

이참에 퍼포스를 사용하는 곳과 검색 트렌드를 좀 확인해보고 자료가 없다면 정리해서 조금씩 만들어보고자 합니다.
(이 글에서 말하는 퍼포스는 버전 관리 프로그램인 Perforce Helix Core를 의미합니다.)

퍼포스 사용하는 회사들

저는 주로 퍼포스는 게임 개발 회사에서 사용한다고 알고 있었습니다. 에픽에서 사용하는 것으로 알고있긴해요.
(엔진 코드가 github에는 올라가 있지만 Perforce를 사용하고 있다고 들었습니다.)

퍼포스를 사용하고 있는 회사는 여기서 확인할 수 있었습니다.
https://www.perforce.com/customers

Industry를 보니 당연히 게임 개발이 있고 다른 카테고리로는 이커머스, 자동차 회사, 우주항공 쪽도 있습니다.
(NASA, 포르쉐도 있네요. 😈)
각 회사에서 사용하는 프로그램은 조금씩 다르긴합니다. 각 회사에서 사용하는 프로그램을 보면,
Helix Core / Hansoft / Helix QAC 요렇게 나눠서 보여주고 있습니다.

• Helix Core: 버전 관리 프로그램 https://www.perforce.com/products/helix-core
• Hansoft: 애자일 툴 https://www.perforce.com/products/hansoft
• Helix QAC: C, C++ 정적 코드 분석 프로그램 https://www.perforce.com/products/helix-qac

각 프로그램에 대한 자세한 내용은 따로 다루지 않고 넘어가겠습니다.
저는 Helix Core를 어디서 얼마나 어떻게 쓰고 있는지가 궁금해서요. 😸

유비소프트(Ubisoft)

Featured Customer로 되어있는 유비소프트 케이스 스터디를 좀 보겠습니다.
https://www.perforce.com/case-studies/vcs/ubisoft

• 2000명 이상의 개발자가 소스코드와 작업 애셋들(그래픽, 애니메이션 등)을 저장하고 있음
• API 용이성, 유연성 / 이상적인 브랜치 방식 / 프록시 서버 효율성
• 개발 환경
  • 개발자: 2000명
  • 파일 수: 5TB(24,070,195개 파일)
  • 변경 수: 166,642,479 리비전 (337GB 메타데이터)
• 아티스트와 모델러는 P4V와 P4GT 그래픽 도구용 플러그인을 이용하여 작업하기도 했음
• P4Report를 사용해서 애셋과 코드에 대한 리포트 생성을 단순화했음
  • 따로 확인해보니 p4 report 명령어는 없고 p4 files, p4 changes 등의 명령어로 정보를 관리한 것으로 보입니다
• 개발 속도를 높이기 위해 자주 사용하는 파일 캐시를 제공하고자 Perforce Proxy(P4P) 활용
• 많은 사내 도구가 개발되면서 소스 제어와 상호작용할 수 있는 유연한 API가 필요했음
• API가 유연해서 유비소프트 내부 도구와 통합할 수 있어서 생산성이 향상되었음

여기도 오래동안 게임을 개발한 곳이어서 개발자 수, 파일 수가 어마어마하네요.
퍼포스를 사용한 이유는 브랜치 방식도 방식인데 내부 개발 도구와 API 연동도 몫을 했나봅니다.
내부 생산성을 위해 툴 개발 및 시스템 구축했다는 것이 인상깊었습니다.

CD Projekt Red

다른 게임사인 CD Projekt Red 포스트도 한번 보겠습니다.
https://www.perforce.com/case-studies/vcs/cd-projekt-red

위쳐 개발하면서 사용했던 이야기를 써두었네요. (사이버펑크 개발할때도 썼겠죠 😸)

• 개발환경
  • 개발자: 450명 이상
  • 데이터베이스 크기: 205GB
  • 저장소 크기: 10TB
  • 파일 수: 1500만개
• 매일 최대 50-60GB 대용량 데이터 작업 진행
  • 큰 파일을 작업하고 동기화하는데에 적합하다고 보고 있음
• 빌드 자동화: Helix Core와 빌드 시스템을 통합하여 변경 사항을 모니터링하고 테스트, 컴파일함
  • 수정된 내역이 포함된 빌드가 완료되면 버그를 자동으로 닫음

앞서 보았던 유비소프트보다는 개발자 수가 적지만 저장소 크기와 파일 수는 꽤나 큽니다.
파일수에 비해 저장소 크기가 큰 것을 보니 글에 있는 내용대로 파일이 큰 작업들을 다 저장소에 올리는 것으로 보입니다.
작업물에 대한 공유를 모두 퍼포스를 통해서 하는 것 같네요.
(다른 클라우드 서비스보다 퍼포스를 사용하는게 아닐까 싶기도하구요.)

그외의 회사들

Helix Core 외에 다른 게임 회사들은 어떤 것을 쓰고 있나 보았습니다.

• EA, Capcom은 Hansoft를 이용해서 작업을 관리하고 있는 것 같습니다
• Epic Games는 Helix Core를 사용하고 있긴하지만 따로 포스트를 올리지는 않았네요
• 영상으로 사례를 올린 곳은 영상의 길이가 짧아서 딱히 알 수 있는 것이 별로 없었습니다

구글 검색 트렌드

퍼포스에서 소개한 회사의 이야기는 들어보았으니 구글에서 사용자들이 얼마나 검색하는지를 알아보겠습니다.
Perforce, SVN, Git으로 확인해보니..

Git이 압도적이어서 Perforce가 아예 바닥에 있어서 보이지를 않네요. Perforce만 두고 기간을 늘려서 보겠습니다.

2000년 초반까지만해도 꽤 많은 검색량이 있었는데 2010년들어서는 많이 떨어졌네요.
나라별로는 세인트헬레나, 대한민국, 이스라엘, 중국, 캐나다, 미국 순으로 많이 검색했네요.

검색량만 봤을때, 지금은 대부분의 회사에서는 소스관리 프로그램 Git을 주로 쓰는 것 같고
Perforce는 게임 개발 회사에서는 몇몇 큰 회사에서 쓰고 있는 것 같습니다.

생각 마무리

어디 퍼포스 쓰는 회사 얼마나 되는지 살짝 맛을 보았습니다. 아무래도 게임 개발에 있어서 큰 애셋 파일들의 동기화가 시간이 걸리는데 그것에 대한 강점이 있고 작업물의 통합에도 편리함이 있으니 사용하는 것 같습니다.
슬쩍 확인해보니 국내 게임 회사들도 꽤나 쓰고 있는 것 같네요. (N사, S사, P사 등)
https://www.perforce.com/support/self-service-resources/documentation 퍼포스 가이드 문서도 이것저것 있는데 아무래도 영어이기도하고 활용하기 어렵게 작성되어있기도해서 조금씩 공부하면서 포스트 해볼 것 같습니다.
가이드 문서가 부족해도 회사에서 쓰고 있는 시스템이니 생산성을 올릴 수 있는 방법도 고민해야하고 가이드 문서들도 좀 챙겨보고 그래야겠죠. ㅎㅎ
이만 생각 포스트 마치겠습니다.

들어가며

앞선 Perforce 베이직 포스트에서는 P4V 클라이언트에서 기본적인 뷰의 구성이나 기능들을 확인해보았습니다.
이번 포스트에서는 워크스페이스를 구성하고 파일을 Submit하고 Depot에 잘 반영되었는지 확인하는 과정을 살펴보려해요.

준비 사항

파일 수정 및 submit 전에 작업할 워크스페이스를 설정해주세요.
우선 P4V를 실행합니다.

1. Server는 사용하고자하는 Perforce 서버 주소를 입력합니다.
2. User는 로그인하고자하는 사용자 ID를 입력합니다.
   1. 사용자 ID는 Open Connection 창에서도 새로 만들 수 있을 수 있지만,
   2. 사내 계정 서비스 또는 LDAP 등으로 계정 관리가 되고 있다는 가정하에 ID를 입력하겠습니다.
3. Workspace는 New를 눌러서 새로운 워크스페이스를 만들어보겠습니다.

Workspace 만들기

1. 앞선 Open Connection 화면에서 Workspace New 버튼을 클릭합니다.
2. Workspace 만드는 화면에서 아래의 값들을 입력, 선택합니다.
   1. Workspace name: 워크스페이스 이름을 입력해주세요. 입력한 값에 따라 Workspace root(경로) 값이 맞춰서 변경됩니다.
   2. Workspace root: 워크스페이스 경로입니다. 경로 변경이 필요할 경우 Browse를 통해 경로를 확인하고 변경할 수 있습니다.
   3. Stream: 워크스페이스와 연결할 Stream을 입력합니다. Browse를 통해 스트림을 찾을 수 있고 입력창에서도 자동완성으로 찾을 수 있습니다.
3. 모두 입력한 뒤에 OK를 누르면 워크스페이스가 생성됩니다.
4. 다른 워크스페이스를 사용하고자할 경우에는 Workspace Browse를 통해 워크스페이스 리스트를 확인할 수 있습니다.
5. 워크스페이스가 생성이 완료되었습니다! 🎉

Workspace로 가서 작업을 시작해보죠!

이제 워크스페이스도 만들었으니 작업하러 들어가보겠습니다.
처음에 들어가면 아래와 같은 화면을 볼 수 있을거에요. (상세한 탭 구성은 저와 살짝 다를 수 있습니다 😈 )

왼쪽에 있는 Depot, Workspace 뷰에 작업할 파일 목록이 보여야하는데 처음에는 보이지 않을겁니다.
아직 워크스페이스와 연결된 depot 스트림에서 데이터를 동기화하지 않았기 때문이죠.
Get Latest를 눌러서 최신화를 해보면 파일들이 최신 데이터 상태로 동기화될겁니다.

Get Latest를 하면 오른쪽 이미지 처럼 폴더 내에 파일이 생긴 것을 확인하실 수 있습니다.
(설마 Get Latest를 하고 있는데 Perforce 서버가 죽거나 다른 분이 파일을 다 삭제하지 않았다면요 🤡 )

파일 작업을 하려면 Perforce에서는 Check Out하고 작업을 시작해야합니다.
(Check Out을 하지 않고 작업을 시작할 경우 각 OS 파일 시스템에서는 파일 잠금을 해제하라고 경고창이 나올거에요.)

Code 파일(Non Exclusive File) 작업

코드, 텍스트 파일 혹은 Non Exclusive 파일 작업의 경우, Check Out 후 바로 작업할 수 있습니다.
Check Out and Open을 눌러주시고 중간에 Select Pending Changelist 창에서 Changelist를 생성합니다.
(이미 작업중인 Changelist에도 추가할 수 있으나 처음 작업한다는 가정하에 Changelist 생성해보겠습니다.)

default Changelist 생성 후 파일이 열립니다. 파일을 수정하고 저장해보았습니다.
Pending 탭에 있는 빨간색 세모 아이콘이 있는 default Changelist에 파일이 있을거에요.

파일 항목에서 마우스 오른쪽 클릭 후 “Diff against have revision”을 해보면 현재 가지고 Revision과 아직 반영하지 않은 수정한 내역의 변경 사항을 확인할 수 있습니다.
(P4V와 함께 사용되는 P4Merge가 실행될겁니다. P4Merge가 없다면 설치하거나 다른 IDE를 통해서 볼 수 있어요.)

수정한 파일 내용이 문제가 없는 것을 확인했다면 실제 스트림에 반영하기 위해 Changelist를 Submit 합니다.

1. Pending Changelist 항목에서 마우스 오른쪽 클릭 후 Submit을 선택합니다.
2. Submit Changelist 창에서 Changelist 설명(Description) 항목에 값을 입력합니다.
   1. 설명에는 작업에 대한 상세 내용과 ITS(jira, redmine 등)를 사용한다면 issue 키를 입력합니다.
   2. Perforce job을 사용한다면 job을 입력하기도합니다.
3. 모든 값이 잘 입력되어있다면 Submit!
4. 변경사항(Changelist)이 잘 제출되었는지는 History 또는 Submitted 탭에서 확인할 수 있습니다.

Asset 파일(Exclusive File) 작업

앞서 코드, 텍스트 파일은 Non Exclusive 파일이어서 체크아웃 후 바로 작업가능한 것으로 말씀드렸습니다.
주로 이미지 파일이나 게임 개발시 사용하는 머터리얼 애셋 등은 대부분의 경우 Exclusive로 설정되어있습니다.

Exclusive로 설정되어있을 경우 내가 작업하고자 A.png 파일을 체크아웃 할 경우,
다른 사람은 내가 체크아웃을 해제할 때까지 A.png 파일을 사용할 수 없습니다.

이미지 파일 또는 애셋 파일들은 여러 사람이 동시 작업할 경우 변경 사항의 컨플릭트를 해결하기 어렵기에
동시 작업을 할 수 없도록 약속을 만들었다고 이해하시면 좋을 것 같습니다.
(SVN, Git lfs에도 있는 파일 Lock 기능입니다.)

• pineoc_main3(user1)에서 test1.png 파일을 수정하기 위해 test1.png를 체크아웃합니다.
• pineoc_main(user2)에서도 test1.png 파일을 수정하려고했더니 이미 Lock이 되어있어서 체크아웃할 수 없습니다.
• pineoc_main3(user1)에서 작업이 끝나고 Lock이 풀려야 pineoc_main(user2)에서 작업이 가능합니다.

위 경우는 동일한 사용자의 워크스페이스 뿐만 아니라 다른 사용자의 워크스페이스에서도 체크아웃이 이뤄지면 파일은 잠기게됩니다 (Lock).

이후 작업을 완료하고 Submit하는 과정은 텍스트 수정 작업과 동일합니다.

작업된 Changelist 확인하기

워크스페이스에서 체크아웃, 파일 수정, 서밋까지 했으니 잘 반영되었는지 확인해보겠습니다.
보통은 작업 후 잘 반영되었는지 History탭에서 Revision을 확인해봅니다.

왼쪽은 워크스페이스에서의 History, 오른쪽은 리모트 depot 스트림의 History입니다.

서밋한 내용이 정확히 반영되었는지 보고 싶다면 해당 리비전에 마우스 오른쪽 클릭 후 diff를 이용해 확인해볼 수 있습니다.
(이미지도 어떤 변경이 있었는지 알 수 있지만 다른 바이너리 파일들은 안됩니다.)

마무리

이렇게 워크스페이스 생성부터 파일 서밋까지 간단하게 정리해보았습니다.
Perforce를 사용하는 곳이 많지 않다보니 하나하나 가이드 문서가 소중한 느낌이긴하네요. 조금조금 팁이 생길 때 마다 포스트 남겨보겠습니다.
이 문서가 하시는 업무에 도움이 되기를 바랍니다. 🙇‍♂️

다른 Perforce 가이드 문서들

• P4V 소개 - 기본 개념 및 Cheat Sheet
• Perforce Client(P4V) basics
• Perforce(P4V) bookmark(북마크)
• Perforce(P4V) Revision Graph(리비전 그래프) 기능
• Perforce(P4V) Search(검색) 기능
• Perforce(P4V) Workspace(작업공간) 관리
• Perforce(P4V) Stream(스트림)
• Perforce Stream, task stream / 태스크 스트림
• Perforce(P4V) Time lapse 기능

Perforce Stream(스트림)?

지난 포스트에서 작업공간(workspace)를 살펴보았는데요. Perforce(P4V) Workspace(작업공간) 관리
이번에는 작업공간과 연결되는 서버 쪽 작업공간, 스트림을 살펴보겠습니다.
(작업공간보다는 브랜치가 더 익숙한 것 같긴합니다 😸)

가이드 문서: perforce - about streams

Stream Depot

Git에서 저장소(Repository)와 같은 역할을 하는 Depot입니다.
Depot 내에는 많은 스트림들이 있고 여러 유형의 스트림이 있습니다.

스트림 유형(Stream types)

• Mainline: 최상위 스트림으로 메인 브랜치로 볼 수 있습니다.
• Release: 안정적인 소스 상태로 관리하기 위한 스트림으로 주로 안정적인 릴리스를 준비하기 위해 사용하는 스트림입니다.
• Development: 개발이 이뤄지는 피쳐 스트림입니다.
• Task: 작은 단위의 작업을 할 때 사용할 수 있는 특수한 스트림입니다. 자세한 내용은 링크를 참고하세요.
• Virtual: 특정 인원에게 제한된 뷰를 제공하기 위한 스트림입니다. 자세한 내용은 링크를 참고하세요.

스트림 그래프(Stream Graph)

스트림 그래프를 보면 스트림간의 부모-자식(Parent-child) 관계를 설정할 수 있다는 것을 알 수 있습니다.
이 관계에 따라 코드의 변경 사항을 전파할 수 있습니다. (rebase, merge할 수 있다는 이야기입니다.)

그래프 방향에 맞춰서 머지 다운(merge down), 카피 업(copy up)이라는 액션을 통해 소스를 머지, 리베이스합니다.
가이드 문서에서는 Propagation(전파)라고 표현하고 있습니다.

이 전파 방식의 목표는 안정적이지 않은 스트림을 보다 안정적인 부모 또는 자식으로 최신 상태를 유지하여
변경 사항이 덜 안정적인 스트림에서 보다 안정적인 스트림으로 전파될 때 덮어쓰지 않도록 하는 것입니다.

가이드 문서에 있는 내용을 가져왔더니 좀 어렵게 설명이 되었네요. 😢
“스트림을 안정적으로 만들고 유지하는 것을 계층으로 전파하는 방식을 통해 이뤄질 수 있도록 했다” 정도로 이해하면 될 것 같습니다.

그래프에 있는 이미지를 짧게 살펴보면,

• rel1 : 릴리스 타입의 스트림으로 main1을 통해 머지 다운, 카피업 (전파)합니다
• main1 : 메인라인 타입의 스트림으로 rel1과 전파할 수 있으며 dev1, dev2과 통신(전파)할 수 있습니다.
• dev1, dev2 : 각각 개발 타입의 스트림으로 main1과 전파하며 각자 dev11, dev22와 전파할 수 있습니다.
• dev11, dev22 : 개발 스트림의 개발 스트림으로 main1에는 직접 전파하지 못하고 dev1, dev2를 통해 전파할 수 있습니다.

여기서 각 스트림 노드에 회색이냐, 파란띠가 둘러져있냐는 부모 스트림 상속(Inherit) 유무를 뜻합니다.
파란띠는 noinherit 으로 상속하지 않았다는 표시, 회색 노드는 상속했다는 표시입니다.

상속한 경우 부모 파일을 공유하거나 다른 경로에 맵핑할 수 있습니다. 자세한 내용은 스트림 뷰 설정에서 확인할 수 있습니다.
(스트림 뷰 설정도 내용이 많아서 따로 정리해서 공유하겠습니다.)

스트림 정리!

짧게 살펴본 스트림 정리해보겠습니다.

1. Perforce에는 Depot(저장소) 하위에 스트림들이 있습니다.
2. 스트림은 git에서 브랜치 와 비슷한 친구로 이해할 수 있습니다.
3. 스트림은 계층 구조를 가질 수 있고 여러가지 타입으로 설정할 수 있습니다.
4. 스트림 간의 코드 전파는 git 브랜치와 다르게 머지 다운, 카피 업과 같은 액션으로 코드를 머지하고 싱크합니다.

스트림 정리는 이만 마치고 다음 포스트에서 스트림 뷰 설정과 상속에 대해 공부하고 정리해보겠습니다. 😸

다른 Perforce 가이드 문서들

• P4V 소개 - 기본 개념 및 Cheat Sheet
• Perforce Client(P4V) basics
• Perforce(P4V) bookmark(북마크)
• Perforce(P4V) Revision Graph(리비전 그래프) 기능
• Perforce(P4V) Search(검색) 기능
• Perforce(P4V) Workspace(작업공간) 관리
• Perforce(P4V) Stream(스트림)
• Perforce Stream, task stream / 태스크 스트림
• Perforce(P4V) Time lapse 기능

Time-lapse(타입 랩스) 기능?

P4V에는 파일의 변경 내역을 Slider를 이용해서 리비전, 체인지리스트 단위로 볼 수 있는 타입 랩스 기능이 있습니다.

• Perforce Video Guide: Time lapse view
• https://www.perforce.com/manuals/p4v/Content/P4V/advanced_files.timelapse.html

타임랩스 기능을 보는 방법은 간단합니다. 파일에서 오른쪽 버튼을 누르고 Time-lapse View를 누르면 확인하실 수 있습니다.
위 화면은 Time-lapse view의 Single revision 모드의 화면입니다. 파일 리비전 단위로 슬라이드를 움직여 히스토리가 변경되는 것을 볼 수 있습니다.

아래에 있는 내용은 가이드 문서에 있는 Toolbar 설명 테이블 내용을 간단히 정리해보았습니다.

타임랩스 뷰 메뉴 설명

Functions	Descriptions
Mode	얼마나 많은 리비전을 보여줄지 결정하는 옵션입니다. - Single revision: 한번에 하나의 리비전을 보여줍니다. - Incremental diffs: 2개의 인접한 리비전의 변경된 것을 강조해서 보여줍니다. - Multiple revisions: 특정 범위 리비전의 변경된 것을 강조해서 보여줍니다.
Content range	시작과 끝 리비전을 정의합니다.
Scale	시점 단위를 체인지리스트로 볼 것인지, 날짜, 리비전으로 볼 것인지 정의합니다.
User	수정한 유저를 보여줍니다.
Aging	수정 사항이 얼마나 오래되었는지 색으로 보여줍니다.
Line numbers	줄 번호를 보여줍니다.
Lifetimes	파일에 인접한 텍스트 청크가 얼마나 오래 같이 있었는지 그래픽 너비(width)를 통해 수명을 보여줍니다.
Direct history	브랜치 히스토리를 제외하고 파일 리비전 히스토리를 보여줍니다.
Branch history	브랜치 히스토리(머지, 인테그레이션)를 보여줍니다. 브랜치 정보는 타임라인 밑에 나타납니다.
Originating changelist	각 리비전의 원래 체인지리스트에 대한 정보를 보여줍니다.
Find	파일에서 텍스트 기반으로 검색한 결과를 보여줍니다.
Go to line number	지금 보이는 코드 라인을 지정해서 봅니다.
Go to Next diff	다음 변경 사항
Go to Previous diff	이전 변경 사항
Line ending	줄바꿈 관련 설정

Incremental diffs mode

Incremental diffs 모드는 인접해있는 2개의 리비전의 변화를 볼 수 있는 모드입니다.
현재 리비전과 직전의 리비전의 차이와 어떤 것이 변경되었는지 빠르게 볼 수 있을 것 같네요.
2개의 리비전 정보도 같이 볼 수 있어서 변경 사항을 파악하는데 유용해보입니다.

Multiple revisions mode

이 모드는 설정한 범위 내의 리비전 변화를 볼 수 있습니다.
특정 범위 내에서 변경 사항을 확인하고 어떤 사람이 어떤 변경을 했는지 집중해서 확인하기에 좋을 것 같네요.

이미지 타임랩스 뷰

이미지의 경우 타임랩스 뷰를 통해 변화되는 것을 볼 수 있습니다.

https://www.perforce.com/manuals/p4v/Content/P4V/advanced_files.timelapse_image.html

가이드 문서나 비디오에서도 기능에 대한 스크린샷이 없네요. 😂
실제 테스트 해보니 이미지 변화를 페이드인/아웃해서 보여줍니다. (이미지가 크면 메모리 많이 먹겠다는 생각이 드네요 ㅎㅎ)
어지간한 이미지 파일 형식은 다 지원하는 것 같습니다.

타입랩스 뷰 소개 마무리

타임랩스 뷰 기능에 대해 간단히 살펴보았습니다.
코드 변경된 내용을 확인하는 데에는 좋은 것 같은데 언어에 따라 포맷팅해주지는 못하는 것 같아 아쉽긴하네요. (P4V 기능 대부분 그런 것 같긴하지만 말이죠 😂)

이만 포스트 마칩니다.

P4V 리비전 그래프 기능

P4V User Guide: Viewing codeline history in the revision graph

P4V의 리비전 그래프 기능은 파일이 어떻게 변경되어왔는지 한눈에 볼 수 있는 기능입니다.
리비전 그래프 기능은 파일이나 폴더를 선택하고 오른쪽 버튼으로 Revision graph를 선택하면 볼 수 있습니다.
단축키는 Mac은 Cmd + Shift + r / Windows는 Ctrl + Shift + r 입니다.

리비전 그래프에서 그래프 선의 의미

리비전 그래프에서 각 리비전 블록과 화살표를 보실 수 있을텐데요.
각 화살표의 의미는 리비전 그래프 오른쪽 하단의 Legend에서 확인하실 수 있습니다.

Legend에서 보실 수 있듯이 색과 선의 형태에 따라 의미하는 것이 다르네요.

저도 정리하면서 어렴풋이 알던 내용을 정리한 느낌이라 좋군요. 😸

Branch, Merge, Edit 등 내용은 이름만 봐도 알 수 있을 것 같으니 이런 것이 있다 정도로 보고 넘어가겠습니다.

리비전 그래프 기능 상세

리비전 그래프에서는 리비전 상세 내용에서 어떤 Integration에 의해 생성된 리비전인지, Label이 있는지, 코드 수정 사항이라면 짧게 Preview도 볼 수 있습니다.

• Details - 리비전의 상세 내용을 알 수 있습니다. 서밋 날짜, changelist, 설명 등이 포함되어있습니다.
• Integrations - 리비전이 어떤 Integration에 의해 만들어졌는지 알 수 있습니다. (그냥 서밋이면 해당 항목은 보이지 않습니다.)
• Labels - 해당 리비전에 설정된 레이블을 보여줍니다.
• Preview - 파일의 프리뷰를 보여줍니다. 파일이 크거나 바이너리일 경우에는 볼 수 없습니다.

마무리

리비전 그래프를 볼 수 있다는 점에서 소스트리 커밋 그래프와 비슷하지만 파일 단위의 히스토리 그래프를 볼 수 있다는 점에서 특장점이 있는 것 같습니다.
파일이 어떻게 머지되고 브랜치에 포함되었는지 볼 수 있어서 편리한 기능이라고 생각합니다.
리비전 그래프 기능 자체가 직관적이라 간단하게 소개해도 내용은 충분했을 것 같네요.
다음에는 타임 랩스 기능을 포스트해보겠습니다.