Git 포크 사용

Question

그것은 나에게 꽤 새로운 일입니다. 우리는 고객이 우리 소스 코드에 액세스 할 수 있음을 인정했습니다. bitbucket/Sourcetree를 사용하여 포크 (Fork)를 사용하여 주어진 상태에 대한 액세스 읽기/커밋을 허용했습니다. 실제 코드 (아직 개발 코드에 있음)에 대한 액세스 권한을 부여하고 싶지 않습니다. 마일스톤 만 공유 할 계획입니다. 이 방식으로 포크를 사용할 수 있습니까? 다른 커밋을 공유하는 다른 옵션이 있습니까? BR, 다니엘 나는 당신이 원하는 무슨 생각을 들어

Answer 1

, 가장 간단한 방법이 될 것이다 :

1. 체크 아웃이 공유 할 커밋
2. 다른 이름으로 프로젝트 디렉토리 (.git 숨겨진 디렉터리 제외);
3. 프로젝트 디렉토리를 새 git repo (github, bitbucket 또는 wherever)로 복사 한 파일을 가져옵니다. 또는 우편 번호를 보내어 고객에게 직접 보내십시오.

이렇게하면 클라이언트에 코드 스냅 샷이 표시됩니다. 현재 커밋이나 기록이 없습니다.

Answer 2

저장소 내에서 커밋 또는 분기 수준의 액세스 제어를 제공하는 방법이 있다고 생각하지 않습니다. 제한된 리포를 만드는 것이 합리적인 방법이지만 필요에 따라 세르지오 튤렌 제프 (Sergio Tulentsev)의 제안에서 스냅 샷을 복사하는 몇 가지 대안을 제안 할 수 있습니다.

잠재적 인 단점은 내부적으로 공유 스냅 샷을 기록에 다시 연결하는 데이터가 손실된다는 것입니다. 앞으로 새로운 버전을 제공하거나 포크에서 패치를 코드베이스로 다시 받아 들일 수 있다면,이 분리는 추가 작업을 만듭니다. 솔루션의

부분은 간단하게 (역사) 당신의 커밋과 자신의 커밋 (제공 스냅 샷) 사이의 관계를 추적한다; 그 문제의 일부분을 태그 지정 규칙으로 해결할 수 있습니다. 그러나 그 이상으로, 변경 사항을 앞뒤로 마이그레이션하려는 경우 수동 마이그레이션 작업을 피하기 위해 설정을 할 수 있습니다. (가) 처음 공유하고 포크 지점을 만들려면 커밋 식별,

먼저, REPO의 :

그래서 당신은 이런 식으로 뭔가를 시도 할 수 있습니다. 당신은로 태그 확약 한 경우 커밋에-공유 할 다음

git checkout commit-to-be-shared 
git checkout -b fork_master 

(당신이 생각하는 경우 아니면 대신 fork-master의 고객의 이름, 이것은 당신이 다른 사람을 다시 할 수있는 일입니다 ...)

다음으로 수동으로 새 저장소로 복사하는 대신 원본의 "얕은 복제본"을 만듭니다. URL (로컬 경로 아님)을 사용해야합니다. 일반적 file://path/to/my/repo 같은 /path/to/my/repo 사용 무언가로 REPO를 해결하는 경우 그래서 ...

cd .. 
git clone --depth=1 -b fork-master http://my.server/origin-repo 

이것은 단지 하나의 커밋 복사합니다 및 설정합니다 ... 자세한 내용은 OS에 따라, 그러나 희망 당신은 내가 무슨 뜻인지 확인할 수 up fetch를 사용하여 fork-master 분기 만 검색하십시오. 그러나은 커밋의 ID를 보존합니다. 그래서 원점에서 미래에 더 많은 변경을 fork-master에 병합하여 결과 커밋을 쉽게 공유 할 수 있습니다.BUT 변경 사항을 더 많이 입력 할 경우, 의도하지 않은 기록 노출을 피하는 방법에 대해서는 아래를 참조하십시오.

다음으로 고객의 출처가 될 서버에서 (원산지와 함께) 빈 레포를 준비합니다.

(... 당신은 당신이 나중에있을 수 있습니다 생각한다면 다시 원격에 대한 고객 별 이름을 사용할 수 있습니다)

git remote add fork-origin http://my.server/fork-origin-repo 
git push -u fork-origin master 

가 : 새로 생성 얕은 REPO에 두 번째 원격으로 설정

허용하려는 개발자는 누구나 fork-master을 추가 할 수 있습니다. 이렇게하면 고객으로부터 패치를 원활하게받을 수 있습니다.

나중에 실수로 내역을 공개하지 않도록하는 것이 트릭입니다. 나중에 fork-master으로 병합하여 fork-origin에 전달하면 기본적으로 새로 병합 된 커밋의 기록이 나타납니다. 명백한 간단한 수정은 얕은의 repo에서, :

git pull --depth=1 

여기서 문제는 자식이 혼동 될 수 있다는 것입니다. (간단한 설명은 새로 가져온 병합은 두 번째 부모에 깊이 1이 있어야하지만 첫 번째 부모에는 깊이 1이 없기 때문에 자식이 원하는대로 처리하지 못하는 것입니다.) 해결하기가 너무 어렵지 않음 :

git pull --depth=2 

이제 합병을 통해 새로 병합 된 작업에 대한 추가 커밋이 생겼음을 알 수 있습니다. 그 커밋은 당신이 fork-master에 머지하고있는 변경 사항들을 담고있어서 아마 괜찮습니다; 하지만 커밋 메시지 나 태그 또는 다른 사람이 공유하고 싶지 않은 메시지가있을 수 있습니다. 이 경우 병합 직전에 일종의 "버퍼 커밋"을 만들 수 있습니다. F1 원래 공유 스냅 샷입니다

F1 -------- F2 <--(fork-master) 
    /  /
/   B 
/  /
X ---- X --- A --- X <--(master) 

, A는 B는이 "고객의 안전이"그 본질적 A 중복 투입하고, F2는 새로운 병합, 당신은 공유하기로 결정했습니다 더 변경 사항이 포함되어 있습니다. 그런 다음 고객은

F1 ---- F2 
    /
     B 

당신은 B를 만들 git commit를 호출 할 때 --allow-empty 옵션을 사용 할 수 있습니다 볼 것입니다.

참고이 엔드 - 투 - 엔드를 테스트 할 기회가 없었습니다. 어떤 단계에서 오류가 발생하면 알려 주시면 그에 맞게 업데이트 할 수 있습니다.