Git 사용자를 위한 Perforce?

Git 사용자를 위한 Perforce?

닫혔습니다. 이 질문은 더 많은 것이 필요합니다.집중적인현재 답변을 수락하고 있지 않습니다.

마감됨8년 전에.

잠겼습니다. 이 질문과 답변은질문이 오프라인이지만 과거의 중요성이 있기 때문에 잠겼습니다.현재 새 답변이나 상호 작용을 허용하지 않습니다.

많은 "Git for Perforce 사용자" 문서가 있지만 겉보기에는 그 반대가 거의 없습니다.

저는 이전에 Git을 사용한 적이 있고 최근에 Perforce를 많이 사용해야 하는 일을 시작했는데, 제가 자주 혼란스러워하는 것을 발견했습니다.Git의 개념은 Perforce와 전혀 일치하지 않는 것 같습니다.

Git에 익숙한 사람을 위해 Perforce를 사용하기 위한 몇 가지 팁을 마련하는 데 관심이 있는 사람?

이것은 지난 몇 주 동안 제가 계속해서 연구해 온 것입니다.아직 진화 중이지만 도움이 될 수도 있습니다.저는 퍼포스 직원입니다.

Git 사용자를 위한 Perforce 소개

Git에서 Perforce로 또는 Perforce에서 Git로 이동하는 것은 사소한 것이 아니라고 말하는 것은 거창한 절제된 표현입니다.표면적으로 동일한 작업을 수행하는 두 가지 도구이기 때문에 이들의 접근 방식은 크게 다를 수 없습니다.이 간단한 글은 Git에서 오는 새로운 Perforce 사용자들이 그들이 처한 새로운 세계를 이해하는 것을 돕기 위해 노력할 것입니다.

우리가 다이빙하기 전에 잠깐 우회합니다. 만약 당신이 Git를 선호한다면 Perforce와 함께 Git를 꽤 잘 사용할 수 있습니다.우리는 Perforce 서버와 동기화된 Git 저장소를 생성하는 Git Fusion이라는 도구를 제공합니다.Git와 Perforce 사람들은 버전 관리를 선택한 동료들의 영향을 받지 않고 동일한 코드로 작업하면서 조화롭게 살 수 있습니다.Git Fusions 13.3은 Perforce 웹 사이트에서 사용할 수 있습니다.Perforce 관리자가 설치해야 하지만 설치하면 저장소 슬라이싱 기능이 Git 사용자로서 매우 유용하다는 것을 알게 될 것입니다.

Git Fusion을 설치하도록 관리자를 설득할 수 없는 경우 Git 자체에는 Git을 사용하여 Perforce 작업 공간에서 파일을 변경하고 제출할 수 있는 Git-P4라는 Perforce 바인딩이 제공됩니다.자세한 내용은 https://git.wiki.kernel.org/index.php/GitP4 에서 확인할 수 있습니다.

아직도?좋아요, 퍼포스를 봅시다.

분류해야 할 몇 가지 용어 차이

자세한 내용을 살펴보기 전에 Git와 Perforce 간의 몇 가지 용어 차이에 대해 간략하게 설명해야 합니다.

첫 번째는 체크아웃입니다.Git에서 이것은 주어진 분기에서 당신의 작업 영역으로 코드의 복사본을 가져오는 방법입니다.Perforce에서는 이를 명령줄 또는 GUI P4V "Get Latest Revision"에서 동기화라고 합니다.Perforce는 P4V에서 체크아웃이라는 단어를 사용합니다.p4 edit명령행에서 버전 제어 시스템에서 파일을 변경할 계획임을 의미합니다.이 문서의 나머지 부분에서 저는 Perforce라는 단어의 의미로 체크아웃을 사용할 것입니다.

두 번째는 Git commit 대 Perforce 제출입니다.Git에서 커밋할 위치는 Perforce에서 제출할 것입니다.모든 작업이 공유 Perforce 버전 관리 서비스에 대해 발생하기 때문에 Perforce는 다음과 같은 기능을 제공하지 않습니다.git push마찬가지로 우리는 없습니다.pull위의 sync 명령어는 우리를 위해 파일을 가져오는 것을 처리합니다.아래에 간략하게 설명된 P4Sandbox 도구를 사용하지 않는 한 Perforce에서 순수 로컬 제출이라는 개념은 없습니다.

