답변:
지난 몇 주 동안 계속해서 노력해 온 것입니다. 여전히 발전하고 있지만 도움이 될 수 있습니다. 저는 Perforce 직원입니다.
Git에서 Perforce로 또는 Perforce에서 Git으로 이동하는 것이 쉽지 않다고 말하는 것은 큰 과소 평가입니다. 표면적으로 똑같은 일을하는 두 가지 도구이기 때문에 접근 방식이 더 다를 수 없습니다. 이 간단한 글은 Git에서 온 새로운 Perforce 사용자가 새로운 세계를 이해하도록 돕기 위해 노력할 것입니다.
우리가 뛰어 들기 전에 간단한 우회; Git을 선호한다면 Git을 Perforce와 함께 사용할 수 있습니다. Perforce 서버와 동기화 된 Git 리포지토리를 생성하는 Git Fusion이라는 도구를 제공합니다. Git과 Perforce 사람들은 동일한 코드를 사용하여 조화롭게 작업 할 수 있으며, 대부분 동료가 버전 관리를 선택해도 영향을받지 않습니다. Git Fusions 13.3은 Perforce 웹 사이트 에서 구할 수 있습니다 . Perforce 관리자가 설치해야하지만 설치하면 저장소 슬라이싱 기능이 Git 사용자에게 매우 유용 할 수 있습니다.
관리자가 Git Fusion을 설치하도록 설득력이 없다면 Git 자체에 Git-P4라는 Perforce 바인딩이 제공되어 Git을 사용하여 Perforce 작업 공간에서 파일을 변경하고 제출할 수 있습니다. 이에 대한 자세한 정보는 https://git.wiki.kernel.org/index.php/GitP4 에서 확인할 수 있습니다.
아직도 여기에? 좋아, 퍼 포스를 보자.
세부 사항에 들어가기 전에 Git과 Perforce의 몇 가지 용어 차이를 간략하게 다루어야합니다.
첫 번째는 결제 입니다. Git에서 이것은 주어진 브랜치에서 작업 영역으로 코드 사본을 얻는 방법입니다. Perforce에서는이를 명령 행 또는 GUI P4V "최신 개정 가져 오기"에서 동기화 라고합니다. Perforce는 P4V 또는 명령 행에서 checkout 이라는 단어를 사용하여 p4 edit버전 제어 시스템에서 파일을 변경할 계획임을 의미합니다. 이 문서의 나머지 부분에서는 Perforce라는 단어 의미에서 체크 아웃을 사용합니다.
두 번째는 Git commit 과 Perforce submit 이다. Git에서 커밋 할 곳은 Perforce로 제출합니다. 모든 작업은 공유 Perforce 버전 관리 서비스에 대해 수행되므로 Perforce에는 해당하는 기능이 없습니다 git push. 마찬가지로 우리는 없습니다 pull; 위의 sync 명령은 파일을 가져옵니다. 아래에 간략하게 설명 된 P4Sandbox 도구를 사용하도록 선택하지 않는 한 Perforce에는 순수 로컬 제출 개념이 없습니다.
Perforce를 두 가지 주요 개념으로 단순화하려면 저장소와 작업 공간에 중점을 둘 것입니다. Perforce 저장소는 Perforce 서버에있는 파일의 저장소입니다. Perforce 서버는 여러 저장소를 가질 수 있으며 각 저장소는 여러 파일을 포함 할 수 있습니다. Perforce 사용자가 저장소와 서버를 서로 바꾸어 사용한다는 말을 자주들을 수 있지만 서로 다릅니다. Perforce 사이트는 여러 서버를 선택할 수 있지만 가장 일반적으로 모든 파일은 하나의 서버에 있습니다.
Perforce 작업 공간 또는 클라이언트는 Perforce 서버의 파일 세트를 사용자 파일 시스템의 위치에 맵핑하는 시스템의 오브젝트입니다. 모든 사용자는 사용하는 각 머신에 대한 작업 공간을 가지고 있으며 종종 동일한 머신에 대해 둘 이상의 작업 공간을 갖습니다. 작업 공간의 가장 중요한 부분은 작업 공간 맵핑 또는보기입니다.
작업 공간보기는 로컬 시스템에 맵핑되어야하는 저장소의 파일 세트를 지정합니다. 서버에서 사용 가능한 모든 파일을 원하지 않을 가능성이 높으므로 중요합니다. 작업 공간보기를 사용하면 관심있는 세트 만 선택할 수 있습니다. 작업 공간은 여러 저장소의 컨텐츠를 맵핑 할 수 있지만 한 서버의 컨텐츠 만 맵핑 할 수 있다는 점에 유의해야합니다.
이와 관련하여 Perforce를 Git과 비교하려면 Git을 사용하여 관심있는 Git 저장소 세트를 선택하고 선택하십시오. 각 저장소는 일반적으로 관련 파일 만 포함하도록 엄격하게 지정됩니다. 이것의 장점은 사용자가 수행 할 구성이 없다는 것입니다. 당신은 당신이 관심있는 것들의 git clone을하고 당신은 끝났습니다. 하나 또는 두 개의 저장소로만 작업하는 경우 특히 좋습니다. Perforce를 사용하면 원하는 코드를 선택하고 선택하는 데 약간의 시간이 필요합니다.
많은 Perforce 상점은 작업 공간보기를 자동으로 생성하거나 스크립트 또는 템플릿 작업 공간을 사용하여보기를 생성 할 수있는 스트림을 사용합니다. 마찬가지로 많은 사람들이 자신의 작업 공간을 직접 생성하도록 사용자를 떠납니다. 하나의 작업 공간에 여러 모듈을 매핑 할 수 있다는 장점은 한 번의 체크인으로 여러 코드 모듈을 쉽게 수정할 수 있다는 것입니다. 체크인과 동기화 된 유사한 클라이언트보기를 가진 사람은 모든 코드가 올바른 상태에있게됩니다. 이것은 또한 지나치게 의존적 인 코드로 이어질 수 있습니다. Git을 강제 분리하면 모듈성이 향상 될 수 있습니다. 고맙게도 Perforce는 또한 엄격한 모듈성을 지원할 수 있습니다. 도구 사용 방법에 대한 질문입니다.
Git에서 나올 때 전체 작업 공간 개념이 가치있는 것보다 더 많은 어려움을 느끼는 것이 쉽다고 생각합니다. 약간의 Git 저장소를 복제하는 것과 비교할 때 이것은 의심의 여지없이 사실입니다. 작업 공간이 빛나고 Perforce가 몇 년이 지난 후에도 여전히 비즈니스에 종사하는 이유는 작업 영역이 개발자를 위해 수백만 개의 파일 프로젝트를 파싱하는 환상적인 방법이며, 여전히 모든 소스를 빌드 및 릴리스하기가 쉽지 않은 이유입니다. 하나의 권위있는 출처. 작업 공간은 Perforce가 확장 할 수있는 주요 이유 중 하나입니다.
작업 공간은 저장소의 파일 레이아웃과 사용자 시스템의 레이아웃이 필요할 경우 달라질 수 있다는 점에서 좋습니다. 많은 회사에서 회사 조직을 반영하도록 저장소를 구성하여 사람들이 사업 단위 나 프로젝트별로 컨텐츠를 쉽게 찾을 수 있도록합니다. 그러나 그들의 빌드 시스템은이 계층에 대해 덜 신경 쓰지 못했습니다. 작업 공간을 통해 도구에 적합한 방식으로 저장소 계층 구조를 다시 매핑 할 수 있습니다. 또한 코드가 인간에게 완전히 혼동되는 매우 구체적인 구성이어야하는 매우 융통성없는 빌드 시스템을 사용하는 회사에서이 기능을 사용하는 것을 보았습니다. 이러한 회사는 작업 공간을 통해 사람이 탐색 할 수있는 소스 계층 구조를 보유하고 있으며 빌드 도구는 필요한 구조를 갖습니다.
Perforce의 작업 공간은 사용자가 작업하려는 파일 세트를 매핑하는 데 사용될뿐만 아니라 서버가 사용자가 동기화 한 각 파일의 개정판을 정확하게 추적하는데도 사용됩니다. 이를 통해 시스템은 파일을 스캔하지 않고도 동기화 할 때 올바른 파일 세트를 사용자에게 전송하여 업데이트해야 할 파일을 확인할 수 있습니다. 많은 양의 데이터를 사용하면 성능이 크게 향상 될 수 있습니다. 이것은 또한 매우 엄격한 감사 규칙이있는 산업에서 매우 인기가 있습니다. Perforce 관리자는 어떤 개발자가 어떤 파일을 동기화했는지 쉽게 추적하고 기록 할 수 있습니다.
Perforce 작업 공간의 모든 기능에 대한 자세한 정보는 P4 구성을 참조하십시오 .
Git에서 Perforce로 이동하는 사용자에게 가장 큰 문제 중 하나는 명시 적 체크 아웃 개념입니다. 파일을 변경하는 Git / SVN / CVS 워크 플로우에 익숙하고 버전 제어 시스템에 수행 한 작업을 찾도록 지시하는 경우 매우 고통스러운 전환이 될 수 있습니다.
좋은 소식은 원하는 경우 Perforce에서 Git 스타일 워크 플로로 작업 할 수 있다는 것입니다. Perforce에서는 작업 공간에서 "allwrite"옵션을 설정할 수 있습니다. 이렇게하면 쓰기 가능한 비트 세트로 모든 파일을 디스크에 기록해야합니다. 그런 다음 Perforce에 명시 적으로 알리지 않고 원하는 파일을 변경할 수 있습니다. Perforce가 변경 사항을 조정하도록하려면 "p4 status"를 실행할 수 있습니다. 적절한 추가, 편집 및 삭제를 위해 파일을 엽니 다. 이 방법으로 작업 할 때 "p4 sync"대신 "p4 update"를 사용하여 서버에서 새 개정을 가져 오려고합니다. "p4 update"는 동기화하기 전에 변경 사항을 확인하므로 "p4 status"를 아직 실행하지 않은 경우 로컬 변경 사항을 방해하지 않습니다.
내가 자주받는 질문은 "왜 명시적인 체크 아웃을 사용하고 싶습니까?"입니다. 처음에는 홍당무가 미친 디자인 결정 인 것처럼 보이지만 명시 적 체크 아웃에는 몇 가지 강력한 이점이 있습니다.
명시 적 체크 아웃을 사용하는 한 가지 이유는 컨텐츠 변경 사항을 파일에서 스캔 할 필요가 없기 때문입니다. 소규모 프로젝트에서는 차이를 찾기 위해 각 파일에 대한 해시를 계산하는 것이 상당히 저렴하지만 많은 사용자는 작업 공간에 수백만 개의 파일을 가지고 있거나 크기가 100MB가 아닌 파일을 가지고 있습니다. 이 경우 모든 해시를 계산하는 데 시간이 많이 걸립니다. 명시 적 체크 아웃은 Perforce가 작업해야하는 파일을 정확하게 알려줍니다. 이 동작은 Perforce가 게임, 영화 및 하드웨어 산업과 같은 대용량 파일 산업에서 인기를 얻는 이유 중 하나입니다.
또 다른 이점은 명시 적 체크 아웃은 개발자가 동료가 무엇을하고 있는지 또는 적어도 어디에서 일반적으로 알 수 있도록하는 비동기 통신 형식을 제공한다는 것입니다. 불필요한 충돌을 피하기 위해 특정 영역에서 일하는 것을 피하고 싶거나 팀의 새로운 개발자가 아마도 필요하지 않은 코드로 방황했다는 사실을 알릴 수 있습니다 편집 중입니다. 저의 개인적인 경험은 Git 또는 Perforce를 사용하여 유일하게 기고자이거나 드물게 기고자 인 프로젝트에서 allwrite를 사용하고 팀과 긴밀하게 작업 할 때 명시적인 체크 아웃을하는 경향이 있습니다. 고맙게도 선택은 당신입니다.
명시 적 체크 아웃은 보류중인 변경 목록의 Perforce 개념과도 잘 어울립니다. 보류중인 변경 목록은 열린 파일을 넣어 작업을 구성 할 수있는 버킷입니다. Git에서는 다른 브랜치를 작업 구성을위한 버킷으로 사용할 수 있습니다. 브랜치는 훌륭하지만 때로는 실제로 서버에 제출하기 전에 작업을 여러 개의 명명 된 변경으로 구성 할 수있는 것이 좋습니다. 잠재적으로 여러 분기 또는 여러 프로젝트를 하나의 작업 공간에 매핑하는 Perforce 모델을 사용하면 보류중인 변경 목록을 사용하여 개별 변경 내용을 쉽게 구성 할 수 있습니다.
Visual Studio 또는 Eclipse와 같은 개발에 IDE를 사용하는 경우 IDE 용 Perforce 플러그인을 설치하는 것이 좋습니다. 대부분의 IDE 플러그인은 파일을 편집 할 때 파일을 자동으로 체크 아웃하므로 체크 아웃을 직접 수행 할 필요가 없습니다.
git stash ==> p4 shelvegit blameGUI에서 ==> p4 annotate또는 Perforce Timelapse ViewPerforce 버전 관리 서비스와의 연결을 끊는 작업에는 두 가지 옵션이 있습니다 (Perforce 서버에 대한 용어입니다).
1) P4Sandbox를 사용하여 전체 로컬 버전 및 로컬 브랜칭을 갖습니다.
2) 원하는대로 파일을 편집하고 'p4 status'를 사용하여 Perforce에게 수행 한 작업을 알리십시오.
위의 옵션을 모두 사용하면 파일을 잠금 해제 할 필요가 없도록 작업 공간에서 "allwrite"설정을 사용하도록 선택할 수 있습니다. 이 모드에서 작업 할 때 "p4 sync"대신 "p4 update"명령을 사용하여 새 파일을 동기화 할 수 있습니다. "p4 업데이트"는 파일을 동기화하기 전에 변경 사항을 파일에서 확인합니다.
다음의 모든 예는 명령 행을 통해 이루어집니다.
1) Perforce에 대한 연결 구성
export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666
이 설정을 쉘 구성 파일 p4 set에 고정하거나 Windows 및 OS X에 저장하거나 Perforce 구성 파일을 사용할 수 있습니다.
1) 작업 공간 만들기
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/...
2) 서버에서 파일 가져 오기
cd /Users/matt/work
p4 sync
3) 작업하려는 파일을 체크 아웃하고 수정하십시오.
p4 edit main/foo;
echo cake >> main/foo
4) 서버에 제출
p4 submit -d "A trivial edit"
5) p4 help simplePerforce로 작업해야하는 기본 명령을 보려면 실행 하십시오.
기존 답변이 해결되지 않은 git과 p4의 가장 큰 차이점은 서로 다른 추상화 단위를 사용한다는 것입니다.
diff되는 파일의 이전 상태와 현재 상태 사이에서 실행되는 결과입니다 .다른 것들은이 차이에서 흘러 나옵니다 . git의 추상화 관점에서 패치 세트를 순서대로 적용하여 모든 파일을 완전히 재구성 할 수 있으므로 두 분기를 병합하려면 소스 분기에 모든 패치를 적용하면되므로 git에서의 분기 및 병합은 고통스럽지 않습니다. 대상 분기에 대상 분기에 올바른 순서로 존재하지 않습니다 (두 분기에 겹치는 패치가 없다고 가정).
퍼 포스 브랜치는 다릅니다. perforce의 브랜치 작업은 한 하위 폴더에서 다른 하위 폴더로 파일을 복사 한 다음 서버 간의 메타 데이터로 파일 간의 연결을 표시합니다. (다른 한 지점에서 파일을 병합하려면 integration억지로 측면에서), 억지로는 볼 것이다 완전한 컨텐츠 소스 분기에 '머리'의과에서 파일의 전체 내용 목표 지점의 선두에있는 파일 및 필요한 경우 공통 조상을 사용하여 병합하십시오. git can처럼 패치를 하나씩 적용 할 수 없으므로 수동 병합이 더 자주 발생하고 더 고통스러워집니다.
Perforce는 꽤 전통적인 개정 제어 시스템 (CVS, Subversion 등에 더 가까운)이고 일반적으로 최신 분산 개정 제어 시스템보다 덜 복잡하다고 간주되기 때문에 그러한 문서가 많지 않을 것입니다.
한 명령에서 다른 명령으로 명령을 매핑하려고 시도하는 것은 올바른 방법이 아닙니다. 중앙 집중식 및 분산 개정 제어 시스템의 개념은 동일하지 않습니다. 대신 Perforce에서 일반적인 워크 플로를 설명하겠습니다.
p4 edit편집하려는 각 파일에서 실행하십시오 . 편집중인 파일을 Perforce에 알려 주어야합니다. 새 파일을 추가하는 경우을 사용하십시오 p4 add. 파일을 삭제하는 경우을 사용하십시오 p4 delete.p4 change변경 세트를 작성하려면 실행하십시오 . 여기에서 변경 사항에 대한 설명을 작성하고 선택적으로 변경 사항 세트에서 파일을 추가하거나 제거 할 수 있습니다. p4 change CHANGE_NUMBER필요한 경우 나중에 설명을 편집하기 위해 실행할 수 있습니다 .p4 {add,edit,delete} -c CHANGE_NUMBER FILE.p4 sync서버에서 최신 변경 사항을 가져 오려면 실행하십시오 .p4 resolve동기화로 인한 충돌을 해결하려면 실행하십시오 .p4 submit -c CHANGE_NUMBER.p4 revert변경 사항을 파일로 되 돌리는 데 사용할 수 있습니다 .
파일이 겹치지 않는 한 여러 변경 세트에서 동시에 작업 할 수 있습니다. Perforce 클라이언트의 파일은 한 번에 하나의 변경 세트에서만 열 수 있습니다. 작고 독립적 인 변경이있는 경우에 편리 할 수 있습니다.
다른 변경 세트에서 이미 열려있는 파일을 편집해야하는 경우 별도의 Perforce 클라이언트를 작성하거나 나중에을 통해 기존 변경 세트를 숨길 수 있습니다 p4 shelve. (와 달리 git stash선반은 로컬 트리의 파일을 되 돌리지 않으므로 별도로 되돌려 야합니다.)
git수년 동안 그렇게했습니다.