GitHub에서 분기와 분기

github 프로젝트 분기의 생성과 github 프로젝트 분기의 장점과 단점에 대해 더 많이 알고 싶습니다.

Forking은 원래 프로젝트의 공동 작업자 목록에 있지 않아도되므로 내 프로젝트 버전을 원래 버전과 분리시킵니다. 사내에서 프로젝트를 개발하고 있기 때문에 사람들을 공동 작업자로 추가하는 데 아무런 문제가 없습니다. 그러나 프로젝트를 분기하면 병합 변경 사항이 기본 프로젝트로 다시 병합되는 것이 더 어려울 지 이해하고 싶습니다. 즉, 분기로 인해 두 프로젝트를 더 쉽게 동기화 할 수 있는지 궁금합니다. 다시 말해, 분기 할 때 주 프로젝트의 버전과 주 프로젝트간에 변경 사항을 병합하고 푸시하는 것이 더 쉬운가요?

해당 특정 프로젝트의 공동 작업자로 등록되어 있지 않기 때문에 분기를 만들거나 기존 분기를 가져 와서 다시 밀어 낼 수는 없습니다.

포킹은 GitHub 서버 측 의 복제 에 지나지 않습니다 .

• 직접 밀 수있는 가능성없이
• 와 포크 큐 기능은 병합 요청을 관리하기 위해 추가

다음과 같은 방법으로 포크를 원본 프로젝트와 동기화시킵니다.

• 원본 프로젝트를 리모컨으로 추가
• 원래 프로젝트에서 정기적으로 가져 오기
• 해당 페치에서 업데이트 한 관심 지점 위에 현재 개발을 리베이스하십시오.

리베이스를 사용하면 변경 사항을 간단하게 처리 할 수 ​​있으며 (병합 충돌이 발생하지 않음) 원본 프로젝트의 관리자가 자신의 프로젝트에 패치를 포함시키기를 원할 때 당김 요청이 더 쉬워집니다.

직접적인 참여가 항상 가능하지는 않지만 실제로 공동 작업을 허용하는 것이 목표입니다 .

GitHub 측에서 복제한다는 사실은 이제 두 개의 "중앙"저장소 ( "중앙"이 "여러 공동 작업자에게 표시됨") 임을 의미
하므로 한 프로젝트의 공동 작업자로 직접 추가 할 수있는 경우 다른 프로젝트를 관리 할 필요가 없습니다. 포크로 하나.

병합 경험은 거의 동일하지만 추가 수준의 간접적 (포크를 먼저 눌렀다가 원래 리포지토리에서 진화의 위험으로 더 이상 빨리 감기 병합을 더 이상 진행하지 않도록)을 요구하십시오. .
즉, 올바른 워크 플로우 git pull --rebase upstream(업스트림에서 새로운 커밋을 기반으로 작업을 리베이스) 한 다음 git push --force origin자신의 커밋이 항상 원래 (업스트림) 리포지토리의 커밋 위에있는 방식으로 기록을 다시 작성해야합니다. .

또한보십시오:

• 깃 포크는 git clone입니까?
• 원래 Github 저장소에서 분기 된 Github 저장소로 새 업데이트 가져 오기

높은 수준의 차이점은 다음과 같습니다.

분기

찬성

• 사용자별로 분기를 유지합니다
• 기본 리포지토리의 혼란을 줄입니다
• 팀 프로세스에 외부 기고자 프로세스가 반영됩니다.

단점

• 활성화 된 (또는 해당 문제에 대해 비활성화 된) 모든 브랜치를보기 어렵게 만듭니다.
• 지점에서 공동 작업하는 것이 더 까다 롭습니다 (포크 소유자는 사람을 공동 작업자로 추가해야 함)
• Git의 여러 리모컨 개념을 이해해야합니다.
  • 추가 정신 부기 필요
  • 이것은 Git에 익숙하지 않은 사람들에게는 워크 플로우를 더 어렵게 만듭니다.

분기

찬성

• 한 곳에서 프로젝트를 중심으로 모든 작업을 수행합니다.
• 모든 공동 작업자는 동일한 지점으로 푸시하여 협업 할 수 있습니다.
• 처리 할 Git 리모콘은 하나뿐입니다

단점

• 버려진 지점은 더 쉽게 쌓을 수 있습니다.
• 팀 기여 프로세스가 외부 기여자 프로세스와 일치하지 않습니다
• 팀원을 브랜치하기 전에 기고자로 추가해야합니다.

Git의 일반적인 워크 플로와 관련이 있습니다. 메인 프로젝트의 저장소로 직접 푸시 할 수 없을 것입니다. GitHub 프로젝트의 리포지토리가 브랜치 기반 액세스 제어를 지원하는지 확실하지 않습니다. 예를 들어 마스터 브랜치에 푸시 할 권한을 다른 사람에게 부여하고 싶지 않기 때문입니다.

일반적인 패턴은 다음과 같습니다.

• 원래 프로젝트의 저장소를 포크하여 자체 GitHub 사본을 가지면 변경 사항을 푸시 할 수 있습니다.
• GitHub 리포지토리를 로컬 머신에 복제
• 선택적으로 원래 저장소를 로컬 저장소의 추가 원격 저장소로 추가하십시오. 그런 다음 해당 리포지토리에 게시 된 변경 내용을 직접 가져올 수 있습니다.
• 로컬에서 수정하고 커밋하십시오.
• 일반적으로 프로젝트 저장소에 대한 쓰기 권한이 없으므로 GitHub 저장소로 변경 사항을 푸시하십시오.
• 프로젝트 관리자에게 문의하여 변경 사항을 가져 와서 검토 / 병합하도록 요청하고 프로젝트 저장소로 되돌 리도록하십시오 (원하는 경우).

이것이 없으면, 공공 프로젝트가 누군가가 자신의 커밋을 직접 추진하게하는 것은 매우 드문 일입니다.

Forking은 기존 저장소에서 완전히 새로운 저장소를 생성합니다 (gitHub / bitbucket에서 간단히 git clone 수행)

포크는 가장 잘 사용됩니다. '분할'의 의도가 논리적으로 독립적 인 프로젝트를 만드는 경우에는 부모와 다시 통합 될 수 없습니다.

지점 전략은 기존 / 작업 저장소에 새로운 지점을 만듭니다.

분기가 가장 잘 사용됩니다. 분기를 원점과 병합하려는 의도로 기능을 통해 작업 할 임시 장소로 만들 때.

더 구체적 :- 오픈 소스 프로젝트에서 리포지토리에 푸시 할 수있는 사람을 결정하는 것은 리포지토리의 소유자입니다. 그러나 오픈 소스의 아이디어는 모든 사람이 프로젝트에 기여할 수 있다는 것입니다.

이 문제는 포크로 해결됩니다. 개발자가 오픈 소스 프로젝트에서 무언가를 변경하려고 할 때 공식 저장소를 직접 복제하지 않습니다. 대신, 그들은 그것을 만들어서 사본을 만듭니다. 작업이 완료되면 저장소 소유자가 변경 사항을 검토하고 변경 사항을 자신의 프로젝트에 병합할지 여부를 결정할 수 있도록 풀 요청을 작성합니다.

핵심 분기점은 기능 분기와 유사하지만 분기를 작성하는 대신 저장소 포크를 작성하고 병합 요청을 수행하는 대신 풀 요청을 작성합니다.

아래 링크는 잘 설명 된 방식으로 차이점을 제공합니다.

https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/

https://buddy.works/blog/5-types-of-git-workflows

http://www.continuousagile.com/unblock/branching.html