이는 워크플로에 적용할 수 있는 가장 간단한 개선 사항이지만 일부 개발자가 가장 어려움을 겪는 부분이기도 합니다. 다른 프로젝트 관리 도구를 사용하여 작업할 때 작업을 이미 작고 관리 가능한 작업으로 세분화했을 가능성이 높습니다. 커밋은 똑같은 방식으로 처리되어야 합니다.

한 줄의 코드가 여러 버그를 마술처럼 수정하지 않는 한, 단일 커밋은 하나의 작업이나 티켓에만 관련되어야 합니다. 더 큰 기능을 작업하는 경우 더 작은 작업으로 나누고 각각에 대해 커밋하세요.

작은 커밋을 사용하는 것의 가장 큰 장점은 문제가 발생하는 경우 바람직하지 않은 변경 사항을 훨씬 더 쉽게 감지하고 되돌릴 수 있다는 것입니다.

커밋 메시지는 프로젝트 기록을 설명합니다. 결국 커밋 메시지에 "이 새 테이블에서는 내 점수를 이길 수 없을 것입니다!" 대신 "메뉴에 높은 점수 테이블을 추가했습니다"라고 표시되면 게임에 높은 점수 테이블을 추가한 변경 사항을 찾는 것이 훨씬 쉽습니다. ”

Jira 또는 GitLab과 같은 작업 티켓팅 시스템으로 작업할 때 커밋에 티켓 번호를 포함하는 것이 훨씬 좋습니다. 스마트 커밋과 함께 작동하도록 많은 시스템을 설정하여 실제로 티켓을 참조하고 커밋 메시지에서 상태를 변경할 수 있습니다.

예를 들어, “JRA-123 #close #comment task done”이라는 커밋은 Jira 티켓 JRA-123을 종료로 설정하고 티켓에 “task done”이라는 댓글을 남깁니다.

이 워크플로 설정에 대한 자세한 내용은Jira의 설명서또는GitLab의 Pivotal Tracker 서비스를 참조하세요.

"commit -a"("모든 변경 사항 커밋"을 위한 Git 명령) 또는 해당 명령을 사용해야 하는 유일한 시간은 프로젝트의 첫 번째 커밋일 때입니다. 일반적으로 프로젝트의 유일한 파일이 README.md인 경우입니다.

커밋에는 리포지토리에 커밋하는 변경 사항과 관련된 파일만 포함되어야 합니다. 일부 변경 사항으로 인해 장면, 프리팹, 스프라이트 아틀라스 등 여러 파일을 변경할 의도가 없었음에도 변경된 것으로 표시될 수 있으므로 Unity 프로젝트 작업 시 특히 주의해야 합니다.

예를 들어, 다른 사람이 작업 중인 장면에 실수로 변경 사항을 커밋한 경우 변경 사항을 커밋하고 먼저 변경 사항을 병합해야 한다는 사실을 확인할 때 골치 아픈 일이 될 수 있습니다.

이는 버전 관리를 처음 접하는 사람들이 저지르는 가장 흔한 실수 중 하나입니다. 프로젝트에 자신의 변경 사항만 커밋해야 한다는 점을 이해하는 것이 중요합니다. 자세한 내용은 작업 흐름 속도를 높이는 방법에 대한이 블로그 게시물을확인하세요.

가능한 한 자주 저장소의 최신 변경 사항을 작업 복사본으로 가져오세요. 병합 충돌의 가능성만 증가시키므로 단독으로 작업하는 것은 좋은 생각이 아닙니다. 각 시스템의 일반적인 일일 작업 흐름에 대한 아이디어를 얻으려면 위의 표를 참조하세요.

Plastic SCM 워크플로우는 중앙 집중식, 분산형 또는 다중 사이트 구성으로 작업할 수 있다는 점에서 약간 다릅니다.

다중 사이트 구성은 각 사용자가 중앙 집중식 또는 분산 워크플로에서 작업하는 매우 고유할 수 있습니다.

다음 예를 고려하십시오.

• 두 팀
• 각 팀에는 현장 서버가 있습니다.
• 팀 구성원은 로컬로 체크인하거나 각 사이트에서 분산하여 체크인하지만 가까운 현장 서버의 속도 이점을 누릴 수 있습니다.
• 서버는 완전히 또는 부분적으로 동기화를 유지하기 위해 서로 밀고 당깁니다.

팀이 작업하기로 선택한VCS에 관계없이 모든 사람이 VCS를 편안하게 사용하고 원하는 도구를 이해하고 있는지 확인하십시오.

Git으로 작업하는 경우 모든 사람이 동일한 GUI 클라이언트를 사용할 필요는 없습니다. 하지만 모든 사람이커밋 > 풀 > 푸시워크플로에 편안함을 느끼는지 확인하는 것을 최우선으로 생각하세요. 즉, 필요한 파일만 커밋할 수 있는 지식이 있어야 합니다.