Perforce의 주요 개념

Perforce를 두 가지 핵심 개념으로 단순화한다면 창고와 작업 공간에 초점을 맞출 것입니다.Perforce 디포는 Perforce 서버에 있는 파일의 저장소입니다.Perforce 서버에는 디포 수가 제한되지 않으며 각 디포에는 파일 수가 제한되지 않습니다.Perforce 사용자가 디포와 서버를 서로 교환할 수 있게 사용하는 것을 자주 듣게 될 것이지만, 이들은 다릅니다.Perforce 사이트는 여러 서버를 사용하도록 선택할 수 있지만, 대부분의 경우 모든 파일이 한 서버에 있습니다.

Perforce 작업 공간 또는 클라이언트는 Perforce 서버의 파일 집합을 사용자 파일 시스템의 위치에 매핑하는 시스템의 개체입니다.모든 사용자는 사용하는 각 시스템에 대해 작업 공간을 가지고 있으며, 사용자는 동일한 시스템에 대해 두 개 이상의 작업 공간을 가지고 있는 경우가 많습니다.작업영역에서 가장 중요한 부분은 작업영역 매핑 또는 보기입니다.

작업 공간 보기는 로컬 시스템에 매핑되어야 하는 디포의 파일 집합을 지정합니다.서버에서 사용할 수 있는 모든 파일을 원하지 않을 가능성이 높기 때문에 중요합니다.워크스페이스 보기를 사용하여 원하는 세트만 선택할 수 있습니다.작업영역은 여러 디포의 콘텐츠를 매핑할 수 있지만 한 서버의 콘텐츠만 매핑할 수 있습니다.

이와 관련하여 Perforce와 Git를 비교하려면 원하는 Git 저장소 세트를 선택하고 선택합니다.각 레포는 일반적으로 관련 파일만 포함하도록 범위가 엄격합니다.이 기능의 이점은 사용자가 수행할 구성이 없다는 것입니다. 중요한 작업을 빠르게 복제하여 완료할 수 있습니다.이 기능은 하나 또는 두 개의 리포지토리로만 작업하는 경우 특히 유용합니다.Perforce를 사용하면 원하는 코드 조각을 선택하고 선택하는 데 약간의 시간이 필요합니다.

대부분의 Perforce 상점은 워크스페이스 뷰를 자동으로 생성할 수 있는 스트림을 사용하거나 스크립트 또는 템플릿 워크스페이스를 사용하여 뷰를 생성합니다.마찬가지로 많은 사용자가 사용자에게 작업 공간을 직접 생성하도록 합니다.한 작업 공간에서 여러 모듈을 매핑할 수 있는 한 가지 이점은 한 번의 체크인에서 여러 코드 모듈을 쉽게 수정할 수 있다는 것입니다. 체크인과 동기화하는 클라이언트 뷰가 유사한 사용자는 누구나 모든 코드를 올바른 상태로 유지할 수 있습니다.그러나 이것은 또한 지나치게 의존적인 코드로 이어질 수 있습니다. Git의 강제 분리는 더 나은 모듈화로 이어질 수 있습니다.다행히도 Perforce는 엄격한 모듈화도 지원할 수 있습니다.이는 모두 도구를 어떻게 사용할 것인지에 대한 문제입니다.

워크스페이스를 선택해야 하는 이유

Git에서 오는 것은 전체 작업 공간 개념이 가치보다 훨씬 더 문제가 많다고 느끼기 쉽다고 생각합니다.몇 개의 Git 저장소를 복제하는 것과 비교하면 이것은 의심할 여지 없이 사실입니다.작업 공간이 빛나고 Perforce가 수년이 지난 지금도 여전히 사업을 하고 있는 이유는 작업 공간이 개발자들을 위해 수백만 개의 파일 프로젝트를 줄일 수 있는 훌륭한 방법인 동시에 빌드 및 릴리스를 통해 하나의 권위 있는 소스에서 모든 소스를 쉽게 통합할 수 있기 때문입니다.작업 공간은 Perforce가 확장할 수 있는 중요한 이유 중 하나입니다.

