[Figma] Branch 기능 살펴보기

피그마는 (오토 세이브 되는..) 버전 히스토리 기능도 매우 훌륭하다고 생각했는데, 어느새 워크 플로우를 관리하기 위한 브랜치 기능까지 추가되었다.

피그마에 작성된 브랜치 문서를 살펴보았다.

최근 브로들리 사용중이다. 이전 툴과는 다르다. 첫번째 원칙으로 단순성과 일관성에 초점을 맞췄다.

브랜치를 사용하기 적절한 예제

이미 존재하는 소스를 기반으로 작업을 시작할 때 고려하면 좋다. 특히 실험적이고, 반복적인 경우

디자인 라이브러리 유지보수

• 메인 파일은 항상 하나로 유지됨
• 공통 스타일 추가하거나 수정할때
• 기존에 존재하던 컴포넌트나 배리언츠 수정할때
• 라이브러리에 새로운 콤포넌트 만들때
• 컴포넌트 수정 제안이 편리해짐

의사 결정권자 혹은 콜라보레이터에게 공유할 때

개발 파트에 시안을 전달하기 위해 작업을 멈춰야할 때

• 기능을 위한 디자인 작업이 완료된 지점을 개발 파트에 공유할 때 시점을 지정해 전달해 디자인을 명확히할 수 있다.
• 디자인이 개발까지 완료되면, 디자인 시안은 메인 파일에 병합할 수도 있고 코드에도 병합된다
• 디자인과 개발 사이에 유사한 워크플로를 만들어 아이데이션에서 릴리즈까지 공통된 언어를 중심으로 응집력을 만들 수 있다

격리된 디자인 테스트 및 사용자 테스트

• 메인 디자인에서 분기된 파생 디자인의 프로토타입을 테스트할 수 있다

브랜치 모범 사례

네이밍 룰

• 명확하게 커뮤니케이션 할 수 있는 네이밍이 필요하다
• 개발 파트의 일반적인 브랜치 네이밍을 공유 받아 같이 사용해도 된다. 대화 및 문서에서 동일한 정보를 참조할 수 있기 때문에 전체 프로세스에 걸쳐 작업하는 데 도움이 될 수 있다.
• 예를들어, 이슈 티켓 이름, 우선순위 플래그, 업무 유형, 이모지 등을 접두어로 사용할 수 있다

브랜치 병합 (merging branches)

• 변경 사항을 메인 파일에 적용하고싶을 때, 브랜치를 병합한다.
• 엔지니어링의 PR 프로세스와 유사하다
• 코멘트와 @멘션을 활용하는것이다. editor에게 알람이 뜨면, 검토 해야할 브랜치로 넘어가 코멘트를 확인하고 추가적인 의견을 남길 수 있다 (review 단계~)
• 브랜치가 메인 파일에 병합되면, 자동적으로 모든 코멘트와 브랜치가 아카이브된다.
• 기존 버전으로 복원은 version history에서 가능하다

브랜치 보관 (archiving branches)

• 미사용 디자인을 아카이브 해도 메인 파일과 계속 연결 되어 있게 된다
• 보관된 브랜치는 언제든지 보거나, 복원할 수 있다
• 파일이 오래되어 다른 사용자가 파일에 액세스하는데 혼동을 일으킬 수 있는 여러 페이지가 생기는걸 방지할 수 있다

브랜치 사용에 부적절한 예제

탐색(exploration)을 위한 새 파일 만들기

• 처음부터 시작하거나 기존 설계에 대한 완전한 기초 정비를 수행하는 경우 새 파일부터 시작하거나 기존 파일을 복제하는 것이 좋다
• 이렇게 하면 모든 새 작업이 자체 파일로 완전히 분리되어 프로젝트, 팀 또는 개인 draft에 저장될 수 있다

모두 합의하는 마이너 업데이트

• 사소한 업데이트를 수행 중이거나 여러 공동작업자가 모두 약간의 다듬기 변경을 하는 경우 기본 파일을 업데이트한다
• 예를 들어 편집 복사, 레이어 구성, 공유 스타일을 사용하기 위한 색상 업데이트 또는 프로토타입의 와이어링은 메인 파일에서 바로 수행되어도 좋다

적극적으로 다른 디자인을 참조(referencing) 하는 경우

• 여러 개념을 탐색하거나 각 디자인을 적극적으로 참조해야 할 수 있는 다른 디자인과 협업하는 경우 동일한 파일의 페이지를 사용하는 것이 더 편리할 수 있다
• 페이지를 사용하면 개념 또는 공동작업자별로 여러 개의 스크래치 패드를 사용할 수 있으므로 페이지 간에 항목을 빠르게 이동할 수 있다

현재의 워크플로우를 유지

• 피그마는 이전 저장 지점을 새 파일로 되돌리거나 복제할 수 있는 자동 저장 및 버전 기록이 있다 (훌륭훌륭 🥴)
• 현재와 같이 계속 작업하고 협업할 수 있음

더 읽을거리: Create branches and merge changes

참고자료:

• How (and why) we built branching
• When to consider branching