Plastic SCM으로 작업하는 경우 팀의 아티스트가 작업 흐름을 단순화하기 위한 사용자 친화적인 GUI인Gluon에 익숙해지도록 권장하십시오. Gluon을 사용하면 작업하려는 파일을 결정할 수 있으므로 전체 프로젝트를 다운로드하고 관리할 필요가 없습니다. 또한 파일을 잠가서 다른 사람이 작업하는 것을 방지할 수도 있습니다. 작업이 끝나면 파일을 다시 저장소에 제출하고 필요에 따라 다시 잠금을 해제하세요.

여러 릴리스 주기가 있는 장기 프로젝트를 작업할 때 기능 분기는 작업 흐름에 매우 유용합니다. 종종 팀은 트렁크, 마스터 또는 메인이라고 불리는 저장소의 동일한 분기에서 작업합니다.

이렇게 하면 전체 프로젝트가 동일한 타임라인을 따라 이동합니다. 그러나 팀으로서 보다 효과적으로 공동 작업을 수행하려면 작업을 여러 분기로 분할하는 것이 유용할 수 있습니다.

Git에서 Git Flow라는 특정 워크플로우는 기능, 버그 수정 및 릴리스를 위해 다양한 브랜치를 사용하는 데 중점을 둡니다.

따라서 개발자가 격리된 분기 내부에서 새로운 기능 작업을 시작하면 작업이 완료되면 기본 분기로 다시 병합됩니다. 한편, 다른 팀원은 아직 개발 중인 기능을 포함하지 않고도 이전 릴리스에 대한 핫픽스를 수행하거나 버그를 수정하고 새 버전을 안전하게 릴리스할 수 있습니다.

Plastic SCM에는작업 분기기능도 있습니다. 이 패턴의 경우 추적하는 모든 작업에 대해 새 분기를 만듭니다. Git Flow에서는 기능 분기를 사용하여 완전한 기능, 때로는 대규모 기능을 개발합니다. Plastic SCM의 작업 분기는 수명이 짧습니다. 작업을 구현하는 데 몇 가지 이상의 커밋이 필요한 경우 더 작은 작업으로 나눌 수 있습니다.

Perforce Helix Core는Streams 라는 시스템을 사용하여 이러한 스타일의 워크플로우를 촉진합니다. 작업할 디포를 생성할 때스트림 디포 유형으로 설정해야 합니다. 그런 다음스트림 그래프 보기를사용하여 새 스트림을 생성할 수 있습니다. 모든 스트림(메인라인 스트림 제외)에는 변경 사항을 업스트림으로 다시 복사할 수 있도록 상위 스트림이 있어야 합니다.

목적에 따라 다양한 유형의 스트림이 있습니다. 로컬 워크스테이션에서 스트림 간을 전환하거나 변경 사항을 다시 업스트림으로 복사하면 변경된 파일의 메타데이터만 병합되어 컨텍스트 변경이 더 빨라집니다.

기능 브랜치에 대한 작업을 완료한 후에는 끌어오기 요청을 사용하여 변경 사항을 저장소의 기본 스트림으로 다시 가져오는 것이 좋습니다. 풀 요청은 기능이나 작업 개발자가 생성합니다. 변경 사항을 메인라인에 적용하기 전에 검토하는 것은 일반적으로 수석 개발자 또는 DevOps 의 책임입니다.

Plastic SCM과 Perforce에는 둘 다 분기를 다시 메인라인으로 병합하는 데 도움이 되는 자동화된 도구가 있습니다. Plastic SCM은Mergebot의 도움으로 이를 수행합니다. Mergebot은 검토 및 검증을 통과한 저장소의 분기를 자동으로 병합합니다. Perforce에는 자동화된 테스트를 통해 설정할 수도 있는 코드 검토 관리에 사용되는 추가 플랫폼인Helix Swarm이있습니다.

솔로 프로젝트를 진행하는 경우에도 구성 및 버전 제어 원칙은 정말 유용할 수 있습니다.

팀과 함께 작업할 때는 명확한 의사소통을 우선시하는 것이 중요합니다. 그룹으로서 프로젝트를 구성하는 방법, 사용할 버전 제어 시스템, 해당 시스템의 워크플로가 어떤 모습이어야 하는지에 대한 지침에 동의해야 합니다.

이렇게 하면 Jira, GitLab, 빌드 도구 또는 자동화된 테스트와 같은 다른 도구를 통합하기 시작할 때 프로젝트 및 워크플로를 구성하기 위해 이미 수행한 작업이 고유하게 표시됩니다.