Version Control에 대한 베스트 프랙티스

워크플로를 가장 간단하게 개선할 수 있지만, 일부 개발자들은 가장 어려움을 겪고 있습니다. 다른 프로젝트 관리 툴을 사용하는 경우, 이미 작업을 관리하기 쉬운 작은 작업으로 분할한 적이 있습니다. 커밋은 정확히 같은 방식으로 처리해야 합니다.

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

작은 커밋을 사용하면 문제가 발생하면 원치 않는 변경 사항을 훨씬 쉽게 감지하고 되돌릴 수 있다는 장점이 있습니다.

프로젝트의 이력을 설명하는 커밋 메시지 결국 게임에 높은 점수표를 추가한 변경 사항을 찾는 것이 훨씬 쉽습니다. 커밋 메시지가 '메뉴에 높은 점수표를 추가했음'이 아닌 '새로운 테이블에서 내 점수를 이길 수 없다고 내기'라는 메시지가 표시됩니다.

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

예를 들어 “JRA-123 #close #comment task completed”라는 커밋을 사용하면 JRA-123의 Jira 티켓이 closed로 설정되어 티켓에 “task completed”라는 주석이 남게 됩니다.

이 워크플로를 설정하는 방법에 대한 자세한 내용은 Jira의 기술 자료 또는 GitLab의 Pivotal Tracker 서비스를 참조하십시오.

'commit -a'(Git 명령 'commit all changes') 또는 해당 부품 중 하나만 사용해야 하는 경우는 프로젝트의 첫 커밋입니다. 일반적으로 이때 프로젝트의 유일한 파일은 README.md입니다.

커밋에는 저장소에 커밋하는 변경 사항과 관련된 파일만 포함되어야 합니다. Unity 프로젝트를 작업할 때 특히 주의해야 합니다. 일부 변경 사항으로 인해 씬, 프리팩, 스프라이트 아틀라스와 같은 여러 파일이 변경된 것으로 표시될 수 있으므로 변경 사항을 적용하지 않아도 됩니다.

예를 들어 다른 사람이 작업 중인 씬에 변경 사항을 실수로 커밋하면 변경 사항을 커밋하고 먼저 변경 사항을 병합해야 한다는 사실을 알게 될 수 있습니다.

이는 Version Control 처음 접하는 사용자가 자주 범하는 실수 중 하나입니다. 프로젝트에 자체 변경 사항만 커밋해야 한다는 점을 이해해야 합니다. 자세히 알아보려면 워크플로 속도를 높이는 방법에 대한 이 블로그 게시물을 확인하세요.

적절한 빈도로 저장소에서 최신 변경 사항을 작업 복사본으로 가져옵니다. 병합 충돌의 가능성이 높아지므로 별도로 작업하는 것이 좋지 않습니다. 각 시스템의 일반적인 일일 워크플로에 대한 아이디어는 위 표를 참조하세요.

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

멀티사이트 구성을 사용하면 각 유저. '광고 지면'의 타겟 고객 중앙 집중형 또는 분산형 워크플로에서 작업할 수 있습니다.

다음 예시를 생각해 보세요.

• 두 팀
• 각 팀에는 현장 서버가 있습니다.
• 팀원들은 현장에서 로컬로 체크인하거나 분산된 방식으로 체크인하지만, 현장 서버의 긴밀한 속도 활용
• 서버가 서로 푸시 및 풀링하여 전체 또는 부분 동기화 유지

팀에서 작업하려는 VCS에 관계없이 모든 사람이 편안하게 사용할 수 있고 사용 가능한 도구를 이해하는지 확인합니다.

Git 사용하는 경우 모두가 같은 GUI 클라이언트를 사용할 필요는 없습니다. 그러나 모든 사람이 commit > pull > push 워크플로에 익숙하다고 느끼는지 우선적으로 확인하십시오. 다시 말해 필요한 파일만 커밋할 수 있는 지식이 있어야 합니다.

Plastic SCM을 사용하는 경우, 팀의 아티스트가 유저. '광고 지면'의 타겟 고객 GUI인 Gluon에 익숙해지도록 유도하여 워크플로를 단순화하세요. Gluon을 사용하면 작업할 파일을 결정할 수 있으므로 전체 프로젝트를 다운로드하고 관리할 필요가 없습니다. 또한 파일을 잠그면 다른 팀원이 작업할 수 없게 됩니다. 완료되면 파일을 저장소로 다시 제출하고 필요에 따라 다시 잠금 해제합니다.

릴리스 주기가 여러 개인 오래된 프로젝트에서 기능 브랜치는 워크플로에 큰 도움이 됩니다. 보통 팀은 저장소의 같은 브랜치에서 작업하며, 이를 트렁크, 마스터, 메인이라고 합니다.

이렇게 하면 전체 프로젝트가 동일한 타임라인을 따라 이동합니다. 하지만 작업을 여러 브랜치로 나누면 팀에서 더 효과적으로 협업할 수 있습니다.

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

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

Plastic SCM에는 작업 브랜치도 있습니다. 이 패턴에서는 추적하는 모든 작업에 새 브랜치를 생성합니다. Git Flow에서는 기능 브랜치를 사용하여 완전하고 때로는 큰 기능을 개발합니다. Plastic Scm 작업 브랜치는 짧은 수명을 자랑합니다. 작업을 구현하는 데 몇 번 이상의 커밋이 필요하면 더 작은 작업으로 나눌 수 있습니다.

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

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

기능 브랜치 작업이 완료되면 풀 리퀘스트를 사용하여 저장소의 메인 스트림으로 변경 사항을 다시 가져오는 것이 좋습니다. 풀 리퀘스트는 해당 기능 또는 작업의 개발자가 생성합니다. 일반적으로 시니어 개발자 또는 DevOps 변경 사항을 메인라인에 적용하기 전에 검토해야 합니다.

Plastic Scm Perforce 모두 메인라인으로 병합하는 브랜치를 관리할 수 있는 자동화 툴을 제공합니다. Plastic SCM은 저장소의 브랜치를 검토하고 검증을 통과한 후 자동으로 병합하는 Mergebot의 도움으로 이를 수행합니다. Perforce에는 코드 검토를 관리하는 데 사용되는 추가 플랫폼인 Helix Swarm이 있습니다. 자동화된 테스트를 통해 설정할 수도 있습니다.

1인 프로젝트에서도 조직 및 Version Control 원칙이 정말 유용할 수 있습니다.

팀과 협업할 때는 명확한 커뮤니케이션을 우선시하는 것이 중요합니다. 그룹으로서 프로젝트를 어떻게 구성해야 하는지, 어떤 Version Control 시스템을 사용해야 하는지, 해당 시스템의 워크플로가 어떻게 되어야 하는지에 대해 동의해야 합니다.

이렇게 하면 Jira, GitLab, 빌드 툴, 자동화 테스트와 같은 다른 툴을 통합하기 시작하면 프로젝트와 워크플로를 구조화하는 작업이 자체적으로 이루어집니다.