답변:
Perl 5 인터프리터 소스 코드는 현재 Perforce에서 git로 변환하는 과정을 겪고 있습니다. 아마도 Sam Vilain의 git-p4raw수입업자가 관심을 가질 것입니다.
어쨌든 모든 중앙 집중식 VCS와 대부분의 분산 된 VCS에서 얻을 수있는 주요 승리 중 하나는 원시적이고 빠른 속도 입니다. 당신이 그것을 경험하기 전까지는 단지 몇 분의 1 초만에 전체 프로젝트 역사를 손에 들고 있다는 것이 얼마나 자유 롭다는 것을 상상할 수 없습니다. 각 커밋에 대한 전체 차이를 포함하는 전체 프로젝트 기록의 커밋 로그를 생성하는 것도 몇 분의 1 초로 측정 할 수 있습니다. Git은 너무 빠르면 모자가 날아갈 것입니다. 네트워크를 통해 왕복해야하는 VCS는 기가비트 이더넷 링크를 통해서도 경쟁 할 기회가 없습니다.
또한 git을 사용하면 커밋을 만들 때 신중하게 선택하는 것이 매우 쉬워 져 작업 복사본 (또는 단일 파일 내)의 변경 사항이 여러 커밋에 분산되고 필요한 경우 여러 분기에 분산 될 수 있습니다. 이렇게하면 작업하는 동안 메모를 적게 할 수 있습니다. 작업을 신중하게 계획 할 필요가 없으며 어떤 변경 사항을 적용할지 미리 결정하고 다른 작업을 연기 할 수 있습니다. 원하는대로 변경하고 커밋 할 때 거의 항상 아주 쉽게 풀 수 있습니다. 은닉 은 여기에서 매우 큰 도움이 될 수 있습니다.
나는 함께, 이러한 사실들로 인해 내가 git을 사용하기 전보다 자연스럽게 더 많은 집중 커밋을 만들 수 있음을 발견했습니다. 이는 결국 귀하의 기록을 일반적으로 더 유용하게 만들뿐만 아니라 .NET과 같은 부가가치 도구에 특히 유용합니다 git bisect.
지금 당장 생각할 수없는 것이 더있을 것 같습니다. git에서 팀을 판매한다는 제안의 한 가지 문제는 위에서 언급했듯이 많은 이점이 상호 연관되어 있고 서로 플레이한다는 것입니다. 따라서 단순히 git의 기능 및 이점 목록을 살펴보고 그 방법을 추론하기가 어렵습니다. 워크 플로를 변경하고 어떤 변경 사항을 개선할지 결정합니다. 이를 고려하고 명시 적으로 지적해야합니다.
저는 직장에서 Perforce를 사용합니다. 코드 작업을 할 때 서버에 연결할 수없는 경우에도 버전 제어를 원하기 때문에 Git을 사용합니다. 아니요, 오프라인 작업을 조정하는 것은 동일하지 않습니다. 다음은 git이 큰 이점이되는 곳입니다.
음, 그것은 내 2 센트입니다. Perforce의 방어에서 저는 고객 지원 규칙을 말해야하며 타임 랩스보기 도구도 마찬가지입니다. git로 타임 랩스 뷰를 얻는 방법을 모르겠습니다. 그러나 편리함과 시간 절약을 위해 나는 언제든지 git과 함께 갈 것입니다.
perforce에서 전환하려면 많은 설득력이 필요합니다. 두 회사에서 나는 그것을 사용하기에 충분했습니다. 둘 다 서로 다른 사무실을 가진 회사 였지만 사무실에는 충분한 인프라가 설치되어 있으므로 분리 / 분리 기능을 사용할 필요가 없었습니다.
얼마나 많은 개발자가 전환에 대해 이야기하고 있습니까?
진짜 질문은-git이 제공 할 수있는 조직의 요구 사항을 충족하지 못하는 퍼 포스에 대해 무엇입니까? 마찬가지로 git이 perforce에 비해 어떤 약점을 가지고 있습니까? 직접 대답 할 수없는 경우 여기에서 요청해도 도움이되지 않습니다. 회사의 비즈니스 사례를 찾아야합니다. (예 : 전체 소유 비용이 낮을 수 있습니다 (중간 학습 단계의 생산성 손실, 높은 관리 비용 (최소 초기) 등).)
나는 당신이 힘든 판매를하고 있다고 생각합니다-perforce는 대체하려고 시도하기에 꽤 좋은 것입니다. pvc 또는 ssafe를 부팅하려는 경우 생각할 필요가 없습니다.
전환 후 / 전환 후 사람들을 행복하게 유지하는 측면에서 초기에 접해야 할 사항 중 하나는 로컬 브랜치가 Git에 얼마나 비공개가 될 수 있는지, 그리고 실수를 할 수있는 자유가 얼마나 많은지입니다. 그들 모두가 현재 코드에서 몇 개의 비공개 브랜치를 복제하도록 한 다음 거기에서 실험을 해보세요. 일부 파일의 이름을 변경하고, 항목을 체크인하고, 다른 브랜치에서 항목을 병합하고, 기록을 되 감고, 한 세트의 변경 사항을 다른 세트 위에 리베이스하는 등의 작업을 수행합니다. 그들의 최악의 사고조차도 동료들에게 영향을 미치지 않는 방법을 보여줍니다. 개발자가 원하는 것은 개발자가 안전하다고 느끼고 더 빠르게 학습 할 수있는 상황입니다 (Git는 중요한 학습 곡선이 가파르 기 때문에). 그리고 결국 개발자로서 더 효과적 일 수 있습니다.
중앙 집중식 도구를 배우려고 할 때 분명히 저장소의 다른 사용자에게 문제를 일으키는 일부 바보를 만드는 것에 대해 걱정할 것입니다. 당혹감에 대한 두려움만으로도 사람들이 실험을하지 못하게 할 수 있습니다. 특별한 "교육"저장소가 있어도 도움이되지 않습니다. 개발자는 교육 중에 본 적이없는 프로덕션 시스템의 상황에 직면하게되므로 다시 걱정하게됩니다.
그러나 Git의 분산 된 특성은이를 제거합니다. 지역 브랜치에서 어떤 실험이든 시도해 볼 수 있으며 끔찍하게 잘못되면 브랜치를 버리고 아무도 알 필요가 없습니다. 무엇이든 로컬 브랜치를 생성 할 수 있기 때문에 실제 라이브 리포지토리에서보고있는 문제를 복제 할 수 있지만 "빌드를 깨뜨 리거나"자신을 속일 위험이 없습니다. 작업을 마치 자마자 깔끔한 작은 패키지로 일괄 작업하지 않고도 모든 것을 확인할 수 있습니다. 따라서 오늘 4 시간 동안 사용한 두 가지 주요 코드 변경 사항뿐만 아니라 중간에 기억했던 빌드 수정 사항과 동료에게 무언가를 설명하는 동안 발견 한 문서의 맞춤법 오류 등이 있습니다. 그리고 프로젝트가 방향을 바꾸고 있기 때문에 주요 변경 사항이 취소되면
개인적으로 git에서 나를 팔 았던 명령은 bisect 입니다. 이 기능은 현재 다른 버전 관리 시스템에서 사용할 수 없다고 생각합니다.
즉, 사람들이 소스 제어를 위해 GUI 클라이언트에 익숙하다면 git에 깊은 인상을받지 않을 것입니다. 현재 모든 기능을 갖춘 유일한 클라이언트는 명령 줄입니다.
git log --graphGit 개정 내역이 비선형적이고 그림없이 시각화하기 어려운 경향이 있기 때문에 GUI (또는 적어도 ) 가 필요합니다 . GitX와 SourceTree를 GUI로 사용하지만, gitk (지금 Git와 함께 제공됨)는 한 번에 통과 할 수 있습니다.
사람들이 사용하는 Perforce 기능은 무엇입니까?
모든 사람들이 명령 줄에서 가져 와서 넣는 것이면 git이이를 다루고 다른 모든 RTS도 마찬가지이기 때문에 묻습니다.
분명히 GitHub는 이제 기업에 git 교육 과정을 제공합니다 . 이에 대한 블로그 게시물을 확인하십시오 .
저는 지난 몇 주 동안 Git에서 Android 교육을 위해 Google 캠퍼스에 여러 번 방문했습니다. 저는 Shawn Pearce (당신은 그의 Git와 EGit / JGit 영광에서 그를 알고있을 것입니다. 그는 Junio가 외출했을 때 유지 보수를 맡는 영웅입니다)이 Andriod에서 작업하는 Google 엔지니어를 전환 하는 데 도움을 줄 것을 요청했습니다. Perforce에서 Git 으로 Android를 대중과 공유 할 수 있습니다. 내가 할 수있어 기뻤다.
[…]
Logical Awesome은 이제 모든 회사에 이러한 유형의 맞춤형 교육 서비스를 공식적으로 제공하고 있으며 , Git으로 전환하려는 경우 조직의 교육 및 계획을 지원할 수 있습니다.
내 강조.
저는 오랫동안 Perforce를 사용해 왔으며 최근에는 GIT도 사용하기 시작했습니다. 내 "객관적인"의견은 다음과 같습니다.
Perforce 기능 :
GIT 기능 :
전반적으로 OpenSource / Distributed 프로젝트의 경우 항상 GIT를 권장합니다. P2P 애플리케이션과 비슷하고 모든 사람이 개발에 참여할 수 있기 때문입니다. 예를 들어, Perforce로 원격 개발을 할 때 일주일에 한 번 1Mbps 링크를 통해 4GB 프로젝트를 동기화했음을 기억합니다. 그 때문에 많은 시간이 낭비되었습니다. 또한이를 위해 VPN을 설정해야했습니다.
소규모 회사가 있고 P4 서버가 항상 작동한다면 Perforce도 매우 좋은 옵션이라고 말할 수 있습니다.
우리는 한동안 Git을 사용해 왔지만 최근에 Git 서버의 하드 드라이브가 충돌하여 최신 상태로 되돌릴 수 없습니다. 우리는 며칠 전 상태로 돌아갈 수있었습니다. 서버가 백업되었을 때. 팀의 모든 사람이 변경 사항을 가져 오거나 밀어 넣고 서버가 현재 상태로 돌아 왔습니다.
Perforce와 git (그리고 가장 일반적으로 언급되는 것)의 중요한 차이점은 각각 거대한 바이너리 파일을 처리한다는 것입니다.
예를 들어, 비디오 게임 개발 회사의 직원에 대한이 블로그에서 : http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html
그러나 중요한 것은 문서에서 지금까지 빌드 된 모든 바이너리 (그리고 마지막으로, 실제 소스 기록)에 이르기까지 모든 것을 포함하는 거대한 6GB 저장소가있을 때 git과 perforce의 속도 차이는 일반적으로 거대 기업은 Perforce를 실행하는 경향이 있으므로 모든 중요한 작업을 지하에있는 거대한 서버 뱅크로 오프로드하도록 설정했습니다.
Perforce의이 중요한 이점은 Perforce와 아무 관련이없는 요소,이를 운영하는 회사가 서버 뱅크를 감당할 수 있다는 사실에서만 비롯됩니다.
어쨌든 결국 Perforce와 git은 다른 제품입니다. Git은 VCS로만 설계되었으며 Perforce보다 훨씬 더 나은 기능을 제공합니다 (일반적으로 사용하기 쉬운 더 많은 기능, 특히 다른 말로 말하자면 Perforce에서 분기하는 것은 열린 마음을 수행하는 것과 같습니다). 수술은 전문가에 의해서만 이루어져야합니다 : P) ( http://stevehanov.ca/blog/index.php?id=50 )
Perforce 이득을 사용하는 회사의 다른 이점은 Perforce가 VCS 일뿐 아니라 파일 서버 일뿐만 아니라 빌드 성능 등을 테스트하기위한 다른 여러 기능이 있기 때문에 발생했습니다.
마지막으로, Git은 오픈 소스이고 부팅에 훨씬 더 유연합니다. git을 패치하여 중요한 작업을 중앙 서버로 오프로드하여 값 비싼 하드웨어를 실행하는 것은 그리 어렵지 않습니다.
나는 GIT가 승리한다는 것을 알고있는 한 가지는 모든 파일에서 "줄 끝을 보존"하는 능력이라고 생각하지만, perforce는 파일을 Unix, Dos / Windows 또는 MacOS9 형식 ( "\ n", "\)으로 번역해야한다고 주장하는 것 같습니다. r \ n "또는"\ r).
Windows 환경 또는 혼합 OS 환경에서 Unix 스크립트를 작성하는 경우 이는 실제 고통입니다. 파일 확장자별로 규칙을 설정할 수도 없습니다. 예를 들어 .sh, .bash, .unix 파일을 Unix 형식으로 변환하고 .ccp, .bat 또는 .com 파일을 Dos / Windows 형식으로 변환합니다.
GIT (기본값인지, 옵션인지, 유일한 옵션인지 확실하지 않음)에서 "줄 끝 유지"로 설정할 수 있습니다. 즉, 파일의 줄 끝을 수동으로 변경하면 GIT가 해당 형식을 그대로 둡니다. 이것은 일을 수행하는 이상적인 방법처럼 보이며 Perforce에서 이것이 옵션이 아닌 이유를 이해하지 못합니다.
이 동작을 수행 할 수있는 유일한 방법은 파일을 바이너리로 표시하는 것입니다. 내가 알다시피, 그것은 누락 된 기능을 해결하는 고약한 해킹 일 것입니다. 모든 스크립트 등을 처리해야하는 지루한 것 외에도 대부분의 diff 등을 깨뜨릴 수도 있습니다.
지금 우리가 정한 "솔루션"은 sed 명령을 실행하여 Unix 환경에 배포 될 때마다 스크립트에서 모든 캐리지 리턴을 제거하는 것입니다. 특히 이들 중 일부는 WAR 파일 내에 배포되고 sed 라인은 압축을 풀 때 다시 실행해야하기 때문에 이상적이지 않습니다.
이것은 GIT에 큰 이점을 제공한다고 생각하는 것이며 위에서 언급하지 않은 것 같습니다.
편집 : Perforce를 조금 더 오래 사용한 후, 또 다른 몇 가지 의견을 추가하고 싶습니다.
A) Perforce에서 내가 정말로 놓친 것은 변경, 제거 및 추가 파일을 포함하여 명확하고 인스턴스 차이입니다. 이것은 GIT에서 사용할 수 있습니다.git diff 명령을 있지만 Perforce에서는 변경 사항이 기록되기 전에 파일을 체크 아웃해야하며, 파일을 편집 할 때 파일을 자동으로 체크 아웃하도록 기본 편집기 (예 : Eclipse)를 설정할 수 있습니다. 때때로 다른 방법 (메모장, 유닉스 명령 등)으로 파일을 편집 할 수 있습니다. 그리고 새 파일은 Eclipse와 p4eclipse를 사용해도 자동으로 추가되지 않는 것 같습니다. 따라서 모든 변경 사항을 찾으려면 전체 작업 공간에서 "Diff against ..."를 실행해야합니다.이 작업은 먼저 실행하는 데 시간이 걸리고 두 번째로 매우 복잡한 제외 목록을 설정하지 않는 한 모든 종류의 관련없는 항목을 포함합니다. 다음 요점으로이 끕니다.
B) GIT에서 .gitignore는 매우 간단하고 관리, 읽기 및 이해하기 쉽습니다. 그러나 Perforce에서 구성 할 수있는 작업 영역 무시 / 제외 목록은 다루기 어렵고 불필요하게 복잡해 보입니다. 와일드 카드가 작동하는 경우 예외를 얻을 수 없었습니다. 나는 다음과 같은 것을하고 싶다.
-//Server/mainline/.../target/... //Svend_Hansen_Server/.../target/...
Server / mainline 내의 모든 프로젝트 내의 모든 대상 폴더를 제외합니다. 그러나 이것은 내가 예상했던 것처럼 작동하지 않는 것 같으며 모든 프로젝트에 다음과 같은 줄을 추가했습니다.
-//Server/mainline/projectA/target/... //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/... //Svend_Hansen_Server/projectB/target/...
...
그리고 bin 폴더, .classpath 및 .projet 파일 등에 대한 유사한 줄.
C) Perforce에는 다소 유용한 변경 목록이 있습니다. 그러나 내가 그룹을 변경하고 모두 확인하고 변경 목록에 넣은 다음 해당 변경 목록을 제출하기 전에 다른 작업을 수행한다고 가정합니다. 나중에 첫 번째 변경 목록에 포함 된 파일 중 하나를 변경하면 해당 파일은 여전히 해당 변경 목록에 있으며 원래 추가 한 변경 사항 만 포함되어 있다고 가정하고 나중에 변경 목록을 제출할 수 없습니다. 동일한 파일이됩니다). GIT에서 파일을 추가하고 파일을 추가로 변경하면 해당 변경 사항이 추가되지 않으며git diff새 변경 사항을 먼저 추가하지 않으면 파일을 커밋 할 수 없습니다. 물론 이것은 추가 된 파일 세트가 하나 뿐인 변경 목록과 같은 방식으로 유용하지 않지만 GIT에서는 실제로 변경 사항을 적용하지 않으므로 변경 사항을 커밋 할 수 있습니다. 다른 변경 사항을 푸시하기 전에 작업 할 수 있지만 나중에 추가하는 다른 변경 사항도 이전 변경 사항을 푸시하지 않고는 푸시 할 수 없습니다.
나는 Git에 대한 경험이 없지만 분산 VCS이기도 한 Mercurial을 사용했습니다. 실제로 프로젝트에 따라 다르지만, 우리의 경우에는 기본적으로 잦은 고장난 빌드를 제거하기 때문에 분산 된 VCS가 프로젝트에 적합했습니다.
일부는 클라이언트-서버 VCS에 더 적합하고 다른 일부는 분산 된 VCS에 적합하기 때문에 실제로 프로젝트에 따라 다르다고 생각합니다.
git에 대해 내가 싫어하는 점은 다음과 같습니다.
우선 분산 된 아이디어가 현실 앞에서 날아 간다고 생각합니다. 실제로 git을 사용하는 모든 사람은 중앙 집중식 방식으로 수행합니다. Linus Torvalds도 마찬가지입니다. 커널이 분산 된 방식으로 관리 되었다면 실제로 "공식"커널 소스를 다운로드 할 수 없었습니다.-하나도 없을 것입니다. Linus 버전을 원하는지 Joe 버전을 원하는지 결정해야합니다. 또는 Bill의 버전. 그것은 분명히 말도 안되는 일이며 Linus가 중앙 집중식 워크 플로를 사용하여 제어하는 공식 정의가있는 이유입니다.
중앙 집중식 정의를 원하면 서버와 클라이언트 역할이 완전히 다르기 때문에 클라이언트와 서버 소프트웨어가 동일해야한다는 교리가 순전히 제한적입니다. 클라이언트와 서버 데이터 가 동일해야한다는 신조는 특히 누구도 신경 쓰지 않고 모두 복제해야하는 15 년의 역사를 가진 코드베이스에서 엄청나게 우스꽝 스럽습니다.
우리가 실제로 그 모든 오래된 물건으로하고 싶은 것은 그것을 찬장에 넣고 거기에 있다는 사실을 잊는 것입니다. 일반 VCS처럼 말입니다. git이 매일 네트워크를 통해 모든 것을 앞뒤로 운반한다는 사실은 매우 위험합니다. 가지 치기에는 지루한 결정이 많이 필요하며 잘못 될 수 있습니다. 그래서 사람들은 아마도 역사의 다양한 지점에서 일련의 스냅 샷 리포지토리를 보관할 것입니다.하지만 처음에는 소스 제어가 무엇 이었습니까? 이 문제는 누군가가 분산 모델을 발명 할 때까지 존재하지 않았습니다.
힘내는 사람들이 역사를 다시 쓰도록 적극 장려하며, 위의 이유가 아마도 그 이유 중 하나 일 것입니다. 모든 일반 VCS는 관리자를 제외한 모든 사람이 기록을 다시 작성할 수 없도록하며 관리자가이를 고려할 이유가 없도록합니다. 내가 틀렸다면 정정하십시오.하지만 내가 아는 한 git은 일반 사용자에게 쓰기 권한을 부여하는 방법을 제공하지 않지만 기록을 다시 작성하지 못하도록 금지합니다. 이는 원한이있는 개발자 (또는 여전히 학습 곡선에 어려움을 겪고있는 개발자)가 전체 코드베이스를 폐기 할 수 있음을 의미합니다. 그걸 어떻게 조이나요? 글쎄, 당신은 전체 역사의 정기적 인 백업을 만들거나, 즉 당신은 역사를 제곱 한 상태로 유지하거나, 이메일로 모든 차이를 받아 손으로 병합하는 가난한 잔디를 제외한 모든 사람에 대한 쓰기 액세스를 금지합니다.
자금이 잘 조달 된 대규모 프로젝트의 예를 들어 git이 Android에서 어떻게 작동하는지 살펴 보겠습니다. 나는 한때 안드로이드 시스템 자체를 가지고 놀기로 결정했습니다. 나는 그들의 자식을 얻기 위해 repo라는 스크립트를 사용해야한다는 것을 알았습니다. 일부 repo는 클라이언트에서 실행되고 일부는 서버에서 실행되지만 둘 다 존재하는 것만으로도 git이 어느 쪽 용량에서든 불완전하다는 사실을 보여줍니다. 무슨 일이 있었는지 나는 약 일주일 동안 소스를 가져 오지 못하고 모두 포기했다. 여러 저장소에서 엄청나게 방대한 양의 데이터를 가져와야했지만 서버는 저와 같은 사람들로 인해 과부하 상태였습니다. Repo는 시간이 초과되어 시간이 초과 된 위치에서 다시 시작할 수 없습니다. git이 그렇게 배포 가능하다면, 당신은 그들이 d는 하나의 서버에 대한 부하를 줄이기 위해 일종의 피어 투 피어 작업을 수행했습니다. Git은 배포 가능하지만 서버가 아닙니다. Git + repo는 서버이지만 repo는 배포 할 수 없습니다. 단지 임시적인 해킹 모음이기 때문입니다.
git의 부적절 함을 보여주는 비슷한 예는 gitolite (그리고 그 조상은 잘 작동하지 않은 것 같습니다.) Gitolite는 git 서버의 배포를 용이하게하는 역할을 설명합니다. 다시 말하지만, 이것의 존재 자체는 git이 서버가 아니라 클라이언트라는 것을 증명합니다. 더군다나, 그것이 둘 중 하나로 성장한다면 그것은 창립 원칙을 배반 할 것이기 때문입니다.
분산 된 것을 믿더라도 git은 여전히 엉망 일 것입니다. 예를 들어 분기 란 무엇입니까? 그들은 당신이 저장소를 복제 할 때마다 암시 적으로 분기를 만든다고하지만, 그것은 단일 저장소의 분기와 같을 수 없습니다. 그래서 그것은 브랜치라고 불리는 적어도 두 가지 다른 것입니다. 그러나 그런 다음 repo에서 되 감고 편집을 시작할 수도 있습니다. 두 번째 유형의 가지와 같습니까, 아니면 또 다른 것입니까? 보유하고있는 저장소 유형에 따라 다를 수 있습니다.-오 예-분명히 저장소도 매우 명확한 개념이 아닙니다. 정상적인 것과 맨손이 있습니다. 베어 파트가 소스 트리와 동기화되지 않을 수 있으므로 일반 파트로 푸시 할 수 없습니다. 그러나 그들이 생각하지 않았기 때문에 맨손으로 cvsimport를 할 수 없습니다. 따라서 cvsimport를 일반 파일로 가져와야합니다. 개발자가 히트 한 베어에 복제하고 cvs에 cvs로 체크인해야하는 cvs 작업 복사본으로 cvsexport합니다. 누가 귀찮게 할 수 있습니까? 이 모든 합병증은 어디에서 왔습니까? 분산 된 아이디어 자체에서. 나는 이러한 제한을 더 많이 부과했기 때문에 결국 gitolite를 버렸다.
Git은 브랜치가 가벼워 야한다고 말하지만 많은 회사는 이미 심각한 불량 브랜치 문제를 가지고 있으므로 엄격한 정책을 통해 브랜칭이 중요한 결정이어야한다고 생각했습니다. 이것은 perforce가 정말로 빛나는 곳입니다 ...
Perforce에서는 매우 민첩한 방식으로 변경 집합을 처리 할 수 있으므로 분기가 거의 필요하지 않습니다. 예를 들어 일반적인 워크 플로는 메인 라인에서 마지막으로 알려진 양호한 버전과 동기화 한 다음 기능을 작성하는 것입니다. 파일을 수정하려고 할 때마다 해당 파일의 diff가 "기본 변경 집합"에 추가됩니다. 변경 세트를 체크인하려고하면 자동으로 메인 라인의 뉴스를 변경 세트로 병합 (효과적으로 리베이스) 한 다음 커밋합니다. 이 워크 플로는 사용자가 이해할 필요없이 시행됩니다. 따라서 Mainline은 나중에 쉽게 선택할 수있는 변경 내역을 수집합니다. 예를 들어, 이전 항목, 예를 들어 이전 항목을 되돌리고 싶다고 가정합니다. 문제가되는 변경 전 순간에 동기화하고 영향을받는 파일을 변경 집합의 일부로 표시하고 순간에 동기화하고 "항상 내"와 병합합니다. (매우 흥미로운 점이 있습니다. 동기화가 동일한 것을 의미하는 것은 아닙니다. 파일을 편집 할 수있는 경우 (즉, 활성 변경 집합에있는 경우) 동기화에 의해 방해되지 않지만 해결 예정으로 표시됩니다. 문제를 일으키는 변경 목록을 실행 취소합니다. 후속 뉴스를 합치면 원하는 효과를 내기 위해 메인 라인 위에 올라갈 수있는 변경 목록이 있습니다. 어떤 시점에서도 우리는 역사를 다시 쓰지 않았습니다. 후속 뉴스를 합치면 원하는 효과를 내기 위해 메인 라인 위에 올라갈 수있는 변경 목록이 있습니다. 어떤 시점에서도 우리는 역사를 다시 쓰지 않았습니다. 후속 뉴스를 합치면 원하는 효과를 내기 위해 메인 라인 위에 올라갈 수있는 변경 목록이 있습니다. 어떤 시점에서도 우리는 역사를 다시 쓰지 않았습니다.
자,이 과정의 중간 쯤에 있다고 가정하면 누군가가 당신에게 달려 가서 모든 것을 버리고 버그를 수정하라고 말합니다. 기본 변경 목록에 이름 (실제로 숫자)을 지정한 다음 "일시 중지"하고, 비어있는 기본 변경 목록의 버그를 수정하고, 커밋 한 다음 명명 된 변경 목록을 다시 시작하면됩니다. 여러 가지를 시도하는 한 번에 여러 변경 목록을 일시 중단하는 것이 일반적입니다. 쉽고 사적입니다. 당신은 미루거나 메인 라인으로 합병하지 않고 지부 정권에서 정말로 원하는 것을 얻습니다.
나는 이론적으로 git에서 비슷한 일을 할 수 있다고 생각하지만 git은 우리가 승인 한 워크 플로를 주장하기보다는 사실상 모든 것을 가능하게 만든다. 중앙 집중식 모델은 유효하지 않은 일반화 인 분산 모델과 관련된 유효한 단순화입니다. 너무 일반화되어 기본적으로 repo처럼 소스 제어를 구현할 것으로 예상합니다.
다른 것은 복제입니다. git에서는 모든 것이 가능하므로 스스로 알아 내야합니다. Perforce에서는 효과적으로 상태 비 저장 캐시를 얻습니다. 알아야 할 유일한 구성은 마스터가있는 위치이며 클라이언트는 재량에 따라 마스터 또는 캐시를 가리킬 수 있습니다. 그것은 5 분의 일이며 잘못 될 수 없습니다.
또한 코드 리뷰, 버그질라 참조 등을 주장하기위한 트리거와 사용자 정의 가능한 양식이 있으며, 물론 실제로 필요할 때를위한 분기도 있습니다. 명확한 케이스는 아니지만 가깝고 설정 및 유지 관리가 쉽습니다.
대체로 중앙 집중식으로 작업 할 것이라는 것을 알고 있다면 모두가 그렇게하는 것을 염두에두고 설계된 도구를 사용하는 것이 좋습니다. Git은 Linus의 무시 무시한 재치와 사람들이 양처럼 서로를 따라 다니는 경향 때문에 과대 평가되었지만, 그 주된 이유는 실제로 상식에 맞지 않으며, git은 자신의 손을 (a) 소프트웨어와 (b) 데이터가 클라이언트와 서버 모두에서 동일해야한다는 두 개의 거대한 교리로, 중앙 집중식 작업에서는 항상 복잡하고 절름발이가 될 것입니다.
GIT를 잘못된 코드 라인 관리 대신 사용하는 것은 일반적입니다. Perforce의 많은 단점은 잘못된 분기 전략의 결과입니다. 다른 중앙 집중식 도구에 대해서도 동일합니다. 많은 가지를 만들어야한다면 뭔가 잘못하고있는 것입니다. 개발자는 왜 그렇게 많은 브랜치를 만들어야합니까?
또한 연결이 끊어진 작업이 왜 그렇게 중요할까요? 누군가가 기차에서 일할 수 있도록? 요즘에는 무선 연결을 할 수없는 유일한 장소입니다. 그리고 대부분의 기차에도 괜찮은 WiFi가 있습니다.