관련없는 분기 간의 git-merge가 원하지 않는 커밋 기록을 가져 오지 못하도록 방지합니다.

Question

B (개인) 및 G (공개)의 2 개의 분기가 있습니다.

브랜치 B (개인)은 주로 내 분지를 개발하고 잠시 동안 개인 코드, 독점 알고리즘 및 공개 할 수없는 몇 가지 사항을 포함하는 모든 종류의 커밋을 포함합니다.

G (public) 지점을 만들었을 때 B (개인용)으로 간단하게 분기 할 수 없었기 때문에 이전에 공개 할 수없는 모든 항목이 내역에 포함되어 있으므로 새 항목을 만들었습니다. 처음부터 (즉, 부모가없는) 분기. 그런 다음 모든 파일을 지점 B (개인)에서 지점 G (공용)으로 가져온 것만 큼 가져오고 (복사 한) 첫 번째 커밋이었습니다.

그 이후로 나는 지점 B (개인)에서 개발 중이며 새로운 커밋이있을 때마다 G (공개)에 체리를 선택했습니다.

이 모든 것은 내가 힘내 시작하기 시작한시기에 이루어 졌으므로 아마도 더 나은 방법으로 그 일을 할 수 있었지만이 배는 오랫동안 항해했습니다.

어떻게하면 git이 작동하는지 (그리고 어떻게 사용되는지) 알게되었으므로 B을 G (또는 그 반대)에 병합하여 모든 커밋을 선택하지 않을 수있었습니다.

1. 이 G에 B 병합 : 그래서 여기에 내가 무엇을 시도했다입니다이들 역사에 접근 할 것이다 커밋 '누구나 G를 검색하기 때문에 unnaceptable 인 G에의 (개인) 커밋의 역사'는 B의 모든 수입 개인/민감한 데이터/알고리즘.

2. GB에 병합 :이 G (개인)에 체리 고른 커밋의 모든 중복, 짜증나는하지만 큰 문제이다. 그러나 B을 G에 병합하려고 시도한 이후로는 아직 충분하지 않았습니다. B의 (개인) 커밋 기록을 모두 G (받아 들일 수 없음)로 가져온 후에는 충분하지 않았습니다. 나는 이것이 git가 B에서 G으로 미래의 합병을위한 출발점으로 사용할 2 개의 가지에 "공통 부모"를 만들 것이라고 생각했다. 그렇지 않았다. 1. G의 오프 리베이스 B

3. 과 동일 문제 : B의 오프

4. 리베이스 G마다 G 커밋의 경우, 충돌이 만들어졌습니다, 그래서 이것은 취소 입증했다.

TL; DR : 나는이 두 가지 개인과 개인의 커밋을 포함 B 및 공개 G. 이것은 그들이 보는 방법은 다음과 같습니다

 
`B` (private): a -- b -- c -- d -- m -- n -- o -- p 
`G` (public): w -- x -- y -- z -/ 

m는 병합 B에 G에서 커밋이다.

난에 "수입", "병합"또는 "가져가"커밋 할 n, o, p (및 다른 B에 밀어 커밋) 그들에게 하나 하나 (하나의 병합을 체리 따기 가져 커밋하지 않고, G에 G에 대한 모든 변경 사항은 B의 이전 기록을 모두 가져 오지 않는 한 허용됩니다.

내 문제에 대한 해결책이 있는지는 잘 모르겠지만 어떤 도움을 주시면 감사하겠습니다.

Answer 1

언급 한 바와 같이 진정한 기밀 정보는 Git repo에서는 있지만 일부 금고에서는 Git 콘텐츠 필터 드라이버 (even though that can be challenging)를 사용합니다.

Git repo를 별도로 보유하는 것은 최소이며 개인 공개는 공개 one as a submodule을 참조해야합니다.

Answer 2

이러한 개인 커밋의 특성은 무엇입니까? 그들 자신의 파일에 스스로 포함되어 있습니까? 당신이 커밋을 선택했기 때문에 이것이 사실이라고 가정하고 공개 알고리즘/데이터 대 개인 알고리즘/데이터의 성격에 대한 병합 충돌을 끊임없이 다루지 않기를 바랍니다.

여기에 분기를 사용하지 말고 별도의 리포지토리를 제안 하시겠습니까? 데이터와 알고리즘을 보호하는 데 신경 쓰면 실수로 다른 팀 구성원이 리베이스/병합을 수행하면 어떤 일이 발생할 수 있는지 생각해보십시오. 또한 대부분의 자식 서버가 저장소 수준에서 작동하고 지점 수준에서는 작동하지 않으므로 별도의 저장소가있는 경우 감사 및 액세스 제어가 훨씬 쉬워집니다. 환경/구성 변수/개인 키 등 같은

1. 비밀 :

   별도의 repos에 대한 이동하기로 결정하는 경우

   , 당신의 독점 정보 은폐에 대한 두 가지 해결책이 있습니다 다음은 버전 관리에 있으면 안 어쨌든 시스템. gitignore에 줄을 지키라. 이들을 팀 동료에게 전달해야하는 경우 VCS보다 다른 통신 수단을 사용하십시오. 이렇게하면 실수로 푸시를 할 수있게하면서 데이터를 실수로 푸시하지 않고 공개 레포로 보호 ​​할 수 있습니다.
2. 개인 클래스/구현 : 이는 까다 롭습니다. 당신은 분명히 그들을 gitignore하고 싶지 않을 것입니다. 내 팀이 git public-push 또는 뭔가 할 수 있도록이 자식 플러그인을 작성하는 것이 좋습니다. 따라서 개인 파일을 프로그래밍 방식으로 결정할 수 있고 공개 repo에 푸시해야하기 때문에 많은 유연성을 제공합니다. 또는 이것에 대해 편집증을 쓴다면 여전히 감사를하고 체리를 선택할 수 있습니다.

TL; DR - 별도의 분기가 아닌 별도의 저장소가 있어야하며 사용자 정의 git 플러그인 일 수도 있습니다. 이렇게하면 단일 git push (또는 사용자 정의 플러그인 또는 기타)을 사용할 수 있으며 유명하게되면 공개 repo에 외부 제공자를 허용 할 수 있습니다.