작업 공간은 또한 필요에 따라 디포의 파일 레이아웃과 사용자 시스템의 레이아웃이 달라질 수 있다는 점에서 좋습니다.많은 기업들이 사업부나 프로젝트별로 사람들이 쉽게 콘텐츠를 찾을 수 있도록 자사의 조직을 반영하여 디포를 구성합니다.그러나 빌드 시스템은 이러한 계층 구조에 신경을 쓰지 않습니다. 워크스페이스를 사용하면 툴에 적합한 방식으로 창고 계층 구조를 재매핑할 수 있습니다.저는 또한 이것을 매우 유연하지 않은 빌드 시스템을 사용하는 회사들이 사용하는 것을 보았습니다. 코드는 인간에게 완전히 혼란스러운 매우 구체적인 구성이어야 합니다.이러한 회사는 작업 공간을 통해 빌드 도구가 필요한 구조를 얻는 동안 사용자가 탐색할 수 있는 소스 계층 구조를 가질 수 있습니다.

Perforce의 작업영역은 사용자가 작업할 파일 집합을 매핑하는 데 사용될 뿐만 아니라 서버에서 사용자가 동기화한 각 파일의 수정사항을 정확하게 추적하는 데 사용됩니다.이를 통해 시스템은 업데이트해야 할 파일을 확인하기 위해 파일을 검색할 필요 없이 동기화할 때 올바른 파일 집합을 사용자에게 보낼 수 있습니다.많은 양의 데이터를 사용하면 상당한 성능상의 이점을 얻을 수 있습니다.이는 감사 규칙이 매우 엄격한 업계에서도 매우 인기가 있습니다. Perforce 관리자는 어떤 개발자가 어떤 파일을 동기화했는지 쉽게 추적하고 기록할 수 있습니다.

Perforce 작업영역의 전체 기능에 대한 자세한 내용은 Configuring P4(P4 구성)를 참조하십시오.

명시적 체크아웃 대암시적 체크아웃

Git에서 Perforce로 이동하는 사용자의 가장 큰 어려움 중 하나는 명시적인 체크아웃의 개념입니다.Git/SVN/CVS 워크플로우에서 파일을 변경한 다음 버전 제어 시스템에 작업 내용을 확인하도록 지시하는 작업에 익숙하다면 매우 고통스러운 전환이 될 수 있습니다.

좋은 소식은 그렇게 선택하면 Perforce에서 Git 스타일 워크플로우로 작업할 수 있다는 것입니다.Perforce에서 작업영역에 "allwrite" 옵션을 설정할 수 있습니다.이렇게 하면 Perforce에 쓰기 가능한 비트가 설정된 디스크에 모든 파일을 써야 한다는 메시지가 표시됩니다.그런 다음 Perforce에 명시적으로 알리지 않고 원하는 파일을 변경할 수 있습니다.Perforce가 변경 사항을 조정하도록 하려면 "p4 status"를 실행합니다.필요에 따라 추가, 편집 및 삭제할 파일이 열립니다.이런 방법으로 작업할 때 "p4 동기화" 대신 "p4 업데이트"를 사용하여 서버에서 새 수정사항을 가져올 수 있습니다. "p4 업데이트"는 동기화하기 전에 변경사항을 확인하므로 "p4 상태"를 아직 실행하지 않은 경우 로컬 변경사항을 방해하지 않습니다.

명시적 체크아웃을 선택해야 하는 이유

자주 받는 질문은 "명시적인 체크아웃을 사용하려는 이유가 무엇입니까?"입니다.얼핏 보기에는 미친 디자인 결정처럼 보일 수 있지만, 명시적인 체크아웃은 몇 가지 강력한 이점을 가지고 있습니다.

명시적 체크아웃을 사용하는 한 가지 이유는 내용 변경을 위해 파일을 검색할 필요가 없기 때문입니다.소규모 프로젝트에서는 차이를 찾기 위해 각 파일의 해시를 계산하는 것이 상당히 저렴하지만, 대부분의 사용자는 작업 공간에 수백만 개의 파일을 가지고 있거나 100MB(더 크지는 않더라도) 크기의 파일을 가지고 있습니다.이러한 경우 모든 해시를 계산하는 데는 매우 많은 시간이 소요됩니다.명시적 체크아웃을 통해 Perforce는 작업할 파일을 정확히 알 수 있습니다.이러한 행동은 Perforce가 게임, 영화 및 하드웨어 산업과 같은 대형 파일 산업에서 인기 있는 이유 중 하나입니다.

또 다른 이점은 개발자들이 일반적으로 동료들이 작업하고 있는 내용이나 적어도 어디에서 작업하는지 알 수 있는 비동기식 통신을 제공한다는 것입니다.불필요한 충돌을 방지하기 위해 특정 영역에서 작업하는 것을 피하거나 팀의 새 개발자가 편집할 필요가 없는 코드로 이동했다는 사실을 알려줄 수 있습니다.제 개인적인 경험은 Git에서 일하거나 Perforce를 사용하여 제가 유일한 기여자이거나 드문 기여자인 프로젝트에 대한 모든 쓰기 작업을 수행하는 경향이 있으며 팀과 긴밀히 협력할 때 명시적인 체크아웃을 수행합니다.다행히 선택은 당신의 몫입니다.

명시적 체크아웃은 보류 중인 변경 목록의 Perforce 개념과도 잘 어울립니다.보류 중인 변경 목록은 작업을 구성하기 위해 열려 있는 파일을 넣을 수 있는 버킷입니다.Git에서는 다른 분기를 작업을 구성하기 위한 버킷으로 사용할 수 있습니다.분기도 좋지만 실제로 서버에 제출하기 전에 작업을 여러 개의 명명된 변경사항으로 구성할 수 있는 경우도 있습니다.잠재적으로 여러 분기 또는 여러 프로젝트를 하나의 작업 공간에 매핑하는 Perforce 모델을 사용하면 보류 중인 변경 목록을 통해 개별 변경사항을 쉽게 구성할 수 있습니다.

Visual Studio 또는 Eclipse와 같은 개발에 IDE를 사용하는 경우 IDE에 Perforce 플러그인을 설치하는 것이 좋습니다.대부분의 IDE 플러그인은 파일 편집을 시작할 때 자동으로 파일을 체크아웃하므로 사용자가 직접 체크아웃할 필요가 없습니다.

Git 기능에 대한 Perforce 교체

• git stash==>p4 shelve
• git 로컬 분기 ==> Perforce 쉘프 또는 태스크 분기
• git blame==>p4 annotate또는 GUI에서 Perforce Timeflapse View(퍼포스 타임랩스 뷰)

작업 연결 끊김

Perforce 버전 관리 서비스와의 연결이 끊어진 작업에는 두 가지 옵션이 있습니다(Perforce 서버에 대한 고급 용어).

P4Sandbox를 사용하여 전체 로컬 버전 및 로컬 분기 설정

원하는 대로 파일을 편집하고 'p4 status'를 사용하여 Perforce에게 당신이 한 일을 알려줍니다.

위의 두 가지 옵션을 모두 사용하면 작업영역에서 "allwrite" 설정을 사용하여 파일 잠금을 해제할 필요가 없습니다.이 모드에서 작업할 때 "p4 sync" 대신 "p4 update" 명령을 사용하여 새 파일을 동기화할 수 있습니다."p4 업데이트"는 파일에 동기화하기 전에 파일의 변경 사항을 확인합니다.

Perforce Quickstart

다음 예제는 모두 명령줄을 통해 수행됩니다.

Perforce에 대한 연결 구성

export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666

에 이 수 . " " " 를 사용합니다.p4 setWindows 및 OS X에 저장하거나 Perforce 구성 파일을 사용합니다.

작업영역 만들기

p4 workspace

# set your root to where your files should live:
Root: /Users/matt/work

# in the resulting editor change your view to map the depot files you care about
//depot/main/... //demo-workspace/main/...
//depot/dev/...  //demo-workspace/dev/...

서버에서 파일 가져오기

cd /Users/matt/work
p4 sync

작업할 파일을 체크아웃하고 수정

p4 edit main/foo; 
echo cake >> main/foo

서버에 제출

p4 submit -d "A trivial edit"

»p4 help simplePerforce에서 작업하는 데 필요한 기본 명령을 확인합니다.

기존 답변 중 어느 것도 다루지 않는 git과 p4의 가장 큰 차이점은 추상화 단위가 다르다는 것입니다.

• git에서 추상화는 패치(일명 diff, 변경 집합)입니다.커밋잇은 기본적으로 실행의 결과입니다.diff커밋할 파일의 이전 상태와 현재 상태 사이.
• 강제적으로 추상화는 파일입니다.p4의 커밋은 해당 시점의 커밋에 있는 파일의 전체 내용입니다.이것은 변경 목록으로 구성되지만, 수정본 자체는 파일 단위로 저장되며, 변경 목록은 단순히 파일의 다른 수정본을 함께 수집합니다.

다른 모든 것들은 이 차이에서 나옵니다.git의 추상화 관점에서 볼 때, 모든 파일은 일련의 패치를 순서대로 적용함으로써 완전히 재구성될 수 있기 때문에 branching 및 merge git는 고통이 없습니다.대상 분기에 없는 소스 분기의 모든 패치를 올바른 순서로 대상 분기에 적용하면 됩니다(두 분기에 중복되는 패치가 없을 경우).

Perforce 분기가 다릅니다.분기 작업을 수행하면 한 하위 폴더에서 다른 하위 폴더로 파일을 복사한 다음 서버의 메타데이터가 있는 파일 간의 연결을 표시합니다. 분기에서 분기로 integrationperforce 용어로), perforce는 원본 분기의 '머리'에 있는 파일의 전체 내용과 대상 분기의 머리에 있는 파일의 전체 내용을 살펴보고 필요한 경우 공통 조상을 사용하여 병합합니다.gitcan처럼 패치를 하나씩 적용할 수 없기 때문에 수동 병합이 더 자주 발생합니다(그리고 더 고통스러운 경향이 있습니다).

Perforce는 상당히 전통적인 개정 제어 시스템(CVS, Subversion 등과 유사)이며 일반적으로 최신 분산 개정 제어 시스템보다 덜 복잡하다고 간주되기 때문에 이러한 문서는 많지 않을 것입니다.

하나에서 다른 하나로 명령을 매핑하려는 것은 올바른 접근 방식이 아닙니다. 중앙 집중식 버전 제어 시스템과 분산형 버전 제어 시스템의 개념은 다릅니다.대신 일반적인 워크플로우를 Perforce에서 설명하겠습니다.

1. 달려.p4 edit편집할 각 파일에 있습니다.어떤 파일을 편집하고 있는지 Perforce에게 말해야 합니다.새 파일을 추가하는 경우p4 add파일을에는 파을삭경우를 합니다.p4 delete.
2. 코드를 변경합니다.
3. 려달을 합니다.p4 change변경 세트를 만듭니다.여기서 변경사항에 대한 설명을 만들고 선택적으로 변경사항 집합에서 파일을 추가하거나 제거할 수 있습니다.실행할 수 있습니다.p4 change CHANGE_NUMBER필요한 경우 나중에 설명을 편집합니다.
4. 필요한 경우 코드를 추가로 변경할 수 있습니다.파일의 추가에는 " " " "/"/" " " " " " " 를 할 수 .p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
5. 려달을 합니다.p4 sync서버에서 최신 변경사항을 가져옵니다.
6. 려달을 합니다.p4 resolve동기화로 인한 충돌을 해결합니다.
7. 변경항을준되실면행비가제출할사실행▁when▁run,를 실행합니다.p4 submit -c CHANGE_NUMBER.

사용할 수 있습니다.p4 revert파일로 변경 내용을 되돌립니다.

파일이 겹치지 않는 한 여러 변경 집합에 대해 동시에 작업할 수 있습니다. Perforce 클라이언트의 파일은 한 번에 한 변경 집합에서만 열 수 있습니다.이것은 작은 개별적인 변경사항이 있는 경우에 편리할 수 있습니다.

집합에서 있는 해야 할 하거나 "Perforce 클라이언트"를 통해 할 수 .p4 shelve 달리)git stash선반을 사용하면 로컬 트리의 파일이 반환되지 않으므로 별도로 반환해야 합니다.)

언급URL : https://stackoverflow.com/questions/17267218/perforce-for-git-users